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

[K1773R]

I'm having an issue with p2pool and my router. It's not a show-stopper but I was wondering if someone might have an idea what's going on or be able to work with me to work out what is going on.

Basically, anytime I turn on QOS, I appear to stop doing any useful work. cgminer trundles along, fans spin, heat generated, Unfortunately, it appears that that's all wasted. the debug output of p2pool says that it's punishing shares for being stale. On the pools graph page, the incoming part of peers and the p2p in on traffic rate drop to zero. For whatever reason, it looks like peers are no longer supplying me with useful information (?)

I've even set things so that p2pool and bitcoind are QOSed to the highest speed category just in case they were getting squashed that way but it still gives the same result.

I can leave QOS off for now but I'd like to get this working properly. I'm using Tomato so the configuration is fairly straightforward and easy. I'll post some pictures in a little bit for illustration. I can perform packet captures and other good stuff but I'm not up on the p2pool networking.

the only thing i've ever used in windows that i've found did a proper job of managing bandwidth was netlimiter

the only thing that did almost a proper job is "format c: -y"

[zvs]

I'm having an issue with p2pool and my router. It's not a show-stopper but I was wondering if someone might have an idea what's going on or be able to work with me to work out what is going on.

Basically, anytime I turn on QOS, I appear to stop doing any useful work. cgminer trundles along, fans spin, heat generated, Unfortunately, it appears that that's all wasted. the debug output of p2pool says that it's punishing shares for being stale. On the pools graph page, the incoming part of peers and the p2p in on traffic rate drop to zero. For whatever reason, it looks like peers are no longer supplying me with useful information (?)

I've even set things so that p2pool and bitcoind are QOSed to the highest speed category just in case they were getting squashed that way but it still gives the same result.

I can leave QOS off for now but I'd like to get this working properly. I'm using Tomato so the configuration is fairly straightforward and easy. I'll post some pictures in a little bit for illustration. I can perform packet captures and other good stuff but I'm not up on the p2pool networking.

the only thing i've ever used in windows that i've found did a proper job of managing bandwidth was netlimiter

the only thing that did almost a proper job is "format c: -y"

what, netlimiter?

why, because it installs some driver that you can disable on startup?

i don't get the big deal with it

[Richy_T]

In case anyone isn't familiar with Tomato, it is a specialized Linux distribution that runs on certain hardware routers.

Other connections appear to occur with no issues (unless I goof the configuration) and if I look in the details, I can see connections between external hosts and my own on the bitcoind and p2pool ports. I can't think it would be anything about Python that would be causing the issue. Hard to see what about QOS would be an issue since it's basically just prioritizing packets. But there must be more to it.

[K1773R]

I'm having an issue with p2pool and my router. It's not a show-stopper but I was wondering if someone might have an idea what's going on or be able to work with me to work out what is going on.

Basically, anytime I turn on QOS, I appear to stop doing any useful work. cgminer trundles along, fans spin, heat generated, Unfortunately, it appears that that's all wasted. the debug output of p2pool says that it's punishing shares for being stale. On the pools graph page, the incoming part of peers and the p2p in on traffic rate drop to zero. For whatever reason, it looks like peers are no longer supplying me with useful information (?)

I've even set things so that p2pool and bitcoind are QOSed to the highest speed category just in case they were getting squashed that way but it still gives the same result.

I can leave QOS off for now but I'd like to get this working properly. I'm using Tomato so the configuration is fairly straightforward and easy. I'll post some pictures in a little bit for illustration. I can perform packet captures and other good stuff but I'm not up on the p2pool networking.

the only thing i've ever used in windows that i've found did a proper job of managing bandwidth was netlimiter

the only thing that did almost a proper job is "format c: -y"

what, netlimiter?

why, because it installs some driver that you can disable on startup?

i don't get the big deal with it

i said on win only "format c: -y" does work almost proper

[gyverlb]

In case anyone isn't familiar with Tomato, it is a specialized Linux distribution that runs on certain hardware routers.

Other connections appear to occur with no issues (unless I goof the configuration) and if I look in the details, I can see connections between external hosts and my own on the bitcoind and p2pool ports. I can't think it would be anything about Python that would be causing the issue. Hard to see what about QOS would be an issue since it's basically just prioritizing packets. But there must be more to it.

Depends how Tomato handles QoS. You can block some traffic if you give higher priority and allow another to saturate your link. QoS isn't simple at all (you must define many compromises to make it work), if your tools make you think it is simple they probably do it wrong.

[zvs]

I'm having an issue with p2pool and my router. It's not a show-stopper but I was wondering if someone might have an idea what's going on or be able to work with me to work out what is going on.

Basically, anytime I turn on QOS, I appear to stop doing any useful work. cgminer trundles along, fans spin, heat generated, Unfortunately, it appears that that's all wasted. the debug output of p2pool says that it's punishing shares for being stale. On the pools graph page, the incoming part of peers and the p2p in on traffic rate drop to zero. For whatever reason, it looks like peers are no longer supplying me with useful information (?)

I've even set things so that p2pool and bitcoind are QOSed to the highest speed category just in case they were getting squashed that way but it still gives the same result.

I can leave QOS off for now but I'd like to get this working properly. I'm using Tomato so the configuration is fairly straightforward and easy. I'll post some pictures in a little bit for illustration. I can perform packet captures and other good stuff but I'm not up on the p2pool networking.

the only thing i've ever used in windows that i've found did a proper job of managing bandwidth was netlimiter

the only thing that did almost a proper job is "format c: -y"

what, netlimiter?

why, because it installs some driver that you can disable on startup?

i don't get the big deal with it

i said on win only "format c: -y" does work almost proper

oh, lots of netlimiter haters out there

but this is true

[Xenotron]

Is there any way to avoid high CPU load by bitcoin-qt? Also latency skyrocketing to 14s...
Tried 11.4 and it seems there is a memory leak. Now started 11.2 - will see.

[azw409]

The latency appears to be in bitcoin-qt because if I restart p2pool, the latency is still high > 10s on restart whereas if I restart both bitcoin-qt and p2pool the latency returns to around 0.5s.

So I'm not sure that using an earlier version of p2pool will have any bearing on this.

[azw409]

Maybe the issue with latency is nothing to do with the software but extremely large blocks :-

https://bitcointalk.org/index.php?topic=207790.0

[Xenotron]

Maybe the issue with latency is nothing to do with the software but extremely large blocks :-

https://bitcointalk.org/index.php?topic=207790.0

Nope. I have started to use blockmaxsize=5000 to see what will be changed. And so far there is no big difference.
bitcoin-qt continues to increase RAM consumption even when new block is found.
I can see on Graphs that when Bitcoin-qt releases occupied RAM then latency drops to its usual values.

[Prattler]

I can confirm the high getblocktemplate latency is bitcoind related.

