Bitcoin Forum

Okay. I've been running a miner for somewhat a week now and recently have set up the flexible mining proxy (http://forum.bitcoin.org/index.php?topic=5506.0), found on this forum. As i had some problems with that and wanted to understand, what's going on behind the curtain, i extended the codebase by some logging and a console window. By doing that and observing the output of the communication client<->proxy, i noticed a strange behaviour of the mining clients, that i do not understand:

The worker logs in to the proxy, new work is requested and forwarded to the client. The client starts processing.
So now, after 45-50 seconds the client logs in again and requests new work again, no matter if it has returned a result for the work it has previously requested or not.
It can happen multiple times in a row, that it re-requests new work, without returning something.
On the other hand it can happen, that the client is able to provide, say, 2-3 solutions within that said 45-50 second time frame.
So everything from 0-X results may get returned by the client between those calls to fetch new work - i supposed this is bases solely on luck.
Thing is, if it will not return something, the ratio requested:returned will go down, which, sounds bad and as a side-effect, it got me banned on BitcoinPool.com.
I tried a lot to figure out, why there is this re-request every 45-50 seconds and how to change it.

I even tried to implement a very basic throttle, that will keep track of the number of work units the client is currently working on and which blocks all further requests, until solutions for the these units are returned by the client. The throttling did not work as expected: the miner went somewhat crazy by not getting new work. The miner even ran out of work and stalled, when it was working on a work unit and for some reason kind of discarded it, without returning a solution for it, which would have freed up the slot for a new request.

tl;dr
The client requests new work every ~45-50 seconds, no matter if it has returned a result for the previous work or not. This decreases request:returned ratio.
Why is that happening? Can this be prevented? Is there a good explanation about the techniques behind all this around? All i could find was some basic blah blah. :|
( A side question would be: what exactly does the client get from the pool? If mining solo, i work on a whole block, but what am i mining on when mining for a pool, exactly? :) )

Here's a sample of my log:

[ 19.06.2011 13:56:10 ] [3] Polling BitcoinPool
[ 19.06.2011 13:56:11 ] [3] BitcoinPool responded.
[ 19.06.2011 13:56:11 ] [3] Processing work for BitcoinPool (09fb56385d5851ce7533d20134635832)
-------------------------------------------------------------------------
[ 19.06.2011 13:56:33 ] [3] Worker returned work for BitcoinPool (09fb56385d5851ce7533d20134635832)
[ 19.06.2011 13:56:33 ] [3] Sending work to BitcoinPool ......success!
[ 19.06.2011 13:56:34 ] [3] Work unit is:valid
-------------------------------------------------------------------------
[ 19.06.2011 13:56:55 ] [3] Worker returned work for BitcoinPool (09fb56385d5851ce7533d20134635832)
[ 19.06.2011 13:56:55 ] [3] Sending work to BitcoinPool ......success!
[ 19.06.2011 13:56:56 ] [3] Work unit is:valid
-------------------------------------------------------------------------
[ 19.06.2011 13:57:01 ] [3] Polling BitcoinPool
[ 19.06.2011 13:57:02 ] [3] BitcoinPool responded.
[ 19.06.2011 13:57:02 ] [3] Processing work for BitcoinPool (09bde84558a701a39f07224b3bc9c83c)
-------------------------------------------------------------------------
[ 19.06.2011 13:57:53 ] [3] Polling BitcoinPool
[ 19.06.2011 13:57:54 ] [3] BitcoinPool responded.
[ 19.06.2011 13:57:54 ] [3] Processing work for BitcoinPool (5e779c1f2a8227810ccc1785f5835cd5)
-------------------------------------------------------------------------

Here you can see the first work request.  Soon two solutions are found and returned for that work. After 51 seconds, new work is requested. After another 52 seconds, again, new work is requested and no result has been found in the meanwhile., efficiency goes down. *rinse-repeat*

Thank you for reading and for clearing things up for me! :)
krom

"Work" in the case of mining is a 1024-bit string returned by the server. The miner must then adjusts a 32-bit value within there, called the nonce, from 0 to 4,294,967,296; hashing it every time to see if the resulting hash is "valid."

Because of the way hashing works, the miner may find that no nonces result in a valid hash; or it may find that many nonces result in valid hashes. This is, as you've discovered, just the way luck works in the mining game.

After the miner has checked all 0 to 4,294,967,296 possible values for nonce, it cannot do any more work on those 1024-bits it received. It must get new work from the server. Your miners are probably requesting work every 45-50 seconds because that's how long it takes to run through all the possible values for the nonce.

As long as you are using mining software designed to achieve 100% efficiency (sounds like you are), then no, there is nothing more you can do.

You're also working on a whole block, but it's a block that belongs to the pool. The difference is that, for solo mining your miner must find a nonce that results in a hash that meets the current Difficulty. That's very tough to do! A mining pool, on the other hand, will accept hashes that meet Difficulty == 1. Easier work, but of course those results are worth less to the pool.

Ah okay. Thank you very much for clearing things up for me. I think i have a better understanding of what's going on, now. But i think there is an additional reason, why the client fetches new data. This is because my CPU miner, which is ofc. very slow, requests new work every somewhat 60 seconds and i doubt, that it can go through all nonces in this short time.

Another thing i've noticed btw.:
My version of proclbm (included with guiminer) is not updating it's internal timer, when getting new data through a long poll. It will fetch new work every X seconds, no matter if it got new work through a long poll a second ago. I didn't notice this behaviour in DiabloMiner, so i think it's not meant to be this way.
This supports my theory, that there has to be another or additional reason for the client to fetch new work, me thinks.

But, in the end, a lot of getworks are not bad for me, but for the pools, because they get more requests, right? I don't think i should have to care about that too much any further, should I? :)

From a technical perspective, the client doesn't need to request work more often than has been outlined. However, the reality is that a lot of mining software will request work at fixed intervals anyway (in addition to Long Polling). This is for two reasons. Historically, Long Polling didn't exist; so asking for work frequently was the only way to prevent a large number of stale shares. A lot of mining software stuck to keeping that "askrate" functionality, and adding Long Polling alongside it. "If it isn't broken, don't fix it," sort of mentality.

The second reason is, well, things break. Long Polling may fail, and the software may not even know that it failed. So asking for work every so often, despite what the Long Polling functionality may have indicated, is a good backup plan to prevent stale shares.

Correct, extra getworks really only affect the pools. If your ISP has strict bandwidth limitations then maybe it has an impact on you as well. But it doesn't cost you extra processing power and memory, like it does the servers.

I've only seen one pool that has explicitly made the "efficiency" of the miner an issue; BitcoinPool.com. It's commendable, for sure; waste is waste, no matter how you look at it. But achieving 100% efficiency while keeping stale shares to a minimum is a technically difficult challenge, and the mining software developers aren't getting paid for their work  :P