It has the turbo RPC changes, the new hub mode to reduce stale/lost blocks, and native long polling support. Please read the documentation at the top of the file.

CAUTION: This code was just finished and has not been well-tested. Test results are appreciated. Bug reports and success reports are equally welcome.

Update: Version 0.4 is now up. It fixes a bug that could cause bitcoind to hang when directed to shutdown.

Currently testing v0.5 on live server.... (a whopping 3 users since relaunch). Will let you know how it turns out.

So far so good. LP notifications seem faster than a certain unnamed big pool Also it seems to favor my pool during new getwork causing my pool to get a higher share of hashrates than said big pool when using hashkill.

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.

I am an employee of Ripple.1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN

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.

I am an employee of Ripple.1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN

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.

I am an employee of Ripple.1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN