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

[Rassah]

With the block halving, my profit is gone, and I had to shut down my miner. I still have Bitcoin-qt and P2Pool running, thinking having a full node available will help other P2Pool users somewhat (have about 24 incoming connections). Someone let me know if I'm wrong about this?

[1713996569]

1713996569

[1713996569]

1713996569

[1713996569]

1713996569

[sharky112065]

forrestv: Much better latest git master after 6.5 hours.
Version: 9.1-5-gb016b6b Node uptime: 0.415 days Peers: 10 out, 24 in
Shares: 89 total (5 orphaned, 3 dead) Efficiency: 121.9%
Still got 27 Get Fails in that 6.5 hours, but no Rem Fails.
2.9% Rejects which is also much better.  

Edit:
htop at start showed 485M RES and 636M VIRT
htop after 6.5 hours  622M RES and 775M VIRT

Watching for 5 minutes I never saw CPU go over 56% Most of the time it is 20 or lower.

Still need to figure out why we get so many Get Fails. I know it is not hardware. I have a really fast server (lots of RAM, 8 CPU cores, and 16TB free space on Hardware Raid 6 ) and a fast Internet connection.

I got 2 Get Fails on solo with bitcoind in 24 hours for comparison.

[AV]

I have two subnets.
Each subnet running bitcoind, but wallet.dat used in both cases is the same.
Also in each subnet running p2pool.
Can I setup two subnets are the same address for the award?
Are there problems?

[K1773R]

I have two subnets.
Each subnet running bitcoind, but wallet.dat used in both cases is the same.
Also in each subnet running p2pool.
Can I setup two subnets are the same address for the award?
Are there problems?

no this is fine

[forrestv]

P2Pool release 9.2 tag: 9.2 hash: b016b6b522286e4675b82b9c4206784937977f3e

Windows binary: http://u.forre.st/u/hvxnplnd/p2pool_win32_9.2.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.2
Source tarball: https://github.com/forrestv/p2pool/tarball/9.2

Changes:
* Fixed some really inefficient checks

This has been confirmed (more or less) to help reduce your stale rate.

[BR0KK]

Stale rate is still pretty dam high

Code:

Version: 9.1

Pool rate: 335GH/s [b](23% stale) [/b]Share difficulty: 522

Node uptime: 1.640 days Peers: 6 out, 2 in

Local rate: 3.81GH/s (5.9% DOA) Expected time to share: 0.163 hours

Shares: 216 total (39 orphaned, 13 dead) Efficiency: 98.28%

[Prattler]

P2Pool release 9.2 tag: 9.2 hash: b016b6b522286e4675b82b9c4206784937977f3e

Changes:
* Fixed some really inefficient checks

This has been confirmed (more or less) to help reduce your stale rate.

Before the switch DoA was at 1.5%. After the switch it climbed up to 5.2%. The latest fix brought it down to 2.5%.

CPU usage still seems high and p2pool is using 1.4 GB RAM, so hopefully there is still place for improvement

Comparing p2pool block receive times and blockchain.info times shows that 250 kB blocks are now distributed in 0-2 seconds. This is amazing!

[Aseras]

9.2 is giving me a 100% orphan rate Last 10 shares in a row are orphans.. rolling back.

[mdude77]

I grabbed the latest git this morning that includes the efficiency patch, that is the big change in 9.2.  After about 14 hours, I'm still looking at 24% stale rate.  However, cgminer is now reporting about 3% rejects, where before it was 10% - 20%.  So I think the stale rate is because of my conn problems.

M

[BitCoiner2012]

Was using 9.0 fine and suddenly on reboot was spammed with this message and it closes instantly when using:


https://i.imgur.com/W4We3.png

Now I downloaded 9.2 just in case, but it connects quickly, but never do my miners seem to connect.. not even on the host machine. Anyone..?

[Aseras]

9.2 is giving me a 100% orphan rate Last 10 shares in a row are orphans.. rolling back.

Double verified 100% orphan on 9.2. 20 more shares instant orphan.

9.1 and 9.0 are both fine though...?

[Aseras]

Was using 9.0 fine and suddenly on reboot was spammed with this message and it closes instantly when using:


https://i.imgur.com/W4We3.png

Now I downloaded 9.2 just in case, but it connects quickly, but never do my miners seem to connect.. not even on the host machine. Anyone..?

Firewall? Looks like its blocked somehow.

[iongchun]

Stale rate is still pretty dam high

Code:

Version: 9.1

Pool rate: 335GH/s [b](23% stale) [/b]Share difficulty: 522

Node uptime: 1.640 days Peers: 6 out, 2 in

Local rate: 3.81GH/s (5.9% DOA) Expected time to share: 0.163 hours

Shares: 216 total (39 orphaned, 13 dead) Efficiency: 98.28%

Your efficiency is high enough
But you should try version 9.2, the DOA rate is much lower for me.

[PatMan]

After 12 hours on v9.2 my stale rate has gone up to 36% - whereas on the previous v9.1-9 it was steady at a lower (but still high) 18-22%. Connections seem quicker, but those damn "punishing share for stale" and "tx" messages are constantly thrown at me. Might go back to the previous build.......

[K1773R]

After 12 hours on v9.2 my stale rate has gone up to 36% - whereas on the previous v9.1-9 it was steady at a lower (but still high) 18-22%. Connections seem quicker, but those damn "punishing share for stale" and "tx" messages are constantly thrown at me. Might go back to the previous build.......

0% stale for me

[rav3n_pl]

After 12 hours on v9.2 my stale rate has gone up to 36% - whereas on the previous v9.1-9 it was steady at a lower (but still high) 18-22%. Connections seem quicker, but those damn "punishing share for stale" and "tx" messages are constantly thrown at me. Might go back to the previous build.......

