Bitcoin Forum
December 07, 2016, 08:19:17 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 [277] 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2032499 times)
Mogumodz
Sr. Member
****
Offline Offline

Activity: 290



View Profile
May 25, 2013, 11:37:56 AM
 #5521

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.




Bitcoin OTC rating GPG ID: 3E7974A1 P2Pool statistics: p2pool.info
1481141957
Hero Member
*
Offline Offline

Posts: 1481141957

View Profile Personal Message (Offline)

Ignore
1481141957
Reply with quote  #2

1481141957
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481141957
Hero Member
*
Offline Offline

Posts: 1481141957

View Profile Personal Message (Offline)

Ignore
1481141957
Reply with quote  #2

1481141957
Report to moderator
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 25, 2013, 11:54:49 AM
 #5522

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.

<shrug>

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 12:07:35 PM
 #5523

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.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Mogumodz
Sr. Member
****
Offline Offline

Activity: 290



View Profile
May 25, 2013, 12:08:47 PM
 #5524

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.

<shrug>

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.

Bitcoin OTC rating GPG ID: 3E7974A1 P2Pool statistics: p2pool.info
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 12:17:56 PM
 #5525

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.

<shrug>

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.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 25, 2013, 12:30:01 PM
 #5526

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.

<shrug>

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

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
zvs
Legendary
*
Offline Offline

Activity: 1386



View Profile WWW
May 25, 2013, 01:23:14 PM
 #5527

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.

<shrug>

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

Dacentec, best deals for US dedicated servers. They regularly restock $20-$25 Opterons with 8-16GB RAM & 2x1-2TB HDD's (ofc, usually lots of other good stuff to choose from).  I did a Serverbear benchmark of one of my $20/mo Opteron (June last year), it's here.  Have had about a half dozen different servers with Dacentec, & none have failed to sustain at least 40MB/s (burst higher). My favorite is a 12-month rent-to-own ZT Systems 2XL5520 16GB 2x2TB SATA for $40/month (got lucky with the 'off-brand', haven't seen a RTO 2xL5520 for under $50/mo since -- at least for monthly contracts).  wholesaleinternet.com has some ancient 2-core intel CPUs @ $10/mo sometimes (I got an Intel Core 2 6300 @ 1.86GHz, with a 250GB HDD with 46000 hours on it, LOL. $20 @ Dacentec is much better, if you can grab one). joesdatacenter.com (same location as Wholesale Internet) also occasionally has specials (or if you don't want to wait, it has an AMD Opteron 170 @ $16/mo).
daemondazz
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 25, 2013, 01:30:17 PM
 #5528

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.

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 25, 2013, 01:55:52 PM
 #5529

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

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 02:22:20 PM
 #5530

And you know for sure HOW that when the latency goes up that it affects p2pool?

Maybe because I did exactly what I described in the guide in my signature.
Mind the fact that I said it affected p2pool. forrestv didn't communicate much on the subject, he might have changed p2pool's code since the problem was detected. This is easy to check by doing the same experiment that I did and described in the guide.

Currently I'm slowly raising maxblocksize and lowering mintxfee and minrelaytxfee on my node to find out how the new bitcoind code is behaving, how the getblocktemplate latency changes and how the efficiency reacts. I'll probably have to add some tips based on my results.
For example, even with the default fees, bitcoind doesn't fill a 500kB block on my node so raising maxblocksize doesn't change much, I'm just testing fee limits below the default value.
I suspect most of the 29MB of transactions currently around is made of fee-less or below recommended fees.

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?

Which problem and reported by whom? If it's still this nonsense about a bug in p2pool when we have bad luck, yes there are trolls. I don't even bother arguing on the subject now, organofcorti has already made the statistical analysis of p2pool luck and shown it was perfectly normal.

And if you didn't believe me when I said getblocktemplate latency was a problem, why don't you argue with the Bitcoin devs that included a patch to lower it this very week?

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!

Yeah right, like it would work and nobody would try to profit from the situation if there's even a mirage of an advantage to gain. There are many people motivated by pure profit or even blinded by some assumption that tuning something as much as possible is good although it's often a compromise.
Just look at what I had to say when someone gave an example of maxblocksize=5000: there's clearly work to be done to avoid these extremes (in this case just explaining that it's counterproductive should be enough).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
bitpop
Legendary
*
Offline Offline

