When I mine at a pool, only a part of my shares are accepted. There is a small percentage which is marked as stale.
As far as I know I only get paid for accepted shares, so what are these stale shares and how can I avoid them?
Bitcoin Stack Exchange is a question and answer site for Bitcoin users, developers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this communityStale shares are the shares that were sent after a block was already solved, that is to say, they were sent late and were no longer valid. To avoid stale shares, best to have a reasonably fast mining rig (so you won't take too long to calculate a share, probably not a problem for most machines), reliable internet connection (stable, not necessarily fast), but also an up-to-date mining software (if you are mining with some really old miner it might not communicate in the most efficient manner with the pool).
In short - update your miner every now and then, make sure your internet is running okay, and don't mine on really weak rigs.
A stale share occurs when you find a share and submit it to the mining pool after the pool has already moved on to the next block. The percentage of stale shares should be very low if everything's working correct, around 2 out of 1,000 shares or so.
Several factors affect the stale share rate. The three most important are long polling, pool load, and miner-to-pool latency.
Any shares found based on old work units after the pool controller receives a new block will be stale. Long polling is a technique that allows the pool to notify all of its miners when there's a change in the block chain so they can immediately request new work units. If your pool or mining software doesn't support long polling, you will finish out the old work units, generating stale shares.
When the long polling notification goes out, all miners that support long polling request new work units at about the same time. This generates a massive burst of load as the pool has to manages lots of network traffic and do several SHA-256 operations for each share it issues. If the pool is slow to issue you a new work unit, the window in which you can generate stale shares increases.
The long polling and subsequent share request process requires a few network operations. Latency between the miner and the pool can slow this process down. Picking a pool with a controller near you (network wise) can reduce this part of the stale share window as well.
In addition, some pools have had bugs in their software that produced stale shares. The pool checks if the share is stale by seeing if it has a record of the work unit and clearing all work unit records when the chain changes. So if something goes wrong with the work unit tracking process, that will result in a stale share being reported.
For example, if the pool erroneously issues the same work unit to two miners, the first one to submit the share will get credit. The pool will remove the record when the share is found because otherwise you could submit the same share more than once. This will result in you getting a stale share report.
I probably shouldn't admit it, but I was actually responsible for one such bug. My first implementation of long polling in the Bitcoin client rushed as quickly as possible to send out the notifications of a new block being discovered to miners -- so quickly that some miners could request new work units before the client had finished processing the new block and they got work units based on the old block. Any shares they submitted based on those work units would be reported as stale.
The above answers are good but one thing I would add is that hashing rate affect stale share %.
Why? Because with a faster miner a smaller % of shares are even "at risk" of being stale.
Pools only pay for completed shares. A block is found on average every 10 minutes so in that 10 minute window the last share is the one at risk of being stale. Now the time between blocks varies but is 10 minutes on average so we will just look at affect of hashing power in a 10 minute window.
A 100MH/s miner would complete (on average) one share every ~42.9 seconds. Which means in 10 minutes it could complete ~14 shares. A 800MH/s miner would complete one shares 5.36 seconds. In 10 minutes that is ~112 shares.
If both miners are working properly and connected to fast accurate pools at most they will lose one share. In other words for the slow miner 1 in 14 shares are "at risk" while with the fast miner only 1 in 112 shares are at risk. The far extreme of this would be trying to mine with a slow CPU. Your hashing rate could be so slow that on average you only complete 1 share per 10 minute block. So 100% of your shares are at risk of being stale.
Everything else being equal a faster miner is more efficient putting less shares at risk of being stale.
Note: for this purpose only the single GPU hashing power matters not the total rig or farm hashing power.
The amount of data required for a standard rig isn't very high. There are a few things that I would suggest if you are having issues.
If you do this, you will notice a considerable improvement on your network.
I was also facing the same problem that time. This problem was due to my usb device (modem) which give internet access to my rig, when I remove that usb modem and connect the rig with my phone via USB than i saw a huge change in the mining performance.
My stale share which came down from 30% to almost 3%. My modem was connected directly to motherboard and it may be it got disturbance signal from all my gpus. It was network problem and make sure the device which you use for giving internet to rig should be kept far from it.
In given picture you can see how much stale shares drops from left to right .
Recently, SparkPool released a new version, added the feature that display stale shares. Some miners are asking what is stale share, we think it is necessary to explain it in detail.
Under the current POW mechanism, the mining pools push calculation task to the miner continuously. If the mining pool receives the share of the last task submitted by the miner after a new task is sent, this share is a stale share. Of course, there is no need to worry too much about it. Stale shares will be calculated as income, but it will be slightly lower than the normal share.
The delay is mainly affected by the miner's network status, and a good network performance will greatly reduce the chance of stale shares. We hope that the miners improve their own networks, and the SparkPool will be continuously optimized the servers simultaneously. If you have any other questions, feel free to contact our customer service staff.