Topic: NastyPoP vs Standard P2Pool - page 3. (Read 17655 times)

Sorry for the few day delay on the updates, but before I get to the numbers, I'd like to take a moment to thank you, kano, for the analysis.  You've certainly addressed one of the issues of the decentralized nature of p2pool: reliance upon who-knows-what kind of hardware and connections and bandwidth across the network.  Because there are no real minimum requirements to setup a p2pool node, pretty much anybody who wants to do so, can.

This week I switched over to TheAnalogKid's node, located right up the road from me.  The switchover was completely seamless as the work I'd done on the NastyPoP was tracked and kept right on going.  From my perspective, the only way a miner would even know if he'd moved from the US to EU or back is that on the nastyfans miner status page, a new graph appears.

Speaking of those graphs, it sure would be nice to see the share lines colored differently for dead and orphaned shares.  Currently a miner cannot tell if a submitted share-chain share was accepted.  For example, the first 3 or 4 share-chain shares I submitted on the US node were likely either dead or orphaned.  Of course, it could have been that previous shares were dropping off the chain right as the new ones were being found.  I couldn't tell, and that's why I'd like to see a visual representation... say red for orphans and purple for dead.

Alright, onto the numbers... my NastyP2P miner suffered some dead/orphaned shares (I think) at the beginning of the week, and the payouts reflect it.

3/20 - 3/27
NastyPoP - 0.02843568BTC
NastyP2P - 0.01970915BTC
Expected - 0.033BTC
Luck - 90.54%

OP updated

Av 24ms vs Av 112ms

Lets see what those number actually mean

0.024s out of an average of 30s per share-change means that you'd expect about 0.08% rejects
0.112s out of an average of 30s per share-change means that you'd expect about 0.4% rejects

So 4.7 times a small amount ... seems to also be a small amount in this case.

What share-chain rejects do you actually get in p2pool? Around 7% 10% 13% ?
So clearly in this case the affect of that latency change shouldn't really make too much difference on finding share-chain shares

So the main problem would appear to be from the p2pool nodes to the other p2pool nodes ..........

We know on the blockchain the sort of network round time for blocks and thus expected orphan rates.
We know that pools with crappy connections and crappy software get more orphans than those without.
But on a normal pool that doesn't affect the shares (and is also happens 1/20th less often ... 600s vs 30s)

On p2pool it's the fact that ALL your share-chain shares are dependent upon that "network round time" that is also full of all sorts of quality hardware/network setups from good/maybe even good pool quality? down to crap performance/network connection quality.

Hmm, this should probably be in the p2pool thread, but it's a reply to your numbers

nonnakip and TheAnalogKid, that's great news!  Not losing your share count when moving from the US to EU and back is a big win.

EDIT:

Just some info about the US node hosted by TheAnalogKid... ping:


EU ping:


I'm going to move my miners to be primary at the US node and backup on the EU and continue the tests.  By the way, are the graphs/stats still hosted on the main site (nastyfans.org) or would miners pointed to the US node look there to see graphs and stats?

Never mind, I see that the stats show up separately on the nastyfans.org site.

I'll confirm (for what it's worth )that during testing things worked across nodes as expected.  I had miners pointed to both nodes with the same registered address, and my hashrate and share count reflected as it should, even after failovers or manual switches between nodes.

I've re-pointed all my miners now to the US node with the original EU node as failover, works well.

All NastyPool nodes work together. If you switch to a different node you will see your stats appear on a separate graph and listed separately on the NastyPoP tables. But when it is time for a distribution all hashes are combined on all nodes.

In the future the charts and tables will show what node the miner is using. This will clarify things. There are also a few other display issues to work out. But the real data is correctly tracked and that is the important thing.

Be free to switch back and forth between nodes as you wish. Your hashes will be counted correctly. Some miners set up the USA node as a backup.

Another week has passed.  P2Pool had just over 100% luck for the seven days, and you can see the NastyPoP payout was very close to the 101.66% of expectations.  The S3 running on the standard node did a bit better, as it had a nice lucky streak right before the block was found yesterday.

