Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 321. (Read 2591971 times)

Then Norgs guide saying add /0+220 to your address is not optimum?

Should it just be +220?

Keep digging...don't think your assertation is correct. I know from experience that /0 absolutely sets your miners to get shares at the smallest possible p2pool share difficulty (currently at 4608650.012 for BTC).

Why is this not documented? No wonder P2Pool isn't taking off. We need all critical code paths documented and logic explained.

On a side note, I refuse to believe that what I am experiencing is just variance and bad luck. It has been over 24 hours and I still haven't found a share with my 2 x S3s running at 1TH/s. There is definitely some sort of incompatibility between S3s and P2Pool.

While I love the idea behind P2Pool, sadly I won't be able to be a part of it until this is fixed. However, I am not hopeful that it will be fixed as let alone identifying the problem, it isn't even acknowledged yet. Pointing my miners to Eligius.

Ok... did a little investigating on this issue.  First off, setting the difficulty to /0 or +0 actually initially sets both to the highest possible values.  First the code in work.py in get_user_details:
Now the code for bitcoin_data.difficulty_to_target:

So for sure don't set your miners to /0 or +0.

The only time I can find any mention of the dust threshold of the coin in the code is when you have not set a difficulty.  In this case if the expected payout per block is less than the dust threshold, it resets your desired difficulty such that your expected payout is greater than that threshold.  Here's the code:

I'm going to keep digging through the code to see what more I can learn from it.

Here it is https://bitcointalksearch.org/topic/m.8036549

Nope, have not seen that site before. Their recommendation on /0+220 seems good for S1's. You could play with the 220 until you get a pseudo share diff that your comfortable with.

In regard to the --scan-time 1 --expiry 1 settings I read a detailed post (I think from ck) saying those were essentially obsolete. Wish I would have saved it.

Greetings guys/gals,

Been out of the country for a few weeks so only got to setting up my S3's a few days ago, but I'm now able to get back to mining with p2pool again & thought I'd share my experience with them after tinkering for a few days trying to find the optimal settings. Generally I'm quite impressed with the S3, even though the performance can vary massively between different devices with the same settings.

They are all B1 units flashed with the latest (non beeping) firmware for my own sanity. I done some reading up on other users experiences/settings & decided to stay away from using the --scan-time 1 --expiry 1 on the advice of ck, choosing to play with the --queue settings & frequencies instead. I have always used --queue 0 with p2pool, believing this to be the optimal requirement, but found that --queue 1 resulted in the lowest discard rate & stopped the cpu maxing out at 100% - why this is I'm not sure, but I'll roll with it. All of my S3's cpu rate now hover ~85% with a much more acceptable discard rate. The freq settings are either 218.75, 237.5 or 250 depending on the unit - some flat refuse to go above 218.75 without losing the plot - others sit there at 250 with less HW errors/discards/rejects than those running at 218.75   I also found 225 to be the worst performing freq of the lot!

Generally I'm quite impressed with them though and it's good to be back on p2pool. I had an email from Bitmain saying they would have a solution for various p2pool issues soon, that was 4 weeks ago & I've not heard a dickey bird since. I did also try their recommended setting of /256 +256 but found them to make no difference whatsoever, so I let p2pool decide the diff which seems to work pretty well. All the units were stripped & checked for lose screws etc before using, but generally the build quality was sound.

With everything that is going on with AMT, KNC, Rockminer, Black Arrow, Spondoolies etc, it seems Bitmain have not only come out with another little gem - but have probably saved p2pools bacon by ensuring that the S3's are at least usable with p2pool, even if not 100% efficiently - hopefully this will be addressed soon with a little more whining encouragement from p2pool users.....the increase in p2pool hashrate is testament to this and I'm wondering if the massive hashrate fluctuations are actually Bitmain keeping true to their promise of investing their equipment into p2pool......that would be nice  

Did we get a new dev yet by the way?

Peace  

OK this link is the easiest for me to follow and accomplish...
Do you really feel that this will make my outcome much better?? I hate to screw around with the settings and have amess on my hands.
! am running 16 S-1's

As soon as we jump up in hashing... my income drops to peanuts?

Did you lift some of your suggested settings from Norgz' Antminer settings page?
http://www.norgzpool.net.au/antminer.html

Please help me

LAN 192.168.0.250:9332, 192.168.0.252: 9332.

How these two pools of fixed interconnected team.

Which folder should be modified? Thank you.

