A guide for mining efficiently on P2Pool, includes FUD repellent and FAQ

[gyverlb]

Very interesting, we'll have to ask forrestv if there's something to be done.

I suspected CPU speed might be a factor, but not as much as that because I don't have a public node anymore: my node only generates work for a single payout address for all my miners (there's only one "New work for workers" line for each new share in my case). I don't know how much latency this is on my node but according to your log, if I were running it on your hardware it would be ~90ms (which isn't so bad: thats less than 1% of the average interval and less than other latencies).

So if we didn't miss something, for people hosting a public node P2Pool work generation is on average <n/2>x slower than private nodes where <n> is the number of payout addresses.

Not sure about why you are receiving more traffic than sending and how it could affect orphan shares.

I'll link your post in the main p2pool thread.

[1715627906]

1715627906

[GrapeApe]

I'm still trying to wrap my head around why having all of the outgoing nodes helps. I made some changes zvs suggested dialled back a little with 30 outgoing vs. 60 like him because of bandwidth limitations but I don't get it. I'm not disagreeing because so far so good on my end (still too soon for any real conclusion) but I'm definitely confused.

[gyverlb]

I'm still trying to wrap my head around why having all of the outgoing nodes helps. I made some changes zvs suggested dialled back a little with 30 outgoing vs. 60 like him because of bandwidth limitations but I don't get it. I'm not disagreeing because so far so good on my end (still too soon for any real conclusion) but I'm definitely confused.

If you are writing about the P2Pool outgoing connections, so many can only hurt. P2Pool is event based in a single thread: by raising the number of connections you raise the rate of events and the time it spends processing them and being unavailable to provide work for miners. It's probably not much time, but if there's no good reasons to have more connections you definitely want to avoid raising them.

As said in my latest update of the guide, raising the total number of connections above 12 (4 outgoing, 8 incoming) didn't raise my efficiency.

