Why does the BFL Single produce ~50% stales with P2Pool?

[norulezapply]

I've heard that the BFL single doesn't work with P2Pool as it produces about 50% rejected shares, which is insanely high.

Why is this?

Is it possible that the hashing is not actually being done on the chip itself? And it's just taking place on an external server then being submitted to the P2Pool node, which would maybe explain why the stale rate is so high due to network latency? (especially since BFL refuse to say what chip they are actually using in their Singles and they don't seem to fit any existing chip specification as far as I'm aware). I find it all a bit suspicious to be honest.

Thanks

Links stating that p2pool and BFL Singles don't play nicely:
https://bitcointalk.org/index.php?topic=60586.msg813269#msg813269
https://bitcointalk.org/index.php?topic=68379.msg815283#msg815283
https://bitcointalk.org/index.php?topic=68811.msg803408#msg803408

[1714787655]

1714787655

[Matthew N. Wright]

I've heard that the BFL single doesn't work with P2Pool as it produces about 50% rejected shares, which is insanely high.

Proof or

[norulezapply]

I've heard that the BFL single doesn't work with P2Pool as it produces about 50% rejected shares, which is insanely high.

Proof or

Proof from someone with a BFL Single running it on p2pool without 50% rejected shares would be better...

[Matthew N. Wright]

Proof from someone with a BFL Single running it on p2pool without 50% shares would be better...

Lacking proof Osama is alive means he's dead? Give me a break.

I'll link to the post where I read it produces 50% stales here when I find it - give me 5 minutes..

Try leading with that next time and you might find me much more receptive.

[norulezapply]

If you're not gonna be helpful why bother posting at all..

Links stating that p2pool and BFL Singles don't play nicely:
https://bitcointalk.org/index.php?topic=60586.msg813269#msg813269
https://bitcointalk.org/index.php?topic=68379.msg815283#msg815283
https://bitcointalk.org/index.php?topic=68811.msg803408#msg803408

[DeathAndTaxes]

The reason why isn't anything deceptive.

BFL singles hash an entire 2^32 nonce range all at once.  When the card finished it returns any found hashes.  2^32 nonces = 4 billion.  @ 800 MH/s that is 5 seconds.  p2pool has a very short LP interval of 10 seconds which means routinely before the BFL Single finished the data has gone stale.

GPU get around this (for other reasons) by using intensity.  They don't run full nonce range in one pass.  In cgminer for example 2^(15+intensity) hashes are processed in one "run".  So 400 MH/s GPU at intensity 8 will do 2^(15+8) = 8.4 million hashes at once.  8.4 / 400 = 0.021 seconds.  This means less shares go stale due to block change.

You can simulate the same effect (no idea if stable) by using an ultra high intensity in cgminer with a GPU.  400 MH/s GPU @ intensity 16 will also have an astronomical stale rate.

[Jaryu]

The reason why isn't anything deceptive.

BFL singles hash an entire 2^32 nonce range all at once.  When the card finished it returns any found hashes.  2^32 nonces = 4 billion.  @ 800 MH/s that is 5 seconds.  p2pool has a very short LP interval of 10 seconds which means routinely before the BFL Single finished the data has gone stale.

GPU get around this (for other reasons) by using intensity.  They don't run full nonce range in one pass.  In cgminer for example 2^(15+intensity) hashes are processed in one "run".  So 400 MH/s GPU at intensity 8 will do 2^(15+8) = 8.4 million hashes at once.  8.4 / 400 = 0.021 seconds.  This means less shares go stale due to block change.

You can simulate the same effect (no idea if stable) by using an ultra high intensity in cgminer with a GPU.  400 MH/s GPU @ intensity 16 will also have an astronomical stale rate.

so basically you must solo mine if using a BFL single then? or are there any pools where the LP is long enough that the Singles can shine on? I have a single 5970 (at the moment) on bitminter, but have some cash coming my way to get a couple of singles in a week or two and don't want to have it wasting time on a pool it won't work under.

[DeathAndTaxes]

Most conventional pools have an LP time of 10 minutes.  They never LP except on a block change.  Pools which merge mine (like Bitminter) have an LP interval of ~ 3 minutes (LP on BTC block change and roughly 2.5 LTC block changes per 10 minutes).

Pools could have more frequent LP and it is possible that at some point in the future LP could be used to update tx list when high value (fee) tx come in.  It is also possible BFL modifies their firmware to allow shorter intervals which eliminate the issue.

p2pool is kinda rare in that it has a VERY short LP interval and BFL single is kinda rare in that it has a very long batch interval.  That overlap is non-optimal.

[TheSeven]