In other news, TheAnalogKid has opened up a US node for OgNasty that runs both the standard NastyP2P as well as the NastyPoP payouts.  It'll be interesting to see how, if at all, the data is shared between the US and EU nodes for the NastyPoP payouts.  Does it transfer, or would it be ramping up just like starting over on any other PPLNS pool?

3/13 - 3/20
NastyPoP - 0.03402797BTC
NastyP2P - 0.05156673BTC
Expected - 0.0327BTC
Luck - 101.66%

OP is updated.

Well, p2pool had a good week, and payouts from both NastyPoP and NastyP2P reflected that, each beating expectations.  NastyP2P managed to edge out NastyPoP, but the difference between the two is only 0.00770503BTC.

3/6 - 3/13
NastyPoP - 0.05138458BTC
NastyP2P - 0.05908961BTC
Expected - 0.0328BTC
Luck - 131.5%

OP updated.

Another lousy luck week for p2pool in general - 7 day luck shows 51.98%.  2 blocks found.  My S3 running with p2pool payouts was all over the board during the week at one point expecting to get nearly 0.02BTC if a block were found... to 0.003BTC per block.  Unfortunately, when the blocks were found, it had fewer than expected shares on the chain and the results suffer for it.  My S3 running with NastyPoP actually made more than I thought it would.  Here are the week's results:

2/27 - 3/6
NastyPoP - 0.02048889BTC
NastyP2P - 0.00942830BTC
Expected - 0.0332BTC
Luck - 51.98%

OP updated.

Yet another week has passed.  P2Pool started off strong, but has stalled for the past 3.5 days.  Luck shows just over 100% for the past 7 days.  Here are this week's results:

2/20 - 2/27
NastyPoP - 0.03798674BTC
NastyP2P - 0.04202049BTC
Expected - 0.0338BTC
Luck - 100.64%

Updated the OP

I used a p2pool with 200ms latency for at least half a year.  

Bitcoin should have less interrupts than DOGE, but since DOGE is the one I remember.... DOGE had one minute block time avg.  I don't remember for sure, but I think it also had 15s share time in p2pool.  So on average, you'd get 5 interrupts a minute.  At 200ms latency, that means at worst you'd be sent some new work, 0.00001ms later there would be a new share/block, requiring the server to send you some new work.  So then you have the 200ms to receive the work, then 200 + a few more ms before you start sending this work back, just call it 400ms.  Five interrupts a minute = 2000ms = 2 out of 60 seconds = 3.33% DOA.  Bitcoin has less interrupts.  Two shares per minute, right?  Then the block that's supposed to be every 15m but on increasing difficulty is a bit faster.   So you're talking less than 1.5% DOA there.

anyway, lower orphan rate of having the pool in Europe more than made up for that for me....  though if I was in Europe, I probably wouldn't be too keen on using a p2pool in the US or Asia, since most the (good) p2pools are hosted in datacenters in germany, france, or the netherlands.

And..... another week gone by with p2pool only finding a single block.  Ouch!  My S3 on the standard p2pool payout was a bit lucky and found more shares than it should have, so at least there was a small bit of consolation.

2/13 - 2/20
NastyPoP - 0.00698833BTC
NastyP2P - 0.01822003BTC
Expected - 0.0348BTC

I almost don't even want to bother posting results this week since p2pool found exactly 1 block.  7 days.  1 block.  Ouch, this past week has been some absolutely horrific luck, and of course this past week was the week I thought I'd rent out some significant hashing power.  Yeah, I gambled and lost... and lost big.  If you had asked me last week at this time if I thought p2pool would only find a single block all week I would have said not likely at all.  But here we are, and it did indeed happen.  Am I disgruntled?  A bit .

NastyPoP - 0.00435959BTC
NastyP2P - 0.00938869BTC
Expected - 0.0361BTC
Luck - 14.3%

OP updated as well.

