[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[nreal]

Anybody notice a drop in shares?
With no changes in setup or machines....
My shares stopped late last night...
So today, I rebooted my computer and reset the system and started everything fresh even the bitcore....
Now running 4 hours at 4 TH and 0.0 shares...
Thats very unusual as I usually get about 2 an hour on average...
Just wondering if its only me?

Thanks

That's variance for you.  Now... that's some pretty crappy luck, but, it happens.  Sometimes when that happens to me, I give my miners a little pep talk.  Positive words of encouragement like, "I'm going to trade you in" and "Do you want to end up on eBay, too?".  Then, a lot of times if that doesn't do the trick, I'll threaten them with unplugging them and not plugging them back in or forcing them to work on the same block over and over until they get it right.  In extreme cases I'll reboot everything repeatedly, just so they know who is in control.

[1713859463]

1713859463

[1713859463]

1713859463

[Duce]

Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229

[squashpile]

I have not yet, but I'll give it a try. I don't think it ever made a difference on my s1 with manual diff on P2Pool. I'm going with everything default so far on P2Pool with the S3's. Pretty sure there was good bit of discussion about this many pages back. Maybe it's different on the S3, but I doubt it.

Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229

[Duce]

I have not yet, but I'll give it a try. I don't think it ever made a difference on my s1 with manual diff on P2Pool. I'm going with everything default so far on P2Pool with the S3's. Pretty sure there was good bit of discussion about this many pages back. Maybe it's different on the S3, but I doubt it.

Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229

There was some talk on the other thread https://bitcointalk.org/index.php?topic=671189.msg8139727#msg8139727 that I replied on about the queue which I did see a few pages back here addressed too but must have missed the difficulty post. windpath is conducting some testing with the queue. I am now following the guidance from the Norgz P2P site for the difficulty setting to see if that makes any difference. So far the BestShare value has come back but do not know if that matters. I think the S3 is working fine on P2P but I am sure if we were not trying different settings we would not be happy.

[sconklin321]

I have not yet, but I'll give it a try. I don't think it ever made a difference on my s1 with manual diff on P2Pool. I'm going with everything default so far on P2Pool with the S3's. Pretty sure there was good bit of discussion about this many pages back. Maybe it's different on the S3, but I doubt it.

Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229

There was some talk on the other thread https://bitcointalk.org/index.php?topic=671189.msg8139727#msg8139727 that I replied on about the queue which I did see a few pages back here addressed too but must have missed the difficulty post. windpath is conducting some testing with the queue. I am now following the guidance from the Norgz P2P site for the difficulty setting to see if that makes any difference. So far the BestShare value has come back but do not know if that matters. I think the S3 is working fine on P2P but I am sure if we were not trying different settings we would not be happy.

I would imagine best share would be the same as best share in cgminer or bfgminer, the highest difficulty share found.  Right now at a 1.4 PH pool rate its currently 4.9M to get a share so you would need to see 4.9M or higher to have earned a share on p2pool.

[kgb2mining]

I'm starting to play around with the static difficulty setting on my S1's (I'm mining at coincadence ATM).  Through yesterday I had left it at the default, which according to the monitoring was "1,000".

Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).

Before the change I had 4 shares over the span of 6 hours.  After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC.  Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.

In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%.  This to me is a good sign I think.

From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently.  If I'm correct in thinking that, then it makes sense.  We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.

I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's.  We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.

[sconklin321]

I'm starting to play around with the static difficulty setting on my S1's (I'm mining at coincadence ATM).  Through yesterday I had left it at the default, which according to the monitoring was "1,000".

Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).

Before the change I had 4 shares over the span of 6 hours.  After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC.  Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.

In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%.  This to me is a good sign I think.

From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently.  If I'm correct in thinking that, then it makes sense.  We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.

I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's.  We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.

I would think that latency and bandwidith would go up with the local node as you are now submitting shares every time you solve 128 instead of 1000, thus increasing both the load and bandwidth to process the increased number of shares coming into the local node.

[kgb2mining]

I would think that latency and bandwidith would go up with the local node as you are now submitting shares every time you solve 128 instead of 1000, thus increasing both the load and bandwidth to process the increased number of shares coming into the local node.

In theory, yes this could affect a node with insufficient resources to handle the additional traffic and processing.  Given the node I'm connected to, it shouldn't have enough of an affect to be detrimental since we're not talking about hundreds of miners, only 20 or so.  Over the next couple weeks we'll be building our own local node which should make the resource questions moot, even for a few hundred miners at low diff.  At least, I think so...

Now we're up to 4 hours without a share, so maybe it'll turn out that manually setting the diff really won't have much of an effect in the long run.

[jonnybravo0311]

I'm starting to play around with the static difficulty setting on my S1's (I'm mining at coincadence ATM).  Through yesterday I had left it at the default, which according to the monitoring was "1,000".

Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).

Before the change I had 4 shares over the span of 6 hours.  After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC.  Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.

In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%.  This to me is a good sign I think.

From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently.  If I'm correct in thinking that, then it makes sense.  We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.

I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's.  We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.

Setting +128 sets your pseudo-share difficulty.  All it does is tell the p2pool node to accept shares from your miner of 128 difficulty or higher.  The effect is to make the graph prettier at the cost of increased bandwidth and processing done by the node to handle the extra shares your miners are sending.
Setting actual share difficulty is done by /128.  Unless you set this to some value higher than the share difficulty, it makes no difference to p2pool since you need to find a share of about 4.5M to even get on the chain.  The only time you'd want to set this value is if you've got a much higher hash rate than average on the node.

You seeing 10 shares in 9 hours is nothing more than luck - not because you set the difficulty level.

[Carlton Banks]

You seeing 10 shares in 9 hours is nothing more than luck - not because you set the difficulty level.

Yes

Setting +128 sets your pseudo-share difficulty.  All it does is tell the p2pool node to accept shares from your miner of 128 difficulty or higher.  The effect is to make the graph prettier at the cost of increased bandwidth and processing done by the node to handle the extra shares your miners are sending.

No

Using the + indicator doesn't alter the way p2pool software runs, it doesn't tell it anything. + supplies information to the miner software (cgminer/bfg), that runs on the miner or whatever separate device you have controlling the ASIC boards. It tells the miner: do not send shares of difficulty lower than +n to the pool node. So: no extra shares are sent to the pool, it's the opposite.

Because + setting affects the mining software, it should be tuned for the hashrate of the individual mining device. So, for a standard Ant S3, somewhere between +256 and +512 will likely give the best results (rule of thumb is to use +1 for every 1 GH/s). + indicator must be set to get best performance for a given hashrate, otherwise the pool software becomes saturated with difficulty 1-2 shares that are not accepted on any pool these days (p2pool least of all...)

Setting actual share difficulty is done by /128.  Unless you set this to some value higher than the share difficulty, it makes no difference to p2pool since you need to find a share of about 4.5M to even get on the chain.  The only time you'd want to set this value is if you've got a much higher hash rate than average on the node.

Yes. Remember that unlike +, / indicator is information for the pool software. So whatever you set should be in relation to your total hashrate on your p2pool node, whereas + should be set to suit the hashrate of each individual mining unit. The rule of thumb is to set this to target an average of one share per hour, IIRC

Setting / is only a good idea for those with bigger overall hashrates. The advantage is that you forego the chance to get a smaller diff share accepted on the chain to concentrate on bigger diff shares (shares are weighted according to difficulty, i.e. 1 high diff share has higher payout than 1 share that only just passes the share difficulty).

[jonnybravo0311]

No

Using the + indicator doesn't alter the way p2pool software runs, it doesn't tell it anything. + supplies information to the miner software (cgminer/bfg), that runs on the miner or whatever separate device you have controlling the ASIC boards. It tells the miner: do not send shares of difficulty lower than +n to the pool node. So: no extra shares are sent to the pool, it's the opposite.

Because + setting affects the mining software, it should be tuned for the hashrate of the individual mining device. So, for a standard Ant S3, somewhere between +256 and +512 will likely give the best results (rule of thumb is to use +1 for every 1 GH/s). + indicator must be set to get best performance for a given hashrate, otherwise the pool software becomes saturated with difficulty 1-2 shares that are not accepted on any pool these days (p2pool least of all...)

Are you stating that if you do not set the pseudo-share difficulty by using ADDRESS+n, then your miner will flood the p2pool node on which you're hashing with difficulty 1 shares?  If that's the case, then why does the p2pool software even care about the "+"?  In other words why would code exist in p2pool to handle you setting the pseudo-share difficulty at all if, as you state, it has no effect on the way the software runs?

From work.py:

Code:

self.pseudoshare_received = variable.Event()

Code:

        desired_pseudoshare_target = None
        desired_share_target = None
        for symbol, parameter in zip(contents2[::2], contents2[1::2]):
            if symbol == '+':
                try:
                    desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
                except:
                    if p2pool.DEBUG:
                        log.err()
            elif symbol == '/':
                try:
                    desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
                except:
                    if p2pool.DEBUG:
                        log.err()

Code:

if desired_pseudoshare_target is None:
            target = 2**256-1
            local_hash_rate = self._estimate_local_hash_rate()
            if local_hash_rate is not None:
                target = min(target,
                    bitcoin_data.average_attempts_to_target(local_hash_rate * 1)) # limit to 1 share response every second by modulating pseudoshare difficulty
        else:
            target = desired_pseudoshare_target
        target = max(target, share_info['bits'].target)
        for aux_work, index, hashes in mm_later:
            target = max(target, aux_work['target'])
        target = math.clip(target, self.node.net.PARENT.SANE_TARGET_RANGE)

Up to this point, I have been under the impression that p2pool dynamically tells the mining software to use the difficulty it assigns, or if the miner sets its own static pseudo-share difficulty, to use that one instead.  I can see this happening in the logs, as well as in the UIs of my miners.

Let me give another example.  If I set the pseudo-share difficulty to ADDRESS+1, I can see my graphs become very smooth.  If I set the pseudo-share difficulty to ADDRESS+1000, the graphs become very spiked.  If I do not set it at all, the graphs are somewhere in the middle.  If your assertion that setting of the value has no bearing on p2pool were true, then not setting it, and setting it to ADDRESS+1 should have the same effect: a very smooth looking graph.

So, to conclude, if you do not set the pseudo-share difficulty, one is assigned to you based upon the hashing power on the node by the p2pool software.  If you do set it, then your miners submit shares at or above the value you set.  If you set this value to something extremely low, then you are indeed flooding the p2pool node with shares that are completely worthless, but your graphs will look nice.  Hence, you are using more bandwidth, and the node is processing a bunch of useless work.

[Carlton Banks]

Well, this is news to me (p2pool setting the pseudo share value itself). All previous talk about this, including everything I've seen outside this thread, has suggested manually setting pseudo shares. I always thought the auto detect feature (-1) wasn't a part of Stratum. For whatever reason, this doesn't appear to be working right with the Ant S3, or user kgb2mining wouldn't gain anything from setting pseudo shares manually.

[kgb2mining]

Ok, so maybe I'm not understanding correctly what the different config options are and what they mean to my situation.  In my mind I was concerned with tuning the miners according to a method of minimizing stales and rejects as I assume lower means better average hashrate and work done on the chain.  I'm less concerned with how my graphs look.  I am more concerned with maximizing the good work done and getting the most out of the miners (as I'm sure most are).

Right now, I've got 20+ Antminer S1's (which is where I set the address+128 pseudo diff), and 2 Cointerra IV's, default configs.  Will be adding more S1's and a good bunch of S3's in the coming weeks.  Call it around a total of 7TH/s average for now, to grow soon.  All of them are set with the same miner address so to the node it appears as one large miner.  I'm mining on coincadence, and I seem to be averaging a share every 1h15m at the moment.

One question is should I split up my types of miners into "sub-pools", organizing by type of miner as well as aggregate mining speed?  From what I'm reading there seems to be per-miner best configs, and then per-node settings so that those with a higher overall hashrate can "play nicer" with the rest of the miners on the node.  I could end up splitting into groups of roughly ~3Th/s each, putting me at the top end of the average hashrate on the node, but not making it so overly out of whack.  And I'm assuming this would also apply whether I'm mining on another node, or if I create my own.  If I bring up my own node I would be better off still trying to keep hashrates similar so that the pool work / share difficulty is roughly even?

Are the "+" and the "/" mutually exclusive settings, i.e. you can have one or the other so you're optimizing for the miner or the node, but not both?

I hope I'm not beating a dead horse with these questions, but unfortunately I've not been able to find one set of clear info anywhere which gives kind of a guide on how to properly configure your miners to get the most out of P2Pool - reading through almost 500 pages of this thread is likely to not happen, so if there's a good breakdown of this earlier, point me to a page and I'll happily go read.

[jonnybravo0311]

Ok, so maybe I'm not understanding correctly what the different config options are and what they mean to my situation.  In my mind I was concerned with tuning the miners according to a method of minimizing stales and rejects as I assume lower means better average hashrate and work done on the chain.  I'm less concerned with how my graphs look.  I am more concerned with maximizing the good work done and getting the most out of the miners (as I'm sure most are).

Right now, I've got 20+ Antminer S1's (which is where I set the address+128 pseudo diff), and 2 Cointerra IV's, default configs.  Will be adding more S1's and a good bunch of S3's in the coming weeks.  Call it around a total of 7TH/s average for now, to grow soon.  All of them are set with the same miner address so to the node it appears as one large miner.  I'm mining on coincadence, and I seem to be averaging a share every 1h15m at the moment.

One question is should I split up my types of miners into "sub-pools", organizing by type of miner as well as aggregate mining speed?  From what I'm reading there seems to be per-miner best configs, and then per-node settings so that those with a higher overall hashrate can "play nicer" with the rest of the miners on the node.  I could end up splitting into groups of roughly ~3Th/s each, putting me at the top end of the average hashrate on the node, but not making it so overly out of whack.  And I'm assuming this would also apply whether I'm mining on another node, or if I create my own.  If I bring up my own node I would be better off still trying to keep hashrates similar so that the pool work / share difficulty is roughly even?

Are the "+" and the "/" mutually exclusive settings, i.e. you can have one or the other so you're optimizing for the miner or the node, but not both?

I hope I'm not beating a dead horse with these questions, but unfortunately I've not been able to find one set of clear info anywhere which gives kind of a guide on how to properly configure your miners to get the most out of P2Pool - reading through almost 500 pages of this thread is likely to not happen, so if there's a good breakdown of this earlier, point me to a page and I'll happily go read.

You're not beating a dead horse at all, and your questions are good ones.

First, the "+" and "/" are not mutually exclusive.  You can set your mining address to "ADDRESS/256+256" and both the pseudo-share and actual share difficulty would be set accordingly.

As to whether or not you should set values... that's debatable.  If you do not set anything, the node will make the determination for you based upon the node's entire hash rate.  There are patches out there to address this, but the node operator would have to install the proper fork of the p2pool code.  These patches will dynamically determine the proper difficulty setting based upon the address, rather than the node's hash rate.  On windpath's node, if you don't set it, you'll get the highest value set for you: 1000 (he'd probably actually see 999.99 in the logs, but whatever...).

Bitmain has come out and stated that S3 owners who mine on p2pool should set the difficulty levels manually.  They have suggested using "ADDRESS/256+256".  I've tried it and have found absolutely no difference in performance.  My error rates, WU, accepted vs rejected have all remained consistent whether or not I set it.  I have noticed no difference in hashing speed, either.

Could there be an effect of setting these values?  Possibly.  I just don't know enough of Bitmain's driver code to understand where the advantage would be in forcing static difficulty settings vs dynamic ones.  Hence, even though I personally have seen no difference, I have set my S3s to Bitmain's recommendations.  One thing I have noticed, however, is that by doing so, my "Best Share" value is now ALWAYS "0".  Not that the value has any meaning other than to see just how close you came to solving a block.

If I remember correctly - and Carlton Banks stated this as well in his post - your target should be around a share an hour.  Since you're pretty much there now, I don't see a need for you to set your share difficulty (by using "/") to a value higher than the ~4.5M already required to put a share on the chain.  However, if you do add enough hardware to make it so you find shares considerably faster than that, you might want to set it at that point.  Right now, to find a share an hour (using 4.5M as the share difficulty), we can figure it out using the following:

Code:

Difficulty * 2**32 / hash rate = number of seconds to find a share
4500000 * 2**32 / R = 3600
R = 5368709120000

So, 5.37TH/s is the hash rate you'd need to find a share an hour at 4.5M difficulty.  Obviously that rate changes as the difficulty level does.  Just like I did with the previous formula, you can determine what your difficulty *should* be set to if you know your hash rate to keep that share finding time at 1 hour.  You could then use that to set your difficulty via the "/".  For example, let's assume I've got 10TH/s:

Code:

D * 2**32 / 10000000000000 = 3600
D = 8381903.17153930664063

So, if you had 10TH/s and wanted to keep your share finding to an hour, you'd use "ADDRESS/8381903"

Hope this helps.

[sconklin321]

I had a question that might if everything works as I believe, could be a possible solution to eliminate some of our issue with scalability.  Correct me if I'm wrong, but regardless of the actual hashrate on p2pool, it adjusts the minimum share difficulty to maintain an average of a 30 second share submission rate?  So if everyone used the "Address/Minimum share submit" it would then adjust the minimum difficulty to maintain the 30 second share submission regardless of the actual hashrate, correct?

If all of the above is true, wouldn't hard coding the formula below from JonnyBravo0311 to main a minimum share submission of 1 share/hr based on the address' hashrate alleviate some of the ever increasing difficutly so that smaller miners, I have to admit this includes myself at 250 gh/s, would be able to submit more shares?  It shouldn't effect anyone's income, as it was my understanding that we get our distributions based on weighted shares anyway.

Code:

Difficulty * 2**32 / hash rate = number of seconds to find a share
4500000 * 2**32 / R = 3600
R = 5368709120000

If all my assumptions are correct, I believe this would, at least for the short term, be a viable option until a more permanent can be found an coded.  Any feedback would be appreciated.

[contactlight]

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

[mdude77]

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

[contactlight]

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

So the actual share difficulty is actually not based on the hashrate of the miner. Only the psuedoshare difficulty depends on the hashrate. Is that correct?

Are psuedoshares valued at all? Because even though my node says approximately 6 hours to a share, I don't get any shares even when I run my miner for over a day.

[mdude77]

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

So the actual share difficulty is actually not based on the hashrate of the miner. Only the psuedoshare difficulty depends on the hashrate. Is that correct?

Are psuedoshares valued at all? Because even though my node says approximately 6 hours to a share, I don't get any shares even when I run my miner for over a day.

Pseudoshares only make your hashrate look better on the graph.  The actual share chain difficulty is based upon the entire hashrate of the pool.  Keep in mind luck (aka variance) plays a role here.  When it says approx 6 hours, that's on average.  You'll have some that are less, some that are more, but your luck has to be pretty bad to not get one within 24 hours.

I've got two folks on my node that look like they're using two S3s a piece.  They're chugging right along with shares, so S3s seem to be working well.

M

[ceslick]

So what are the best settings then for an S1 running at 200GHS on P2Pool?