The BFL Singles could actually report the shares asynchronously while still working on their current job, but their firmware is just too dumb to do that.
For regular pools the inefficiencies of this protocol cause the effective average valid hashrate to be around 1% below their nominal hashrate.
However for the P2Pool blockchain, which is ticking insanely fast, the effective average valid hashrate is around 26% below their nominal hashrate, just because of lacking asynchronous share reporting. Then there's relatively high latency due to polling and much overhead during work transmission, which hurts P2Pool badly as well. I, personally, don't have a BFL, so I don't have real-world measurements, but I'd say effective hashrate will be 40-60% below nominal, depending on how fast your host computer is, how aggressively the mining software is, connection latencies, etc.

BTW, the merged mining long polls don't count here because they should have set the "sendold" flag on pools/miners that support this.

TL;DR: They fucked up the firmware. Badly. In theory they can fix it though.

[Jaryu]

Most conventional pools have an LP time of 10 minutes.  They never LP except on a block change.  Pools which merge mine (like Bitminter) have an LP interval of ~ 3 minutes (LP on BTC block change and roughly 2.5 LTC block changes per 10 minutes).

Pools could have more frequent LP and it is possible that at some point in the future LP could be used to update tx list when high value (fee) tx come in.  It is also possible BFL modifies their firmware to allow shorter intervals which eliminate the issue.

p2pool is kinda rare in that it has a VERY short LP interval and BFL single is kinda rare in that it has a very long batch interval.  That overlap is non-optimal.

sorry, not sure I completely understood the whole explanation.

Since the single works the whole nunce in 5 seconds what is the minimum LP interval the pool needs to have that is effective to mine on with the singles at this current time that would make the singles shine?

[TheSeven]

The longer it is, the better will be your efficiency. But all pools (except for P2Pool) usually send important (non-sendold) long polls at the same time, so as long as you aren't using P2Pool you just don't have to care if your miner software supports sendold and the pool is working correctly.

[DeathAndTaxes]

There is always some overhead but at 10 min LP the overhead causes ~1% higher stale rate. 

At 10 second LP the overhead is more like a ~30%+ higher stale rate.

The Seven is right about "submitold",  For pools with merge mining if they are using "submitold" extension then it shouldn't have any worse stale rate than a non merge mining pool (on the BTC chain, NMC chain would be ~3% higher stales).  Also there are a couple ways BFL could "fix" the long interval.  Some are better than others.  Since BFL Singles use encrypted bitstreams only BFL can fix it (if they want to).  There is nothing at the miner or pool level that can fix it.

[Jaryu]

The longer it is, the better will be your efficiency. But all pools (except for P2Pool) usually send important (non-sendold) long polls at the same time, so as long as you aren't using P2Pool you just don't have to care if your miner software supports sendold and the pool is working correctly.

There is always some overhead but at 10 min LP the overhead causes ~1% higher stale rate. 

At 10 second LP the overhead is more like a ~30%+ higher stale rate.

The Seven is right about "submitold",  For pools with merge mining if they are using "submitold" extension then it shouldn't have any worse stale rate than a non merge mining pool (on the BTC chain, NMC chain would be ~3% higher stales).  Also there are a couple ways BFL could "fix" the long interval.  Some are better than others.  Since BFL Singles use encrypted bitstreams only BFL can fix it (if they want to).  There is nothing at the miner or pool level that can fix it.

Thanks for the explanation guys, much appreciated.

[bitpop]

Has this/will this be fixed soon?

[TheSeven]

Has this/will this be fixed soon?

Ask BFL. But until now they didn't seem to care at all?

[P_Shep]

Has this/will this be fixed soon?

Ask BFL. But until now they didn't seem to care at all?

at some point they did inquire about this. So they may well be working on something.

[norulezapply]

Has this/will this be fixed soon?

Ask BFL. But until now they didn't seem to care at all?

It'd be in their best interests to fix it, as I'm not purchasing until they do, so that's about $1300 they're losing out on atleast.

Hopefully it won't take long (unfortunately I can't say the same about their delivery times...)

[bitpop]

Wow, they are clueless, they are losing on $2,400 here

[rjk]

Wow, they are clueless, they are losing on $2,400 here

You make me laugh. There are people lined up down the street, pre-paying for something that will take forever to arrive (as of now), and have ordered so many that they are already on rev3, and you think your non-order will affect something? Not to mention those that have already plunked down 25, 60, 100+k for rig boxes.

[Matthew N. Wright]

Wow, they are clueless, they are losing on $2,400 here

You make me laugh. There are people lined up down the street, pre-paying for something that will take forever to arrive (as of now), and have ordered so many that they are already on rev3, and you think your non-order will affect something? Not to mention those that have already plunked down 25, 60, 100+k for rig boxes.

Meh. Money is money.

EDIT: I do question how much money and time(money) it would take them to make the necessary changes...that's assuming they haven't already been made