1. Upgrade bitcoind to the latest possible version (https://bitcointalk.org/index.php?topic=201124.0)

2. With p2pool we are real miners and make our own blocks, so edit the important settings in your bitcoin.conf!

Code:

blockmaxsize=250000 # default: 250000

blockprioritysize=27000 # default: 27000

mintxfee=0.0002 # default: 0.0001

minrelaytxfee=0.0002 # default: 0.0001

Setting mintxfee and minrelaytxfee higher than default will increase your getblocktemplate latency. It's a matter of opinion, but I think those defaults are too low for the network, so, by increasing them a bit, you are also benefiting the network. I would personally recommend setting both to 0.0005.

Edit: what happens is that lots of free and low fee transactions accumulate on the mempool, which increases getblocktemplate latency, due to an algorithmic flaw of bitcoind's getblocktemplate. It might not matter for most pools, but p2pool is more dependant on this. Setting mintxfee/minrelaytxfee above default 0.0001 reduces the accumulation of mempool garbage. Restarting bitcoind also clears the mempool and helps for a short time.

[mdude77]

I can confirm the high getblocktemplate latency is bitcoind related.

1. Upgrade bitcoind to the latest possible version (https://bitcointalk.org/index.php?topic=201124.0)

2. With p2pool we are real miners and make our own blocks, so edit the important settings in your bitcoin.conf!

Code:

blockmaxsize=250000 # default: 250000

blockprioritysize=27000 # default: 27000

mintxfee=0.0002 # default: 0.0001

minrelaytxfee=0.0002 # default: 0.0001

Setting mintxfee and minrelaytxfee higher than default will increase your getblocktemplate latency. It's a matter of opinion, but I think those defaults are too low for the network, so, by increasing them a bit, you are also benefiting the network. I would personally recommend setting both to 0.0005.

Until bitcoind gets optimized, getblocktemplate just gets too slow with the default minrelaytxfee=0.0001.

Maybe this is hardware or environment related?  I'm still using default settings and latest p2pool.  My stale rate is always 10-15% less than the pool's rate.  Yes, according to p2pool my bitcoind latency is at 10s.  So what?

M

EDIT: I restarted bitcoind, it did significantly reduce getblocktemplate latency.  Don't see a big deal here, have to restart things regularly anyhow.  Just had to restart cgminer because it went funny on me.  Presumably hit the AMD driver time limit.

[furball]

I can confirm the high getblocktemplate latency is bitcoind related.

1. Upgrade bitcoind to the latest possible version (https://bitcointalk.org/index.php?topic=201124.0)

2. With p2pool we are real miners and make our own blocks, so edit the important settings in your bitcoin.conf!

Code:

blockmaxsize=250000 # default: 250000

blockprioritysize=27000 # default: 27000

mintxfee=0.0002 # default: 0.0001

minrelaytxfee=0.0002 # default: 0.0001

Setting mintxfee and minrelaytxfee higher than default will increase your getblocktemplate latency. It's a matter of opinion, but I think those defaults are too low for the network, so, by increasing them a bit, you are also benefiting the network. I would personally recommend setting both to 0.0005.

Until bitcoind gets optimized, getblocktemplate just gets too slow with the default minrelaytxfee=0.0001.

Maybe this is hardware or environment related?  I'm still using default settings and latest p2pool.  My stale rate is always 10-15% less than the pool's rate.  Yes, according to p2pool my bitcoind latency is at 10s.  So what?

M

EDIT: I restarted bitcoind, it did significantly reduce getblocktemplate latency.  Don't see a big deal here, have to restart things regularly anyhow.  Just had to restart cgminer because it went funny on me.  Presumably hit the AMD driver time limit.

I've been running with the blockmaxsize and mintxfee setting per above for the last 12 hours and it didn't seem to help. I just added in the blockprioritysize and minrelaytxfee settings and it looks to have made a huge difference.

Went from 5s latency to sub 1s.

Thanks so much Prattler...awesome post!

[daemondazz]

None of the above changes have made any difference for my node - I'm currently running at 11s Get Work latency. With a 10s block time, I can't help but think I'm never going to actually solve a share.

Restarting bitcoind drops the latency back down, but it climbs back up to >10s in about half hour. I'm now restarting once per hour from cron to attempt to get some period where I might be able to get some valid work.

This is with version 0.8.1-precise2 from http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu.

Any other ideas?

[mdude77]

None of the above changes have made any difference for my node - I'm currently running at 11s Get Work latency. With a 10s block time, I can't help but think I'm never going to actually solve a share.

Restarting bitcoind drops the latency back down, but it climbs back up to >10s in about half hour. I'm now restarting once per hour from cron to attempt to get some period where I might be able to get some valid work.

This is with version 0.8.1-precise2 from http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu.

Any other ideas?

I'm at 1s latency now.  It was about 8-10 hours ago that I restarted it.  Must behave differently on linux than it does windows.  Or it's hardware related?  What horsepower do you have under the hood?  using an i7 on an SSD with 12gb of ram here.

M

[TurdHurdur]

None of the above changes have made any difference for my node - I'm currently running at 11s Get Work latency. With a 10s block time, I can't help but think I'm never going to actually solve a share.

Restarting bitcoind drops the latency back down, but it climbs back up to >10s in about half hour. I'm now restarting once per hour from cron to attempt to get some period where I might be able to get some valid work.

This is with version 0.8.1-precise2 from http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu.

Any other ideas?

Code:

mintxfee=20000

...in bitcoin.conf worked pretty good for me, still get some fee'd transactions in and latency is under .1 seconds.

Edit: it ceased being effective, unfortunate...

[gyverlb]

Here's the settings I'm currently trying (too soon to be sure it works).
This removes any room reserved for high priority transaction (using old inputs).

Code:

blockminsize=0
blockprioritysize=0
mintxfee=0.001

mintxfee might have to be raised to avoid the current set of problematic transactions (I'm not sure how much they paid by kB).

[zvs]

blockminsize=0
blockprioritysize=0
blockmaxsize=5000     (you could reduce this to probably 2000 or 3000 and still pick up the odd super high transaction fee transfer.  *1200 or below will always miss it, as it'll just have the 1 transaction from block)
minrelaytxfee=0.0005    (i assume that one works, i make the change in the source, which would be nMinRelayTxFee = 50000)

the post about increasing the relay fees = higher latency is wrong

ofc, if all blocks came from p2pool then we'd have issues if everyone had ^^^ those settings

i guess 'mintxfee' would be the creation tx fee, which you probably wont want to change unless you want to increase fees on your own transactions.  i assume most pools run with the default setting of 0.0001

last edit, i think;

set maxblocksize to 1000.  if you still have latency issues, then the issue lies somewhere other than with bitcoind and p2pool

[daemondazz]

I'm at 1s latency now.  It was about 8-10 hours ago that I restarted it.  Must behave differently on linux than it does windows.  Or it's hardware related?  What horsepower do you have under the hood?  using an i7 on an SSD with 12gb of ram here.

I'm running on a HP Blade, quad core Xeon on SAS drives, so computing power shouldn't be an issue

Not sure what else to try...

[azw409]

This current round is taking a long time :-(