There few parameters you should look at:
1. Local rate:  xxx H/s (yy% DOA)  
DOA there should be very low (max few %). If it is high possible miner config is bad or node GBT/lag is very high and you are mining old share.
2. Shares: xxx total (yyy orphaned, zzz dead) Efficiency: qqq%
yyy depends on mostly LUCK, some on config. Orphaned share means that someone found share at same time as you, and yet another share was put on his share not yours.
zzz depends on node and bit on luck. Dead share means that it is another share already after that one you was mining. So if your node is lagging and not fetching/passing shares fast enough you will get more dead shares.

[tiker]

I'm rebuilding my p2pool node due to a hardware failure.

Running the latest version as of 15 minutes ago from the GIT and I get the following:

Code:

2012-11-30 08:31:23.335637 > Traceback (most recent call last):
2012-11-30 08:31:23.336126 > Failure: twisted.python.failure.DefaultException: sharereply result: too long
2012-11-30 08:31:23.336928 Requesting parent share b68a0d0b from 173.11.125.162:9333
2012-11-30 08:31:25.159341 > in download_shares:
2012-11-30 08:31:25.159967 > Traceback (most recent call last):
2012-11-30 08:31:25.160453 > Failure: twisted.python.failure.DefaultException: sharereply result: too long
2012-11-30 08:31:25.161314 Requesting parent share b68a0d0b from 83.161.255.174:9333
2012-11-30 08:31:28.133602 > in download_shares:
2012-11-30 08:31:28.134254 > Traceback (most recent call last):
2012-11-30 08:31:28.134743 > Failure: twisted.python.failure.DefaultException: sharereply result: too long
2012-11-30 08:31:28.135574 Requesting parent share b68a0d0b from 173.11.125.162:9333
2012-11-30 08:31:28.166702 P2Pool: 0 shares in chain (0 verified/4565 total) Peers: 6 (0 incoming)
2012-11-30 08:31:28.167326  Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2012-11-30 08:31:30.027398 > in download_shares:
2012-11-30 08:31:30.028164 > Traceback (most recent call last):
2012-11-30 08:31:30.028618 > Failure: twisted.python.failure.DefaultException: sharereply result: too long
2012-11-30 08:31:30.029446 Requesting parent share b68a0d0b from 173.11.125.162:9333
2012-11-30 08:31:31.816948 > in download_shares:
2012-11-30 08:31:31.817605 > Traceback (most recent call last):
2012-11-30 08:31:31.818093 > Failure: twisted.python.failure.DefaultException: sharereply result: too long
2012-11-30 08:31:31.818912 Requesting parent share b68a0d0b from 83.161.255.174:9333
2012-11-30 08:31:34.376080 > in download_shares:
2012-11-30 08:31:34.376732 > Traceback (most recent call last):
2012-11-30 08:31:34.377251 > Failure: twisted.python.failure.DefaultException: sharereply result: too long
2012-11-30 08:31:34.378040 Requesting parent share b68a0d0b from 75.12.89.18:9333

Not sure if it's worth worrying about or not but posting just in case.

[PatMan]

After 12 hours on v9.2 my stale rate has gone up to 36% - whereas on the previous v9.1-9 it was steady at a lower (but still high) 18-22%. Connections seem quicker, but those damn "punishing share for stale" and "tx" messages are constantly thrown at me. Might go back to the previous build.......

There few parameters you should look at:
1. Local rate:  xxx H/s (yy% DOA)  
DOA there should be very low (max few %). If it is high possible miner config is bad or node GBT/lag is very high and you are mining old share.
2. Shares: xxx total (yyy orphaned, zzz dead) Efficiency: qqq%
yyy depends on mostly LUCK, some on config. Orphaned share means that someone found share at same time as you, and yet another share was put on his share not yours.
zzz depends on node and bit on luck. Dead share means that it is another share already after that one you was mining. So if your node is lagging and not fetching/passing shares fast enough you will get more dead shares.

Hi rav3n,

My local DOA rate on p2pool is 1.8% which is pretty normal for me.

I just done a few tweaks on my rig and rebooted, but before that I was over 36% stales and about 75% efficiency - where as before all this malarkey I was at a constant 98-110%+.

Ki77er, how do you manage to get a 0% stale rate when the pool stale rate is over 20%? Teach me Obe Wan.....

[K1773R]

After 12 hours on v9.2 my stale rate has gone up to 36% - whereas on the previous v9.1-9 it was steady at a lower (but still high) 18-22%. Connections seem quicker, but those damn "punishing share for stale" and "tx" messages are constantly thrown at me. Might go back to the previous build.......

There few parameters you should look at:
1. Local rate:  xxx H/s (yy% DOA)  
DOA there should be very low (max few %). If it is high possible miner config is bad or node GBT/lag is very high and you are mining old share.
2. Shares: xxx total (yyy orphaned, zzz dead) Efficiency: qqq%
yyy depends on mostly LUCK, some on config. Orphaned share means that someone found share at same time as you, and yet another share was put on his share not yours.
zzz depends on node and bit on luck. Dead share means that it is another share already after that one you was mining. So if your node is lagging and not fetching/passing shares fast enough you will get more dead shares.

Hi rav3n,

My local DOA rate on p2pool is 1.8% which is pretty normal for me.

I just done a few tweaks on my rig and rebooted, but before that I was over 36% stales and about 75% efficiency - where as before all this malarkey I was at a constant 98-110%+.

Ki77er, how do you manage to get a 0% stale rate when the pool stale rate is over 20%? Teach me Obe Wan.....

i cant tell you why, i can just guess.

[AV]

How to setup --submit-stale parameter in cgminer ?
Submit or no submit ?  

K1773R
Thanks.