Week of 1/30 to 2/6 saw my S3 on the standard p2pool suffer.  It hadn't found a share for nearly 5 days, which caused it to miss quite a few block payouts.  Also, as promised, nonnakip compensated for the mistake in share counting from the previous 2 weeks.  As a result, NastyPoP payouts crushed standard p2pool payouts for my miners this week.  Here are the numbers:

NastyPoP - 0.05905592BTC
NastyP2P - 0.02003162BTC
Expected - 0.0375BTC
Luck - 93.32%

As usual, OP updated with this week's numbers.

Week of 1/23 - 1/30 was very close between standard p2pool payouts and NastyPoP for my S3s.  P2Pool itself was down on luck for the week, so neither standard p2pool nor NastyPoP hit expected earnings.  Numbers:

NastyPoP - 0.01963295BTC
NastyP2P - 0.02061486BTC
Expected - 0.0361BTC
Luck - 81.85%

OP updated with the week's numbers.

R.I.P. 

Thanks for the update.  I'll adjust the test numbers when the corrections are sent.

Just a quick update... it looks like Nonnakip double-spent the coins and as a result I received the payout from last week's mining on NastyPoP.  Thanks!  I wasn't expecting the payout until tomorrow, so it was a nice surprise .

Anyway, now that the payout has been received, here are the results for the week of 1/16 - 1/23:

NastyPoP - 0.02833329BTC
NastyP2P - 0.03989456BTC
Expected - 0.0352BTC

I didn't capture the 7 day luck last Friday, so I don't have it to report unfortunately.  There have definitely been some growing pains with the adoption of ckpool as the front end for NastyPoP, and the payout reflects it.  Downtime, restarts, etc contributed, and the lower payout is the result.  Things have gotten a tad more stable this week, so we'll see how it stacks up tomorrow.

OP updated with the results.

Edit: you'll notice that I am not including numbers for a miner on my own node any longer.  Last week when I was traveling for work I noticed that the miner had gone down.  When I returned home, I found the miner had hashed its last hash.  Oh well... it was an early batch S3 that's long since paid for itself.  Moving forward, I'll be running the test only showing the results of standard p2pool payouts vs NastyPoP with both S3s pointing to nastyfans.org.

I begin with many thanks to jonnybravo0311. Your work here is excellent. The transparency of the fanclub and pool allows people to have a critical eye. This is to our benefit. Because we are human and we make mistakes.


The issues do not exist now because I go back to direct P2Pool. But you are very correct that the past days were very wrong.

• the new CKPool frontend introduced unexpected performance issues (despite very successful testing)
• the payout distribution software mistakingly counted all CKPool-based mining as nastyfans donations
• the distribution transaction was classified low priority and may never be processed

I think the failed transaction processing is a blessing because the transaction contents are wrong. So instead of me adjusting the next payouts and documenting all this errors to compensate for this mishap I will double-spend the correct amounts.


You need to be aware that we try running CKPool in a mode (proxy mode) that is not used by other great CKPool-based pools. I do not know if any other pools use this mode. And particularly as a P2Pool frontend. This means NastyPool may trigger problems that exist only for us.

I am grateful to ckolivas for his support during our (unfotunately unsuccessful) integration. I am convinced that CKPool is the correct choice as a pool frontend for NastyPool.


Your concern is legitimate. And it is obvious I must improve how data is displayed. As OgNasty already mention the P2Pool-based and CKPool-based mining is shown separate. This was not technically mandatory. But I wanted this so everyone could keep eyes on statistics. The payout transaction did not include your CKPool-based hashes. This was a error.

I now fixed the distribution payout software and re-run for last distribution. For last mining window 1CVFuGmhMfQJ5hTyYe8fWtKPKNWVpNe8dE will receive 0.02833329 BTC. I plan to double-spend the Bitcoin soon.


I will.

Unless I'm mistaken, it is an 8kb transaction with a 0.0008 BTC transaction fee.  That is the recommended fee, right?  It does appear to me that a combination of young inputs and small outputs are causing the delay.  It will be interesting to see if it gets processed before having to be double spent on Friday.