I'll take a look at the code to see if /0 really would override the dust payout threshold.  I didn't see anything to that effect, but then again I wasn't looking for it.  I'll post back here (probably tomorrow, I'm tired of looking at code) with any findings.  Of course, if anybody else can provide an answer to what effect /0 might have on dust threshold, that'd be great, too.

As I wrote a few pages back, I have seen no difference in the performance of my S3s between letting the node determine difficulty, and setting it manually as per Bitmain's direction (ADDRESS/256+256).  The only actual difference I have seen is on the S3 web UI's miner status page.  The value of Best Share is always "0" when manually setting the difficulty.

The real miners who should be setting the difficulty are the big hitters.  If your hashing rate has you expecting to find more than a share an hour, set your difficulty appropriately (i.e. HIGHER than the p2pool share difficulty) so the rest of the miners on the node don't suffer for it.

Huh... there's an interesting thing to look into as well.  If I have 5 miners on my node, 4 miners have 1TH/s each and the 5th miner has 100TH/s, would the node not consider the big hitter's hash rate when setting the difficulty for the other miners if the big hitter sets his own difficulty using ADDRESS/value?  If not, then it is advisable for all miners on public nodes to set a difficulty manually.

It would be nice if forrestv actually provided the answers to these, and other queries.  Unfortunately, he's not been on the boards since 7/26, so this post will probably not gain his attention.

Yes, that's where it should be changed.  Note, however, that from my own testing, the blockchain.info site throws back an error if you try to call it from script like that.  Even though it clearly states on their site that it can be done, it fails.  I'm still looking for a way to incorporate it into the JS and not re-writing everything in a php.

Here's what happens when I change the call.  First the code for the call:

And the resulting error:

If I change it to use https, the error becomes:

It's an issue on blockchain.info.  They specifically state they allow cross-site connections (that's what the cors=true is supposed to handle), yet as you can see it fails.  I've also tried forcing CORS locally by doing:
But, that fails as well.

Oh well... the API is there, and it works if you just paste that link in your browser.  Hopefully someone at blockchain.info can fix it.  Like I said, I could probably write php to get it, but I'm just not that motivated at the moment .

Is this the line I'm looking to change the call https://blockchain.info/blocks/P2Pool?format=json

I'll try this on an S3. I know Bitmain has their recs ('BTC address/256+256' or 'BTC address+256'.) for S3 P2Pool mining. Maybe I should give it a shot. I have been sticking with just payout address so far.

Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary.

This is if you use a public node...if you have your own it really shouldn't matter.

The concepts are the same but perhaps I should have posted that it is written with primarily scrypt miners in mind

So, yea the "low setting" caution statement is for coins that could incur large fees when sent due to low payout amounts (dust) to smaller miners. I do believe that the /0 setting overrides the minimum "dust" payout code written into p2pool so you might want to double check on that. Don't remember if I verified from reviewing the code but I'm relatively sure that's how it works....thinking about it though the minimum p2pool share difficulty is too high on BTC to matter...

On number 2
I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more.
Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners.
I think I read about custom changes to set diff per address. I really need to check into this. I guess the only other thing you can do is maybe suggest manual diff for high hashrate miners?

So I guess just stick it out and hope to get a share even if you're getting trounced.
(I just read some of the previous posts. Those snuck in on me. Makes more sense now)


O and thanks for all the info jbravo!

I've read through your FAQ.  Nice writeup.  I do have a few comments/questions for you.

1) You state that setting your difficulty to something silly low (like /0 for example) will have an effect on your payout.  I do not believe this to be true.  A submitted share from your miner means absolutely nothing to p2pool unless it is above the threshold difficulty, which currently sits over 4,000,000.  You can set your difficulty to /0 or /10 or /1000000 and it won't mean a thing.  Setting it to a value over 4,000,000 however, will have an effect.  I made a post regarding this a few pages back.
2) You are absolutely correct about the node's hash rate determining the difficulty for the miners, and if you're mining on a node where there is a very large discrepancy between you and the node's hash rate, you'll find shares less often; however, when you do find that share it will be worth more.
3) Where did you get the 0.00000116 value for setting pseudo-share?  I've seen that number passed around, especially for scrypt mining, and I forget the origin.  Also, is that number relevant to BTC, and if not, what is?  I do remember reading a thread about setting difficulty, but damned if I can find it now.

Thanks.

The problem is the expectation.  Remember, this is all completely luck-based.  The equations and formulas and everything else out there that provides you with things like "expected time to block" or "expected time to share" are nothing more than educated guesses based upon probability.  You could go for days without finding a single share, or you could find 100 shares in a day.  For example, I had an S1 mining on p2pool.  That S1 had been powered on for about 2 weeks and it found a block.  According to every calculator out there, it should have taken over 5 YEARS to find that block, yet I found it in about two weeks.

The thing is, you tend to notice this a heck of a lot more on p2pool than you do on any other pool.  Why?  Well, first off, because share difficulty is over 4M.  Secondly, because most every p2pool UI prominently displays numbers like "Expected time to share".  If you were mining a coin that had an extremely low difficulty and were finding thousands of shares a day, you would barely notice a swing of a few hundred shares up or down.  That's what mining on another pool is like.  You're far more *likely* to find a bunch of shares with a difficulty of 1024 than you are shares at 4M.

Variance can be a bear.  Over the past 24 hours we've had a total of 10 shares.  All of them were in hours 8-22, with no shares in the past 8 hours.  We're running a hashrate almost 20x your S3, so we should in theory expect a share on average in just over an hour.  sometimes we'll get a few in the span of an hour or two, then none for a while.