I suspect zvs initial tuning results have been collected with older bitcoin and P2Pool versions (zvs latest tests with 1MB block have shown inefficiencies, but AFAIK from his reaction not to the extent zvs expected them).
Different versions behave differently and tuning recommendations must be updated (for example I did witness bad efficiencies with old P2Pool version when getblocktemplate was >0.2s and can't reproduce it anymore even with 0.5s).
I try to explain the process I follow in the guide so that people can try to find their own settings by themselves if my recommendations aren't optimal for them.

[zvs]

I have tons of outgoing connections, I don't get many orphans.  That's the point of all the connections.

Right now I have 1 in 47, and that one occurred at the very end of that 1,000,000 blocksize test...  prior to that, I had the 3 orphaned out of 256...  

6 outgoing connections only certainly isnt optimal, especially if you aren't listening for incoming connections... but, then, I only have 11 so far after node being online for over 12hrs.   One of them connects within seconds (*cough* p2pool-node).  Relying on 6 random outgoing connections to not get orphans?   Some crap shoot


oh, here's a good example of why you should at least do like 2500 block size:

New work for worker! Difficulty: 5.000000 Share difficulty: 1218.324058 Total block value: 25.915000 BTC including 3 transactions

[gyverlb]

I have tons of outgoing connections, I don't get many orphans.  That's the point of all the connections.

Right now I have 1 in 47, and that one occurred at the very end of that 1,000,000 blocksize test...  prior to that, I had the 3 orphaned out of 256...  

6 outgoing connections only certainly isnt optimal, especially if you aren't listening for incoming connections... but, then, I only have 11 so far after node being online for over 12hrs.   One of them connects within seconds (*cough* p2pool-node).  Relying on 6 random outgoing connections to not get orphans?   Some crap shoot


oh, here's a good example of why you should at least do like 2500 block size:

New work for worker! Difficulty: 5.000000 Share difficulty: 1218.324058 Total block value: 25.915000 BTC including 3 transactions

zvs, you only work by feeling, not stats. Feelings aren't good advisors...

1/
I've studied "6 random connections" for weeks and got 105+ efficiency constantly and most of the time 110+. It works, there's nothing to discuss if you didn't test it and then got bad efficiency repeatedly for days. Nothing is set in stones and things may change in the future, but right now there's no reason to advise to use large amount of connections unless you have hard data showing meaningful efficiency differences. There's one obvious reason to advise against it : it uses bandwidth that is limited: you use a dedicated server where it could be OK (additional CPU usage might make it bad) but many like me use an ADSL connection where it would simply kill efficiency (tested).

2/
your example of 25.915BTC with 3 transactions is just that, an example. Unless things changed dramatically these past days, there's no way you will get this amount of fees constantly with only 2500 block size. And even if it was the case, you'll have to compare both efficiency and fees to what you get with blockmaxsize=1_000_000 and other values to decide if it's advisable to use such a low block size.

[zvs]

I have tons of outgoing connections, I don't get many orphans.  That's the point of all the connections.

Right now I have 1 in 47, and that one occurred at the very end of that 1,000,000 blocksize test...  prior to that, I had the 3 orphaned out of 256...  

6 outgoing connections only certainly isnt optimal, especially if you aren't listening for incoming connections... but, then, I only have 11 so far after node being online for over 12hrs.   One of them connects within seconds (*cough* p2pool-node).  Relying on 6 random outgoing connections to not get orphans?   Some crap shoot


oh, here's a good example of why you should at least do like 2500 block size:

New work for worker! Difficulty: 5.000000 Share difficulty: 1218.324058 Total block value: 25.915000 BTC including 3 transactions

zvs, you only work by feeling, not stats. Feelings aren't good advisors...

1/
I've studied "6 random connections" for weeks and got 105+ efficiency constantly and most of the time 110+. It works, there's nothing to discuss if you didn't test it and then got bad efficiency repeatedly for days. Nothing is set in stones and things may change in the future, but right now there's no reason to advise to use large amount of connections unless you have hard data showing meaningful efficiency differences. There's one obvious reason to advise against it : it uses bandwidth that is limited: you use a dedicated server where it could be OK (additional CPU usage might make it bad) but many like me use an ADSL connection where it would simply kill efficiency (tested).

2/
your example of 25.915BTC with 3 transactions is just that, an example. Unless things changed dramatically these past days, there's no way you will get this amount of fees constantly with only 2500 block size. And even if it was the case, you'll have to compare both efficiency and fees to what you get with blockmaxsize=1_000_000 and other values to decide if it's advisable to use such a low block size.

First off... no kidding, there usually isn't some 1 BTC fee transaction that's 250 bytes in size.  Sometimes there is.  Are you arguing that I drop that down to 1500?    1,000,000 obviously is detrimental to *my* income, so why would I use it?  

You need to do some more studying if you think 6 random connections will get "105+ efficiency constantly and most of the time 110+".  I could possibly see a modified source allowing 0 outgoing connections and then 6 chosen connections added via --p2pool-node getting a low # of orphans

i would like to see this mythical node of yours, it isnt listed on http://p2pool.hostv.pl/  for sure.

[gyverlb]

i would like to see this mythical node of yours, it isnt listed on http://p2pool.hostv.pl/  for sure.

You demonstrated that running a public node hurts efficiency by delaying work delivery to miners and you want me to do it?

The worker port is blocked by my firewall, I used to have a public node in 2012 but when I started studying how p2pool behaves in various conditions I blocked the port to avoid any unwanted perturbation (I was worried about bandwidth usage at the time and it seems I should have been worried about P2Pool process delays).

No need to take my word for it or doubt it, just test it yourself and publish your data here for everyone to see and try to reproduce. If your results don't match mine we'll have to find our why: your last test with 1MB blockmaxsize was enlightening and made me create a github issue.

My current configuration for BTC P2Pool is 10 connections (5+5). One month ago it was 6 (3+3). I see the current additional 4 as a safety margin in case P2Pool's behavior changes or my node connects to several "bad" nodes at the same time (6 has been enough and is the lowest I consider relatively safe, I'm advising to use slightly higher values if possible in the guide and follow my own advice and prefer to have a margin when I'm not actively collecting efficiency numbers).

I'm about to test a different setting: less outgoing and more incoming to help people behind firewalls who can't forward ports and see if it lowers my efficiency.

[zvs]

Just for the record, it did this again:

2013-06-19 19:14:17.235456  Shares: 117 (2 orphan, 3 dead) Stale rate: ~4.3% (1-10%) Efficiency: ~121.5% (114-125%) Current payout: 0.3549 BTC
2013-06-19 19:14:19.021332 Skipping from block a3c01ac1b7431fe4f3b141091650172a0ca3f147ad5472ebe8 to block 44635c8d256559a4bbd27e36c84c0b1349102cfc99fd5645c7!
2013-06-19 19:14:19.421899 Punishing share for 'Block-stale detected! a3c01ac1b7431fe4f3b141091650172a0ca3f147ad5472ebe8 < 44635c8d256559a4bbd27e36c84c0b1349102cfc99fd5645c7'! Jumping from 0ed16b1a to 68f2aca3!
2013-06-19 19:14:21.264227 GOT SHARE! Drizztztzzztztzzzzztzz b9803115 prev 0ed16b1a age 2.22s DEAD ON ARRIVAL
2013-06-19 19:14:27.240538  Shares: 118 (2 orphan, 3 dead) Stale rate: ~4.2% (1-10%) Efficiency: ~121.6% (114-125%) Current payout: 0.3576 BTC
2013-06-19 19:14:37.245425  Shares: 118 (2 orphan, 3 dead) Stale rate: ~4.2% (1-10%) Efficiency: ~121.3% (114-125%) Current payout: 0.3576 BTC


though that time it said DOA, but gave me credit for it.

so I guess maybe it's messed up sometimes when that's going on.  maybe in a few of those other cases the same thing happened

though I wonder what '68f2aca3' was. scratch.

[GrapeApe]

Both of you guys have been extremely helpful to me so I'm reluctant to get in the middle here but isn't that what happens when you submit work for an old block.I found this in my log...

[2013-06-19 19:14:18] Stratum from pool 0 detected new block

edit: I realize I could have nothing useful to add here you two obviously are in a different league than me.

edit2: I'm sorry I do see your point now what did happen to '68f2aca3'?

[zvs]

Both of you guys have been extremely helpful to me so I'm reluctant to get in the middle here but isn't that what happens when you submit work for an old block.I found this in my log...

[2013-06-19 19:14:18] Stratum from pool 0 detected new block

edit: I realize I could have nothing useful to add here you two obviously are in a different league than me.

edit2: I'm sorry I do see your point now what did happen to '68f2aca3'?

that's the big question 

i didn't build off of 68f2aca3...

[notme]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

[gyverlb]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

[notme]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

Well, in the link we have an example of a Jalapeno in the wild running on a p2pool instance with better 100% efficiency.  But thanks for ignoring it.

[gyverlb]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

Well, in the link we have an example of a Jalapeno in the wild running on a p2pool instance with better 100% efficiency.  But thanks for ignoring it.

Don't post inaccurate information and I won't ignore it. You reference a post quoting an assertion that is clearly bullshit: "these guys claim the ASICs blow through an entire nonce range in a few ms". Why do you still expect me to waste my time with a post like this when I clearly explained it was impossible 2 posts earlier?

Now a newbie user (seems to be the same) claimed in the P2Pool thread that he got 106% efficiency after enough shares that it shouldn't be a fluke so I'll update my guide to reflect that. But I certainly won't write that BFL Asics are working properly, only that they might: between a newbie report I don't know at all and ckolivas' report there's clearly a difference in trust.
This would change if for example ckolivas confirmed that his device is working properly and he made a mistake in his earlier tests, there's a new firmware for BFL ASICs solving early problems or there are some other trusted user reporting good efficiency.
Currently I have conflicting reports with the most trusted user claiming it doesn't work properly with p2pool and a newbie I don't know claiming otherwise, like I said in my earlier post... do the math!

If I were in your shoes, I'll look for an explanation for why ckolivas' ASIC didn't work like it should or find trusted members of the forum to verify the newbie's claim. I'm only collecting information here, if there isn't enough information I can't do much.

[bitpop]

I too got 106% efficiency, without jalapeno 115. Using slush to be safe for now hoping for a fix. I'll be back either way.

Many many rejects but I guess it didn't matter

http://imgur.com/EOVlFrm

Im wrong, it was skewed by 10ghs of other miners. Only 10/20ghs was jalapeno.

[gyverlb]

Guide updated for conflicting reports about BFL ASICs and one success report for ASICMINER Block Erupter blades.

[gigq]

Guide updated for conflicting reports about BFL ASICs and one success report for ASICMINER Block Erupter blades.

Hi, I'm the newbie mentioned.  Thanks for updating the guide with my findings.  Hopefully more users will try their BFL ASICs on P2Pool as they get them and we can get more evidence either way.

FWIW my local DOA rate is high (Local rate: 5.64GH/s (22% DOA) Expected time to share: 0.206 hours) but my efficiency has been fine (Shares: 43 total (3 orphaned, 3 dead) Efficiency: 105.6%).  The only change I have done over stock cgminer is I run it with username/6000 to increase the share difficulty.  This was suggested by a user on the BFL forums.

If you have any questions or want me to share anymore information I'd be happy to.

[notme]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

Well, in the link we have an example of a Jalapeno in the wild running on a p2pool instance with better 100% efficiency.  But thanks for ignoring it.

Don't post inaccurate information and I won't ignore it. You reference a post quoting an assertion that is clearly bullshit: "these guys claim the ASICs blow through an entire nonce range in a few ms". Why do you still expect me to waste my time with a post like this when I clearly explained it was impossible 2 posts earlier?

Now a newbie user (seems to be the same) claimed in the P2Pool thread that he got 106% efficiency after enough shares that it shouldn't be a fluke so I'll update my guide to reflect that. But I certainly won't write that BFL Asics are working properly, only that they might: between a newbie report I don't know at all and ckolivas' report there's clearly a difference in trust.
This would change if for example ckolivas confirmed that his device is working properly and he made a mistake in his earlier tests, there's a new firmware for BFL ASICs solving early problems or there are some other trusted user reporting good efficiency.
Currently I have conflicting reports with the most trusted user claiming it doesn't work properly with p2pool and a newbie I don't know claiming otherwise, like I said in my earlier post... do the math!

If I were in your shoes, I'll look for an explanation for why ckolivas' ASIC didn't work like it should or find trusted members of the forum to verify the newbie's claim. I'm only collecting information here, if there isn't enough information I can't do much.

I'm sorry I didn't do the digging to figure it out for you.  It appears it is raising the share difficulty that saves your efficiency.  I just figured you were the expert and could figure it out easier.  Sorry for wasting your time.  I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.

[gigq]

Here are some screen shots of my P2Pool and cgminer output if they help:

http://imgur.com/a/cfqgK

[zvs]

Here are some screen shots of my P2Pool and cgminer output if they help:

http://imgur.com/a/cfqgK

do you have to use stratum?   it has some 1/2 second delay or so for me

it looks like whatever you're using has 1500-2000ms latency.  so we'll be optimistic and consider that 15% DOA.     now, can you set up your pool so you have 5% or less orphans?  probably not with 6 outgoing connections and 0 incoming

i don't understand why people run pools locally when they'd be better off using a remote server.  i ran mine locally for about 2 days