Author

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

legendary
Activity: 1540
Merit: 1001
Also, the P2Pool block time is 10 seconds, so having a latency of >10 seconds means that when a new block is detected, you're going to completely miss the next block, which would half your actual effective rate.

Finally something that is factual.  Thanks! Smiley

The highest I saw mine was 3s.  And as I stated multiple times, restarting bitcoind put it back down where it was supposed to be, but it did start climbing back up.  I still fail to see how transactions have anything to do with it when restarting bitcoind lowers the latency.

M
sr. member
Activity: 448
Merit: 250
Also, the P2Pool block time is 10 seconds, so having a latency of >10 seconds means that when a new block is detected, you're going to completely miss the next block, which would half your actual effective rate.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
While all you lot touch each other and fight about it.

No changes to Bitcoin.conf, simply updated to 0.8.3rc3 and I have some LOW LAT back, seems to be holding.

I still don't see what the big deal was about latency.  Everything seemed to be working fine, but people were panicking over apparent high latency.  Instead they'd rather use a pre-release version of bitcoind that specifics warns you not to use for mining.



M

I already explained the problem. There are 2 reasons to upgrade:
  • You use bitcoind's RPC interface yourself and use calls that took several seconds instead of <0.1s in your tools (like I do)
  • P2Pool has shown less efficiency when the getblocktemplate latency is above 0.2s in the past (it's shown in the graphs to help study its influence)

If everyone has the same blocktemplate latency (even if its several seconds) it doesn't matter: the efficiency is relative to other P2Pool nodes. But if some have far less latency than others we could see the same problem appear again.
And efficiency vs other node set aside we have orphan blocks to worry about too: if other pools manage to get block templates faster than P2Pool our orphan rate will rise.

And you know for sure HOW that when the latency goes up that it affects p2pool?  When everyone else tries saying there's a problem, you call them a troll, and it's just bad luck.  Yet when you say there's a problem, it's gospel, not bad luck?

I agree, everyone having different latencies should theoretically affect their performance vs others.  All the more reason to leave it alone and keep everyone the same!

M
1) they'll be slower on the uptake for new blocks, wasting the mining time of whatever their latency is/was
2) if they discover a block, it's more likely to be orphaned

indirectly, higher latency would imply more transactions, which would mean more orphans for you on the p2pool network
legendary
Activity: 1540
Merit: 1001
While all you lot touch each other and fight about it.

No changes to Bitcoin.conf, simply updated to 0.8.3rc3 and I have some LOW LAT back, seems to be holding.

I still don't see what the big deal was about latency.  Everything seemed to be working fine, but people were panicking over apparent high latency.  Instead they'd rather use a pre-release version of bitcoind that specifics warns you not to use for mining.



M