Activity: 1932


https://keybase.io/bitpop


View Profile WWW
May 25, 2013, 02:25:45 PM
 #5531

Huge difference on mine with rc3 see sig

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
bitpop
Legendary
*
Offline Offline

Activity: 1932


https://keybase.io/bitpop


View Profile WWW
May 25, 2013, 02:26:26 PM
 #5532

Ps is there an explorer for unconfirmed transactions?

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
Subo1977
Sr. Member
****
Offline Offline

Activity: 345


View Profile
May 25, 2013, 02:30:09 PM
 #5533

Ps is there an explorer for unconfirmed transactions?


blockchain.info/de/unconfirmed-transactions

I provide a 1000Mbit+ Torrent-Seedbox in FR and a 500Mbit Box in NL for orginal Blockchain Bootstrap.dat download. and also for Armoryclient Torrent

Tips are welcome:  15MuGdPSXU62fEFE9XbBZN3UvJMHBDVBoy
bitpop
Legendary
*
Offline Offline

Activity: 1932


https://keybase.io/bitpop


View Profile WWW
May 25, 2013, 02:39:35 PM
 #5534

Sweet. What's the harm in making my node include them all.

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 02:56:44 PM
 #5535

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

 Roll Eyes There are such misconceptions floating around...

OK first mdude77 is wondering why the latency is lowered by restarting bitcoind and raises again.

When you restart bitcoind it doesn't save the list of unconfirmed transactions on disk: they are only maintained in what's called the memory pool.
When you restart it, at first it doesn't have any transaction in its memory pool. So any rpc call to bitcoind involving any parsing of the list of transaction in the memory pool is fast: getblocktemplate is obviously one of them as its goal is to build a template for a block including the tx in your memory pool that your bitcoind deems worth confirming.
Then your bitcoind learns of unconfirmed transactions at the rate at which it's neighboors (the nodes it's connected to) on the bitcoind P2P network transmit them. Only new transactions are automatically broadcasted and received by a freshly started node quickly, old ones are transmitted far slower to avoid network congestion. So a freshly started node gets new transactions appearing on the network quickly and slowly catches up through the backlog of unconfirmed transactions. The rate at which a node receives old transactions varies greatly: it depends on the nodes it is connected to (not every node is configured the same, some may relay more transactions than others).
This is why getblocktemplate latency is slowly rising and is perfectly consistent with getblocktemplate latency being heavily dependent on both the number of transactions your bitcoind accepts in its memory pool and the number of transactions it selects for confirmation (these being controlled by maxblocksize, minxtxfee and minrelaytxfee among others).

Second: the getblocktemplate and P2Pool orphan rate.
First a bit of vocabulary just to avoid any misunderstanding: what daemondazz calls P2Pool blocks are P2Pool shares.

AFAIK P2Pool doesn't need a fresh getblocktemplate to build a share. It can reuse a previous one (unless a Bitcoin block has just been found, then shares based on old templates would generate orphan blocks, see one of my earlier posts on why it's bad). The only drawback of using an old getblocktemplate result is that it doesn't include new transactions that were received after it (so it lowers the fee income and slow transaction confirmation a bit).

What the problem is is probably more subtle than that: P2Pool is an event-driven program (as opposed to multi-threaded or multi-process) with most of its event being handled asynchronously (waiting for a getblocktemplate result is probably done asynchronously).
What could happen but is very difficult to analyze is that the event-driven framework doesn't cope with long running queries as well for some obscure technical reason (like polling some event result in exponentially longer intervals instead of being woken up by a select or equivalent system call) or might have a timing problem when some task that can't be done asynchronously (like pure crypto computations) happens to be done right when the geblocktemplate comes back. There's even a system in place in P2Pool to punish shares computed from old templates when a newer block is known: P2Pool nodes generating them because of high getblocktemplate latency will most probably see them orphaned.

I don't know the exact reason why getblocktemplate affected efficiency and even if it's still the case today as forrestv might have changed something that removes this problem. It was still the case very recently (like less than 2 months ago) when getblocktemplate took more than 0.2s. I don't check often how it affects p2pool but I'm doing it right now (in fact I'm studying how the block size and fee limits affect getblocktemplate in the current situation, checking the efficiency is just a bonus). If the behavior of p2pool changed I'll know it in the following days and will be able to update my guide. For now I still recommend to keep it under 0.2s to be safe.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 03:10:40 PM
 #5536

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.

<shrug>

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.

As your post could be misinterpreted: to be accurate simply waiting didn't work: you had to update bitcoind to a version which includes the fix from sipa for the getblocktemplate low performance. The P2Pool version doesn't have anything to do with it and you verified it yourself by upgrading bitcoind and keeping the same P2Pool version.

Your trouble started when bitcoind 0.8.1 had to handle the current backlog of unconfirmed transactions. 0.8.1 could handle a normal block size worth of transactions (500kB to 1MB) without problems but it simply couldn't process more than 20MB of them efficiently until sipa fixed the code.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 03:14:54 PM
 #5537

Sweet. What's the harm in making my node include them all.

Difficult to say. With a default configuration your node won't include them all.

I'm testing lower fee limits to find out if it affects bitcoind and P2Pool negatively but it takes time. As I explained earlier old unconfirmed transactions move slowly and on each bitcoind restart you have to download them again from your peers (currently my bitcoind still can't fill a 500kB block with what it got from the network since my last restart).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Mogumodz
Sr. Member
****
Offline Offline

Activity: 290



View Profile
May 25, 2013, 03:26:22 PM
 #5538

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.

<shrug>

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.

As your post could be misinterpreted: to be accurate simply waiting didn't work: you had to update bitcoind to a version which includes the fix from sipa for the getblocktemplate low performance. The P2Pool version doesn't have anything to do with it and you verified it yourself by upgrading bitcoind and keeping the same P2Pool version.

Your trouble started when bitcoind 0.8.1 had to handle the current backlog of unconfirmed transactions. 0.8.1 could handle a normal block size worth of transactions (500kB to 1MB) without problems but it simply couldn't process more than 20MB of them efficiently until sipa fixed the code.

Cheers, I was trying to convey that simply updating the Bitcoin client solved it for me and that the p2pool version is the same as when the trouble started. I see how that can be misinterpreted as I was just listing everything I was using at the time and currently.

Bitcoin OTC rating GPG ID: 3E7974A1 P2Pool statistics: p2pool.info
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 25, 2013, 03:58:41 PM
 #5539

Roll Eyes There are such misconceptions floating around...

OK first mdude77 is wondering why the latency is lowered by restarting bitcoind and raises again.

When you restart bitcoind it doesn't save the list of unconfirmed transactions on disk: they are only maintained in what's called the memory pool.
When you restart it, at first it doesn't have any transaction in its memory pool. So any rpc call to bitcoind involving any parsing of the list of transaction in the memory pool is fast: getblocktemplate is obviously one of them as its goal is to build a template for a block including the tx in your memory pool that your bitcoind deems worth confirming.
Then your bitcoind learns of unconfirmed transactions at the rate at which it's neighboors (the nodes it's connected to) on the bitcoind P2P network transmit them. Only new transactions are automatically broadcasted and received by a freshly started node quickly, old ones are transmitted far slower to avoid network congestion. So a freshly started node gets new transactions appearing on the network quickly and slowly catches up through the backlog of unconfirmed transactions. The rate at which a node receives old transactions varies greatly: it depends on the nodes it is connected to (not every node is configured the same, some may relay more transactions than others).
This is why getblocktemplate latency is slowly rising and is perfectly consistent with getblocktemplate latency being heavily dependent on both the number of transactions your bitcoind accepts in its memory pool and the number of transactions it selects for confirmation (these being controlled by maxblocksize, minxtxfee and minrelaytxfee among others).

Second: the getblocktemplate and P2Pool orphan rate.
First a bit of vocabulary just to avoid any misunderstanding: what daemondazz calls P2Pool blocks are P2Pool shares.

AFAIK P2Pool doesn't need a fresh getblocktemplate to build a share. It can reuse a previous one (unless a Bitcoin block has just been found, then shares based on old templates would generate orphan blocks, see one of my earlier posts on why it's bad). The only drawback of using an old getblocktemplate result is that it doesn't include new transactions that were received after it (so it lowers the fee income and slow transaction confirmation a bit).

What the problem is is probably more subtle than that: P2Pool is an event-driven program (as opposed to multi-threaded or multi-process) with most of its event being handled asynchronously (waiting for a getblocktemplate result is probably done asynchronously).
What could happen but is very difficult to analyze is that the event-driven framework doesn't cope with long running queries as well for some obscure technical reason (like polling some event result in exponentially longer intervals instead of being woken up by a select or equivalent system call) or might have a timing problem when some task that can't be done asynchronously (like pure crypto computations) happens to be done right when the geblocktemplate comes back. There's even a system in place in P2Pool to punish shares computed from old templates when a newer block is known: P2Pool nodes generating them because of high getblocktemplate latency will most probably see them orphaned.

I don't know the exact reason why getblocktemplate affected efficiency and even if it's still the case today as forrestv might have changed something that removes this problem. It was still the case very recently (like less than 2 months ago) when getblocktemplate took more than 0.2s. I don't check often how it affects p2pool but I'm doing it right now (in fact I'm studying how the block size and fee limits affect getblocktemplate in the current situation, checking the efficiency is just a bonus). If the behavior of p2pool changed I'll know it in the following days and will be able to update my guide. For now I still recommend to keep it under 0.2s to be safe.

Thanks for the detailed explanation.  Now I understand, and it makes a lot more sense than it did before, and I agree with your conclusions.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 25, 2013, 07:12:54 PM
 #5540

Preliminary report of my testing of recent bitcoind builds.

As nothing seemed to bother bitcoind since sipa's patch was included, I decided to test really permissive settings.
I allow for the maximum block size supported by the protocol (1MB), fees only 10% of the default minimum and even allow for 400kB of fee-less transactions if nothing else is available. These last ones should help the network clean itself from these unconfirmed transactions and help people with older bitcoind versions which slowed down due to the current backlog.

Here are the modifications I'm testing right now:
Code:
blockmaxsize=1000000
blockminsize=400000
mintxfee=0.00001
minrelaytxfee=0.00001

Here are the default values according to "bitcoind --help"
Code:
blockmaxsize=250000
blockminsize=0
mintxfee=0.0001
minrelaytxfee=0.0001

Note : I believe the default blockmaxsize has been raised to 500000 some time ago with 0.8 (and according to the current main.h value for MAX_BLOCK_SIZE_GEN it should be), the help may be outdated or I may have missed something in the source code.

"bitcoind getmininginfo" is useful to check how the node includes transactions:
Code:
{
    "blocks" : 237896,
    "currentblocksize" : 998727,
    "currentblocktx" : 965,
    "difficulty" : 12153411.70977583,
    "errors" : "",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "pooledtx" : 2064,
    "testnet" : false
}
The currentblocksize is almost 1MB which is expected (it takes some time to reach it though).
The node selected 965 transactions out of 2064 it knows about (there are 5109 on the network according to blockchain.info but my node didn't see all of them yet).

The getblocktemplate latency started to rise but is still around 0.2s. My efficiency is still very good at 110-115%. I just restarted my P2Pool node to get more accurate values (it's an average and I didn't have the same bitcoind settings all along). I'll keep an eye on the node traffic too: I suppose that as nodes must verify shares they need to know all transactions used in the block templates which may mean more traffic with bigger templates.

What is surprising is that there's a log of transactions with fee/kB above 0.00001 and below 0.00005 (with 0.00005 I couldn't fill a 500kB block template). I wonder who/what is generating these transactions, certainly not ordinary users.

I've yet to see how bitcoind and P2Pool behave on a 24h period to make any recommendation but it seems that sipa's patch allows us to include far more transactions in our blocks without performance/income penalties. Generating 1MB blocks may even be doable (which may mean substantially more income and some troll repellent as a bonus).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Pages: « 1 ... 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 [277] 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!