[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[AV]

2012-12-02 17:12:50.987000 > in download_shares:
2012-12-02 17:12:50.988000 > Traceback (most recent call last):
2012-12-02 17:12:50.988000 > Failure: twisted.python.failure.DefaultException: sharereply result: too long
2012-12-02 17:12:50.988000 Requesting parent share f024bcd1 from 24.108.77.4:9333
2012-12-02 17:12:53.795000 > in download_shares:
2012-12-02 17:12:53.795000 > Traceback (most recent call last):
2012-12-02 17:12:53.795000 > Failure: twisted.python.failure.DefaultException: sharereply result: too long

Always...

[1534674773]

1534674773

[1534674773]

1534674773

[1534674773]

1534674773

[1534674773]

1534674773

[1534674773]

1534674773

[forrestv]

P2Pool release 9.3 tag: 9.3 hash: f4a7b14a1314e0ada29b8a6d5fb9e2e52bb4dfe8

Windows binary: http://u.forre.st/u/asugseew/p2pool_win32_9.3.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.3
Source tarball: https://github.com/forrestv/p2pool/tarball/9.3

Changes:
* Fixes "sharereply too long" bug

[BR0KK]

nice i'll upgrade immediately

[rav3n_pl]

Pool wide DOA drop under 10%, looks like all troubles are gone.
Upgrade

[K1773R]

Pool wide DOA drop under 10%, looks like all troubles are gone.
Upgrade

Shares: 27 (0 orphan, 0 dead) Stale rate: ~0.0% (0-66%) Efficiency: ~124.7% (42-125%)

[cabin]

I just tried newest version from git overnight. And I have to admit, p2pool is still unusable for me. On my machine with 1GB RAM, p2pool is consuming 523 MB RAM (1002 MB virtual). I have some other processes running on my Debian machine and I cannot give away half of my RAM to p2pool, because of very high swapfile usage. Before v9 it was much lower and p2pool was running absolutely fine. I have to shutdown my node.

After the share reply problems (which were just fixed today) my memory did drop back down a bit, to around 350MB. Network usage does seem to be higher than before though. Not sure of that is low enough to stop the swapping though.

[ninjaboon]

Pool wide DOA drop under 10%, looks like all troubles are gone.
Upgrade

upgrading from 9.1 to 9.3 now...

[rav3n_pl]

Pool wide DOA drop under 5% but orphan rate in same time around 20%? See hourly stats now. Odd.

[PatMan]

Pool wide DOA drop under 10%, looks like all troubles are gone.
Upgrade

I'm seeing a pool stale rate of 24% still....

[rav3n_pl]

Pool wide DOA drop under 10%, looks like all troubles are gone.
Upgrade

I'm seeing a pool stale rate of 24% still....

Code:

Pool rate: 422GH/s (19% stale) Share difficulty: 740

but see hourly graphs:
DOA:7,5%
orphan: 12%
So sum will be 19%
I think this "stale" text should be changed to "DOA+orphan"

[PatMan]

Pool wide DOA drop under 10%, looks like all troubles are gone.
Upgrade

I'm seeing a pool stale rate of 24% still....

Code:

Pool rate: 422GH/s (19% stale) Share difficulty: 740

but see hourly graphs:
DOA:7,5%
orphan: 12%
So sum will be 19%
I think this "stale" text should be changed to "DOA+orphan"

Yup, that would make sense.

[rav3n_pl]

Pull request sent... ;]

[PatMan]

Pull request sent... ;]

It would be nice if there were two different texts, one for each. It would defo help noobs like me out....lol

[TAiS46]

will there ever be a BFL single support?

[eleuthria]

will there ever be a BFL single support?

You'd have to ask BFL that.  They're the ones who made a poorly designed FPGA that doesn't report back solves until the nonce range is exhausted, and can't be interrupted while doing so.

[TAiS46]

but all other pools are working with bfl singles?

[btharper]

but all other pools are working with bfl singles?

P2Pool generates a sharechain block every 10 seconds (on average) where the bitcoin blockchain only makes one block every 10 minutes (again, average).

The BFL single takes ~5 seconds to report back the work it computes.
On the full blockchain, or on work from pools this isn't a big deal since a share from five seconds ago is likely to be valid.
On P2Pool because of the lower block generation time a share from 5 seconds ago may or may not be valid, hence the high rejection rate (usually DOA iirc).

So to fix the problem BFL has to reprogram the singles to report back faster like GPUs or other FPGA units do, or P2Pool has to hardfork and use a longer time between blocks. Neither are particularly useful suggestions as changing P2pool for one manufacturer's mistakes is a lot of work for no reason, and a bad precedent; while getting BFL to update their firmware for an obsolete product is a waste of resources.

[K1773R]

@forrestv:
could you implement a way to print more details for such messages:

Code:

Merged block submittal result: True

something like this:

Merged block submittal for pool <POOLURL> result: True

[aTg]

Pool rate: 330GH/s (21% stale) Share difficulty: 577
Node uptime: 0.376 days Peers: 6 out, 1 in
Local rate: 39.1GH/s (62% DOA) Expected time to share: 0.0177 hours
Shares: 501 total (76 orphaned, 157 dead) Efficiency: 67.76%

I'm on version 9.3, which is going on?

[Rogue Star]

Pool rate: 330GH/s (21% stale) Share difficulty: 577
Node uptime: 0.376 days Peers: 6 out, 1 in
Local rate: 39.1GH/s (62% DOA) Expected time to share: 0.0177 hours
Shares: 501 total (76 orphaned, 157 dead) Efficiency: 67.76%

I'm on version 9.3, which is going on?

Have you tried restarting your miner(s)? I find it helps to restart after an upgrade.