I already explained the problem. There are 2 reasons to upgrade:
  • You use bitcoind's RPC interface yourself and use calls that took several seconds instead of <0.1s in your tools (like I do)
  • P2Pool has shown less efficiency when the getblocktemplate latency is above 0.2s in the past (it's shown in the graphs to help study its influence)

If everyone has the same blocktemplate latency (even if its several seconds) it doesn't matter: the efficiency is relative to other P2Pool nodes. But if some have far less latency than others we could see the same problem appear again.
And efficiency vs other node set aside we have orphan blocks to worry about too: if other pools manage to get block templates faster than P2Pool our orphan rate will rise.

And you know for sure HOW that when the latency goes up that it affects p2pool?  When everyone else tries saying there's a problem, you call them a troll, and it's just bad luck.  Yet when you say there's a problem, it's gospel, not bad luck?

I agree, everyone having different latencies should theoretically affect their performance vs others.  All the more reason to leave it alone and keep everyone the same!

M
hero member
Activity: 896
Merit: 1000
While all you lot touch each other and fight about it.

No changes to Bitcoin.conf, simply updated to 0.8.3rc3 and I have some LOW LAT back, seems to be holding.

I still don't see what the big deal was about latency.  Everything seemed to be working fine, but people were panicking over apparent high latency.  Instead they'd rather use a pre-release version of bitcoind that specifics warns you not to use for mining.



M

I already explained the problem. There are 2 reasons to upgrade:
  • You use bitcoind's RPC interface yourself and use calls that took several seconds instead of <0.1s in your tools (like I do)
  • P2Pool has shown less efficiency when the getblocktemplate latency is above 0.2s in the past (it's shown in the graphs to help study its influence)

If everyone has the same blocktemplate latency (even if its several seconds) it doesn't matter: the efficiency is relative to other P2Pool nodes. But if some have far less latency than others we could see the same problem appear again.
And efficiency vs other node set aside we have orphan blocks to worry about too: if other pools manage to get block templates faster than P2Pool our orphan rate will rise.
sr. member
Activity: 290
Merit: 250
While all you lot touch each other and fight about it.

No changes to Bitcoin.conf, simply updated to 0.8.3rc3 and I have some LOW LAT back, seems to be holding.

I still don't see what the big deal was about latency.  Everything seemed to be working fine, but people were panicking over apparent high latency.  Instead they'd rather use a pre-release version of bitcoind that specifics warns you not to use for mining.



M

Trouble started with 0.8.1 and 11.4 for me. Seems all back to normal now. Not had to change anything in Bitcoin.conf to affect tx and wotnot, waiting worked.
hero member
Activity: 896
Merit: 1000
Ah yeah - I forgot to completely ignore the fact (like you are) that the big pools are confirming the transactions that you aren't ...

So yet again your excuse for proving p2pool is worse for bitcoin is that ... there's apparently a problem with bitcoind that the big pools can work around ... and then you get posts like the one above this post ...

I also notice that gmaxwell is completely avoiding posting here ... yes he's an avid proponent of p2pool ... maybe there's a reason he's not commenting in here ...

What's your point again? Sorry kano, but your bullshitting is so thick I don't even know what you are bullshitting about now.
I think I've found a Luke-Jr V2.0

That's not really helping your point.

To help you understand my point of view: I'm bed-ridden for more than 3 weeks now and take painkillers that make concentration for long period of times difficult and result in my current short-temper. If you don't present your argument in a concise way or repeat arguments that have already countered, I simply call bullshit: I don't have the patience to repeat myself these days.

Calling me names (literally Smiley ) is just a waste of your time.
legendary
Activity: 1540
Merit: 1001
While all you lot touch each other and fight about it.

No changes to Bitcoin.conf, simply updated to 0.8.3rc3 and I have some LOW LAT back, seems to be holding.

I still don't see what the big deal was about latency.  Everything seemed to be working fine, but people were panicking over apparent high latency.  Instead they'd rather use a pre-release version of bitcoind that specifics warns you not to use for mining.



M
sr. member
Activity: 290
Merit: 250
While all you lot touch each other and fight about it.

No changes to Bitcoin.conf, simply updated to 0.8.3rc3 and I have some LOW LAT back, seems to be holding.



zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
This server is using the latest git pull with unmodified settings on fees & a max blocksize of 500000 (isn't the default 1,000,000?  or is it still 500k for p2pool?)

I believe the default is 500k. 1M is the limit allowed by the protocol and can be set if needed.

In fact if you have a very low getblocktemplate latency, you should increase maxblocksize as there's still 22MB of unconfirmed transaction as I write this according to blockchain.info: there may be fee-less transactions in these 22MB but I assume that there's a lot of fees to grab too.

If you are below 0.01s latency and want to optimize your income, increase maxblocksize gradually until you reach either 1MB or 0.01s latency.

Well, it's hitting like .10-.15s avg, with .0001 fee and 500,000 blocksize, doesn't seem too bad. 

'course, someone could always waste some of their money to spam a lot of junk transactions.  Guess you'd just need to monitor it a bit
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Ah yeah - I forgot to completely ignore the fact (like you are) that the big pools are confirming the transactions that you aren't ...

So yet again your excuse for proving p2pool is worse for bitcoin is that ... there's apparently a problem with bitcoind that the big pools can work around ... and then you get posts like the one above this post ...

I also notice that gmaxwell is completely avoiding posting here ... yes he's an avid proponent of p2pool ... maybe there's a reason he's not commenting in here ...

What's your point again? Sorry kano, but your bullshitting is so thick I don't even know what you are bullshitting about now.
I think I've found a Luke-Jr V2.0
sr. member
Activity: 290
Merit: 250
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/test/

Just seen a new rc3 4 hours ago. Anyone want to test?

I'm off to bed.
hero member
Activity: 896
Merit: 1000
This server is using the latest git pull with unmodified settings on fees & a max blocksize of 500000 (isn't the default 1,000,000?  or is it still 500k for p2pool?)

I believe the default is 500k. 1M is the limit allowed by the protocol and can be set if needed.

In fact if you have a very low getblocktemplate latency, you should increase maxblocksize as there's still 22MB of unconfirmed transaction as I write this according to blockchain.info: there may be fee-less transactions in these 22MB but I assume that there's a lot of fees to grab too.

If you are below 0.1s latency and want to optimize your income, increase maxblocksize gradually until you reach either 1MB or 0.1s latency.

Edit: typo, I meant 0.1s latency not 0.01.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
This server is using the latest git pull with unmodified settings on fees & a max blocksize of 500000 (isn't the default 1,000,000?  or is it still 500k for p2pool?)

http://nogleg.net:9332/static/graphs.html?Hour

granted, it's also running ltc @

http://nogleg.net:9327/static/graphs.html?Hour

but that doesn't seem to really take much resources anyway

    "blocks" : 237724,
    "currentblocksize" : 476689,
    "currentblocktx" : 812,
    "difficulty" : 11187257.46136079,
    "errors" : "",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "pooledtx" : 844,
    "testnet" : false

it benches about 5% higher than nogleg.com
hero member
Activity: 896
Merit: 1000
4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

I did what is stated above to the latest 0.8.2rc2 (sipa changes). I had similar results with the 0.8.2rc1 as well (3.00ms).

Usually I agree to some blockmaxsize and tx fee tuning, but it's going too far here. forrestv suggested that the bitcoind latency doesn't influence your efficiency noticeably and I can confirm that below 0.2s I don't see any meaningful difference (I'm still at 110-115% efficiency).

In fact you may actually hurt your income at this point. Depending on your hashrate you will eventually hit a block and it will pay less to everyone, yourself included. If you only have hundreds of megahashes this doesn't change much for everyone as you probably won't hit a block in the foreseeable future but if you are one of the lucky few with ~100GH/s (there are at least 2 currently according to the payouts) it's 10% of the total p2pool network and nearly 10% of less fees for everyone yourself included. Fees are ~1% of the incomes currently.

This means ~0.1% less income for everyone. If you encourage others to do the same mistake, this is 1% less income for everyone.

My recommendations if you want to tune bitcoind:
  • compile it from git head like GrapeApe: it has the latest performance enhancements and its default mintxfee and minrelaytxfee values are better for miners (don't touch the source, modifications of constants demonstrated earlier in this thread will only make things more difficult and only touch default values that can now be changed with the mintxfee and minrelaytxfee parameters)
  • look at your average bitcoind latency as reported by p2pool for at least 24h
  • if your latency is above 0.1s and only if it is try the following tunings (from first to last) measuring the result for at least 24h each time you apply one of them and stop when you reach <0.1s latency (it will give you some margin if something slows down bitcoind later and avoid its latency raising above 0.2s, you should monitor this value and many others with monitoring software if you value your income anyway):
    • give CPU and IO priority to your bitcoind and p2pool processes if your OS allows it (see the guide in my signature, I'll update it soon for Linux examples)
    • move the bitcoind and p2pool data directories to SSD storage
    • reduce blockmaxsize to 250000 instead of 500000
    • raise mintxfee and minrelaytxfee to 0.0005
    • if you are still above 0.1s, reapply the measure that had the largest impact on your getblocktemplate latency between the last 2 (blockmaxsize=125000 or mintxfee/minrelaytxfee=0.001 for example)



Note that if you reach the latest steps, you probably have CPU and IO limitations that are hurting your efficiency elsewhere anyway.

If your node is in ideal conditions (very strong CPU and SSD dedicated to bitcoind + P2Pool) and your latency still needs heavy tuning (blocksize < 100000 or fees > 0.001) to reach 0.1s, this is starting to hurt the Bitcoin network (especially if you control large hashrates): you should start discussing it with other p2pool miners to see if it's a general problem worth reporting to the Bitcoin devs.
hero member
Activity: 896
Merit: 1000
Uuhh please don't call them GrapeApe modifications (just following directions from another post). With that said gyverlb I agree completely. My efficiency is the same with 2.5ms vs .05s latency. So yes all I am doing is ultimately cutting into my (everyones) income. I have done exactly as you recommended above. By the way your guide has been a huge help.

I'll edit my post right away to remove "GrapeApe modifications" (I can't fit many posts in my short-term memory and I'm a little groggy from painkillers so I make mistakes, sorry).
sr. member
Activity: 476
Merit: 250
Uuhh please don't call them GrapeApe modifications (just following directions from another post). With that said gyverlb I agree completely. My efficiency is the same with 2.5ms vs .05s latency. So yes all I am doing is ultimately cutting into my (everyones) income. I have done exactly as you recommended above. By the way your guide has been a huge help.
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
So for git and 0.8.2 it all can be set in bitcoin.conf
I`ll try this:
Code:
blockmaxsize=500000
blockprioritysize=10000
blockminsize=5000
mintxfee=0.0005
minrelaytxfee=0.0005
hero member
Activity: 896
Merit: 1000
4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

I did what is stated above to the latest 0.8.2rc2 (sipa changes). I had similar results with the 0.8.2rc1 as well (3.00ms).

Usually I agree to some blockmaxsize and tx fee tuning, but it's going too far here. forrestv suggested that the bitcoind latency doesn't influence your efficiency noticeably and I can confirm that below 0.2s I don't see any meaningful difference (I'm still at 110-115% efficiency).

In fact you may actually hurt your income at this point. Depending on your hashrate you will eventually hit a block and it will pay less to everyone, yourself included. If you only have hundreds of megahashes this doesn't change much for everyone as you probably won't hit a block in the foreseeable future but if you are one of the lucky few with ~100GH/s (there are at least 2 currently according to the payouts) it's 10% of the total p2pool network and nearly 10% of less fees for everyone yourself included. Fees are ~1% of the incomes currently.

This means ~0.1% less income for everyone. If you encourage others to do the same mistake, this is 1% less income for everyone.

My recommendations if you want to tune bitcoind:
  • compile it from git head like GrapeApe: it has the latest performance enhancements and its default mintxfee and minrelaytxfee values are better for miners (don't touch the source, modifications of constants demonstrated earlier in this thread will only make things more difficult and only touch default values that can now be changed with the mintxfee and minrelaytxfee parameters)
  • look at your average bitcoind latency as reported by p2pool for at least 24h
  • if your latency is above 0.1s and only if it is try the following tunings (from first to last) measuring the result for at least 24h each time you apply one of them and stop when you reach <0.1s latency (it will give you some margin if something slows down bitcoind later and avoid its latency raising above 0.2s, you should monitor this value and many others with monitoring software if you value your income anyway):
    • give CPU and IO priority to your bitcoind and p2pool processes if your OS allows it (see the guide in my signature, I'll update it soon for Linux examples)
    • move the bitcoind and p2pool data directories to SSD storage
    • reduce blockmaxsize to 250000 instead of 500000
    • raise mintxfee and minrelaytxfee to 0.0005
    • if you are still above 0.1s, reapply the measure that had the largest impact on your getblocktemplate latency between the last 2 (blockmaxsize=125000 or mintxfee/minrelaytxfee=0.001 for example)
sr. member
Activity: 476
Merit: 250
WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;



3) compile bitcoin

 
4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

I did what is stated above to the latest 0.8.2rc2 (sipa changes). I had similar results with the 0.8.2rc1 as well (3.00ms).

Deja Vu no?
Jump to: