[20 BTC] Multithreaded Keep-alive Implementation in Bitcoind - page 8.

somebadger

member

Activity: 170

Merit: 10

Quote from: TeraPool on July 06, 2011, 02:55:34 AM

QUESTION

JoelKatz's optimizations here will probably never make it into the official bitcoin github account, will they? Because they typically only make sense for pool operators or am I wrong?

The patches I believe will definitely make it in because that can benefit everybody. (Great work!)

So if anyone downloads the latest "v0.3.24rc3" or later from somebadger's github account, then it will contain JoelKatz's latest "diff" as seen here http://davids.webmaster.com/~davids/bitcoin-3diff.txt Huh

Will somebadger's fork always contain the new pool related code? Just wondering if I should just make my own github fork of bitcoin just for my own pool so I can keep track of this and any future similar changes.

Great work JoelKatz. Thank you for that contribution to the community!

My plan is to keep the fork upto date with any improvements for pool operators, i'll also be adding bitcoin pulls that help pool performance

ps. its patched based on http://davids.webmaster.com/~davids/bitcoin-4diff.txt and modifications to make it apply to the latest build

TeraPool

newbie

Activity: 42

Merit: 0

Quote from: somebadger on July 06, 2011, 12:22:40 AM

i just merged your diff with the latest from the official bitcoin git,

https://github.com/somebadger/bitcoin

I also added the following to --help

Code:

-pollpidfile= Pushpoold Pid file for long polling support
-hub= Hub mode for pool operators

other than some manual intervention and fixing CReserveKey::CReserveKey(CWallet*) syntax for the latest build it wasnt too much of a headache. enough though that i'm keeping it in git now Tongue

ps. i hate manually doing .rej's lol

QUESTION

JoelKatz's optimizations here will probably never make it into the official bitcoin github account, will they? Because they typically only make sense for pool operators or am I wrong?

The patches I believe will definitely make it in because that can benefit everybody. (Great work!)

So if anyone downloads the latest "v0.3.24rc3" or later from somebadger's github account, then it will contain JoelKatz's latest "diff" as seen here http://davids.webmaster.com/~davids/bitcoin-3diff.txt Huh

Will somebadger's fork always contain the new pool related code? Just wondering if I should just make my own github fork of bitcoin just for my own pool so I can keep track of this and any future similar changes.

Great work JoelKatz. Thank you for that contribution to the community!

somebadger

member

Activity: 170

Merit: 10

No probs

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Thanks.

somebadger

member

Activity: 170

Merit: 10

Quote from: JoelKatz on July 06, 2011, 12:50:22 AM

If you get the chance, a pull request for the two resource leak fixes would be nice.

That would be this change to net.cpp:

// Send and receive from sockets, accept connections
- pthread_t hThreadSocketHandler = CreateThread(ThreadSocketHandler, NULL, true);
+ CreateThread(ThreadSocketHandler, NULL);

And this change to util.h:

return (pthread_t)0;
}
if (!fWantHandle)
+ {
+ pthread_detach(hthread);
return (pthread_t)-1;
+ }

Patched and submitted pull request
https://github.com/bitcoin/bitcoin/pull/385

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

If you get the chance, a pull request for the two resource leak fixes would be nice.

That would be this change to net.cpp:

// Send and receive from sockets, accept connections
- pthread_t hThreadSocketHandler = CreateThread(ThreadSocketHandler, NULL, true);
+ CreateThread(ThreadSocketHandler, NULL);

And this change to util.h:

return (pthread_t)0;
}
if (!fWantHandle)
+ {
+ pthread_detach(hthread);
return (pthread_t)-1;
+ }

somebadger

member

Activity: 170

Merit: 10

i just merged your diff with the latest from the official bitcoin git,

https://github.com/somebadger/bitcoin4pools

I also added the following to --help

Code:

-pollpidfile= Pushpoold Pid file for long polling support
-hub= Hub mode for pool operators

other than some manual intervention and fixing CReserveKey::CReserveKey(CWallet*) syntax for the latest build it wasnt too much of a headache. enough though that i'm keeping it in git now Tongue

ps. i hate manually doing .rej's lol

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Thanks for that report. I'll check the code and see if I can get the SIGUSR1 to be sent faster. I think that will solve half the problem though. While pushpool will issue fewer blocks that will turn into stale shares, bitcoind will still be processing the new block when all the new 'getwork' requests start piling in, and you'll get miner idles instead.

I have a fix for this that has other benefits as well, but the first time I tried to implement it, it was a disaster. I think I know the right way to do it now, having run out of wrong ways to do it already. What I'd like to do is pre-compute the skeleton 'getwork' block when a new block or new transaction comes in, rather than waiting to hijack the next 'getwork' request to do it. But to make this work, the locking has to be exactly right. The funny thing is, in my day job ten years ago, this was exactly the type optimization I specialized in. And now I can't seem to quite get it right.

MrSam

member

Activity: 112

Merit: 10

Joel,

I wanted to thank you ! The patch works really well now ..

The only issue that remains is that the USR1 signal has a bit of a delay.

pushpool debug:
[2011-07-05 23:36:1.710434] USR1 signal received, flushing LP waiters
if i check blockexplorer, that block was found at 2011-07-05 23:35:31)

[2011-07-05 23:33:36.427621] USR1 signal received, flushing LP waiters
real time 2011-07-05 23:33:24

[2011-07-05 23:30:36.337827] USR1 signal received, flushing LP waiters
real time 2011-07-05 23:30:20

When i test this on my mining rig at home, the rejected blocks are just those few seconds between the found block and the sig.

MrSam

member

Activity: 112

Merit: 10

.

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Quote from: MrSam on July 04, 2011, 06:12:57 PM

hmm, where can i get v0.5 ?

I tried 0.4 yesterday but wont work, bitcoind crashes after pushpool sends many
'HTTP request failed: The requested URL returned error: 500' and opened like 20k sockets in seconds

http://davids.webmaster.com/~davids/bitcoin-4diff.txt

I'm starting to suspect the newer issues are coming from pushpool, but I'm not 100% sure yet. I'm not going to have much time today, but I hope to investigate in more detail tomorrow.

MrSam

member

Activity: 112

Merit: 10

hmm, where can i get v0.5 ?

I tried 0.4 yesterday but wont work, bitcoind crashes after pushpool sends many
'HTTP request failed: The requested URL returned error: 500' and opened like 20k sockets in seconds

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Quote from: phorensic on July 01, 2011, 11:56:24 AM

Great progress! One question, are we tracking this fork on github? I didn't see the patches on the network graph there.

No, I'm not doing that ... yet!

phorensic

hero member

Activity: 630

Merit: 500

Great progress! One question, are we tracking this fork on github? I didn't see the patches on the network graph there.

Jine

sr. member

Activity: 403

Merit: 250

Hi!

We're running the "master node" upon a 2*Intel Xeon E5504 (8 cores in total);
http://data.fuskbugg.se/skalman02/4e0deb49dc5b9_tits.png

So far it looks good for me. And no, no blkmond.
But i think we're still experiencing a bit of lag / stales when LP is pushed, due to huge amounts of connections I'd think.

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Awesome. I'm glad all of my code bits are getting "real use". Let me know if people are still seeing a higher percentage of stale blocks. It's possible the daemon just needed some time to 'settle in' as it makes connections and so on. My next set of changes may fix this anyway, it's designed specifically to reduce latency in 'getwork', particularly around reorganizations and transaction list changes.

Make sure your CPU has the juice to run at "-hub=2". Note that with a multi-core CPU, things can be deceptive. Bitcoind isn't very well multi-threaded -- if one core is maxed out, there's a good chance bitcoind is CPU limited. My next changes after the changes I'm working on now are expected to be better multi-threading of the code that handles I/O.

You did remember not to run blkmond, right? It will conflict with native long polling.

Jine

sr. member

Activity: 403

Merit: 250

Hi!

This should answer both of those:

Code:

BITCOIND_OPTS="-conf=/etc/bitcoin.conf -pid=/var/run/bitcoind.pid -hub=2 -pollpidfile=/var/run/pushpoold.pid -daemon"

In other words: hub level 2, and yes - built in LP.

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Quote from: Jine on July 01, 2011, 12:41:04 AM

We're running the latest 0.5 patch since last night - and it seems to work just fine.
Although - a couple of users have complained about higher stale-count.

Is that something you are aware of that could be a sideeffect of the modifications?

LP seems to work just fine tho.

I'm not really quite sure. Two questions:

1) Are you using any of the hub modes? If so, which level?

2) Are you using my long polling or are you using blkmond?

Jine

sr. member

Activity: 403

Merit: 250

We're running the latest 0.5 patch since last night - and it seems to work just fine.
Although - a couple of users have complained about higher stale-count.

Is that something you are aware of that could be a sideeffect of the modifications?

LP seems to work just fine tho.

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Thanks for the testing and the report.

I believe your diagnosis is probably right. I've been trying to figure out why that latency is so high. It turns out that when processing a significant change, like when a new block has been found, the code has to do a whole bunch of stuff. Coincidentally, this is exactly the same time every client needs new work. I believe the mechanism is contention on the cs_main mutex, which 'getwork' needs in this case because it calls CreateNewBlock. I'll do some head scratching.

One way to fix this might be to pre-compute the information 'getwork' needs so we don't have to wait for a 'getwork' request to do it. That would allow 'getwork' to run without touching the cs_main mutex. I'll need to instrument the code to confirm that's the issue before putting the effort into a change that might fix something that's not actually a problem.

Topic: [20 BTC] Multithreaded Keep-alive Implementation in Bitcoind - page 8. (Read 31406 times)