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

Graphs on http://p2pool.info/ are not working  

UPDATE: fixed

yah, it 'makes' it submit stales, since p2pool stales arent network stales

and orphans are much worse than DOA, in most cases DOA is just a matter of your latency to wherever you are mining at, orphans means wherever you are mining at isnt propagating it's shares fast enough (or occasionally you'll get screwed when someone that was rly slow happens to get two in a row)

i use more resources using my home computer for essentially the same % of lost shares as I get mining at nogleg.  they're just orphans instead of DOA.   but if you're some person that wants to mine at a remote pool, you certainly wouldnt want to mine at my home pool getting all the orphans, since then you'd still get just as many orphans + the DOAs associated with your latency

cgminer respects the pool message telling it to submit stales.

Thanks. I'm not even sure submit-stale does anything in cgminer any more, maybe it is the p2pool telling cgminer to submit stales. either way, glad its recommended.

stales (including doa and orphan shares) are when you submit a share that isn't included in P2Pool's sharechain. DOA are because your miner was working on obsolete dat, orphans are because some other node managed to publish a share at roughly the same time than yours and the P2Pool network chose his share instead of yours.
Both type of stales don't reduce your income unless you have more than the average miner (as both can generate blocks which will have their income distributed to everyone).

There's a bit more info in the guide in my signature and on the wiki.

Ok so I had it set right. Yeah it would be dumb punishing something you could just hide. So where do stales and doa come from? A valid can just be late?

P2Pool actually asks for stales as they can be valid blocks. There's no reason it would punish you :-)

Ah, ok.  I just read their (apparently incorrect) documentation on the protocol for SC devices.  My bad.  

Given this, nothing can be done to make these devices work with p2pool effectively short of changes by ButterflyLabs.

1. Fuck bfl, suck bird dick

2. I'm using lancelots and I remember setting cg miner to submit stales. Am I punished by p2pool for submitting stales? These are the rejected ones .1s after stratum.

I'll update the guide mentioning these problems.
As long as a device doesn't support being fed new work to switch to with nearly no latency or work on short nonce ranges with at most 0.1s spent on them P2Pool payouts will start to be noticeably decreased (>1% lost income).
IIRC BFL did know about this in the early days, there were discussions of the ZPX command or an equivalent last summer for their ASICs. Guess they simply don't care about such details.

More like drowning in stolen money, lol

2-3% doa with 0.165s at default setting on 0.8.2 version
for the moment it seem that income are lower...

BFL_StevenM did say something in the chat about reviewing some FPGA wake script for the ASICs yesterday. What exactly, and why nobody has gotten back to you or others, I dunno.

Check the BFL forums. We asked them why they didn't implement the command because we tried it and it doesn't work on BFL SC devices.

They did not respond. I think BFL are too busy drowning in fail to respond to petty questions like these.

Ah, I assumed cgminer was doing something optimal-ish! I'm going to write a BFL interface within P2Pool for testing to see how much better it can get.

I had some free time tonight so I tried this.  My intent was to run a 24 hour long test to see if there were problems with p2pool or cgminer going crazy and blowing up, as I believe was reported with previous attempts with ASIC devices.  However, I aborted my test after an hour when it was apparent that Jalapeno devices can not be effectively used with p2pool.  In fact, I see now that forrestv reported the same problem that I ran into just a few posts up in the thread, and I didn't notice that detail until now.

The problem is the same as with the BFL Single FPGA devices.  Immediately after a p2pool share is found and stratum signals that new work should start (or a longpoll occurs), the Jalapeno will have a tendency to submit several stale shares (DOA in p2pool terms) because the BFL chips can't be interrupted mid-work and so they keep working on the old work for a couple seconds after stratum has signaled to start on a new work item.  The result is approximately 20% DOA and a 20% drop of effective hashrate, which makes a Jalapeno pretty much unusable with p2pool for anyone that cares about their earnings.

Although the BFL SC devices supposedly support the ZPX command that was added for MiniRig FPGA devices to allow it to work on shorter nonce ranges (and therefore wake up for new work much more frequently and therefore have much lower DOA %), neither cgminer nor bfgminer (I tried them both) use this command with the BFL SC devices and instead use the ZNX queue command.  With any other pool, ZNX is a better choice because it will minimize idle time of the hardware.  But with p2pool, ZNX is likely worse than ZPX would have been.  In a perfect world, BFL would have added a "partial nonce" version of the ZNX command so that we could have queued work items and smaller nonce ranges, but that isn't the case.

So, the verdict, at least for jalapeno devices, is that they are essentially unusable with p2pool and there is nothing that p2pool can change (other than something drastic like not having shares every 10 seconds) to make it work.  Perhaps if cgminer supported switching to ZPX things might get a little better, but there would still almost certainly be a reduction in hashrate as compared with other pools that were compatible with the more efficient ZNX command.

I'm not sure how things will turn out with the 60 GH/s SC Singles, but my guess is they will have exactly the same problem and it won't matter that they are faster because they are really just more of the same ASIC chips working in parallel and each chip is still going to be testing an entire nonce range before returning any results.  But I am not entirely confident on that, so I will certainly retest this when mine arrive in 4-6 weeks.

Edit: Also, perhaps obvious is that it's possible the same problem with the CPU spiking would have eventually happened to me and I just didn't bother waiting long enough.  So I think it is unclear if the problem that ckolivas saw with p2pool a while back still exists with the latest versions of bitcoind and p2pool.

Hi guys. I am not sure if this counts as a bug in p2pool or not but we are apparently adding a "strange" zero value transaction output at the end of our payouts. This affected a wallet app (that has since been fixed).

Details here:

https://bitcointalksearch.org/topic/m.2327217

Good to know...thanks for the reply!

My primary goal will be to confirm or not the reports that it doesn't actually work.  If it has problems, then we can explore options to debug.

I couldn't test it with getblocktemplate latencies higher than 0.25s. But I suspect you should be fine with much larger values: people here had 30s latencies with 0.8.1 and IIRC mot of them didn't see efficiency plummet like it would have if this latency mattered anymore.

I believe this latency only matters for blocks generated just after another: p2pool probably uses an empty template in this case until it gets an answer from bitcoind (forrestv, can you confirm this?). So unless it becomes a substantial portion of the 10min block interval that shouldn't be a big problem for P2Pool's income, it would reduce the total tx fees a bit that's all.