Bitcoin Forum
December 11, 2016, 08:20:12 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Pool mining: why are some shares rejected?  (Read 5624 times)
Proofer
Sr. Member
****
Offline Offline

Activity: 251


View Profile
December 29, 2011, 04:18:02 PM
 #1

What is/are the cause(s) of share rejection?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 29, 2011, 04:25:45 PM
 #2

What is/are the cause(s) of share rejection?

They are either invalid (bad hash of good data) or stale (good hash of bad data)

When a block is found any share you are working on or submitting is no longer worth anything.  They are stale.   If you push GPU too hard it will make mathematical errors producing invalid hashes.
Proofer
Sr. Member
****
Offline Offline

Activity: 251


View Profile
December 29, 2011, 04:47:44 PM
 #3

What is/are the cause(s) of share rejection?

They are either invalid (bad hash of good data) or stale (good hash of bad data)

When a block is found any share you are working on or submitting is no longer worth anything.  They are stale.   If you push GPU too hard it will make mathematical errors producing invalid hashes.

In Mining > Pools I see occasional mention of rejection rates.  I assume these are stale shares rather than hardware errors. Why would some pools (or mining software) be better than others in reducing stale shares?
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 29, 2011, 06:40:21 PM
 #4

What is/are the cause(s) of share rejection?

They are either invalid (bad hash of good data) or stale (good hash of bad data)

When a block is found any share you are working on or submitting is no longer worth anything.  They are stale.   If you push GPU too hard it will make mathematical errors producing invalid hashes.

In Mining > Pools I see occasional mention of rejection rates.  I assume these are stale shares rather than hardware errors. Why would some pools (or mining software) be better than others in reducing stale shares?

Timing.

A timeline to illustrate
1) A new block is published to the network (time starts)
2) Currently all miners are now working on stale (worthless) data
3) Pool server must be notified of block change (latency from average block to pool server, more links = better)
4) Pool server must generate new merkle tree
5) Pool server must issue LP and new work (latency between pool server & miner)
6) Client must receive LP and change data being worked on (time stops)

The amount of time spent doing those 6 steps will vary by pool and thus pools will have differing amount of stales.

Some pools (like slush for example) complete step 5 in order of miner size to ensure largest miners are updated as quickly as possible.  That bring effective hashing power closer to max quicker.

A good pool should:
a) have thousands of connections to bitcoin network to ensure it is quickly notified of all blocks found
b) actively search out IP addresses of other block generators to ensure they are in list of known nodes
c) have sufficient CPU power to quickly (as in fraction of a second) generate new work for all miners after block change
d) have low latency link to all miners (this is partially beyond control of pool)

Stales can never be brought to 0 but they can be significantly reduced.  On Bitminter my reject rate of prior 30 days is 0.04%.  I believe about 0.02% of that is due to hardware failures (one GPU has higher reject rate than all other GPU) so roughly 0.03% of that is pool inefficiency which is pretty damn good.  Anything below 0.1% should be considered good.  Anything above 1% is horribly bad.  Most miners have 0.1% to 1% stale rate.
Proofer
Sr. Member
****
Offline Offline

Activity: 251


View Profile
December 29, 2011, 08:22:06 PM
 #5

Thanks.  And I notice that cgminer sometimes beats the pool server, although I guess it still has to wait for the pool server to send work:

[2011-12-29 12:16:50] New block detected on network before longpoll, waiting on fresh work
[2011-12-29 12:16:50] LONGPOLL requested work restart, waiting on fresh work


DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 29, 2011, 08:25:05 PM
 #6

Thanks.  And I notice that cgminer sometimes beats the pool server, although I guess it still has to wait for the pool server to send work:

[2011-12-29 12:16:50] New block detected on network before longpoll, waiting on fresh work
[2011-12-29 12:16:50] LONGPOLL requested work restart, waiting on fresh work


Yeah that is an optimization by the author.  Yeah you still need to wait for work but it saves a small amount of time.  Remember once an OpenCL kernel starts it will have to finish you can't interrupt it.   When cgminer detects work is stale it can clear the q, prevent miner from starting on stale work and wait for new data. 
ZodiacDragon84
Sr. Member
****
Offline Offline

Activity: 266


The king and the pawn go in the same box @ endgame


View Profile
December 30, 2011, 09:14:26 PM
 #7

I use bitminter, and have way lower stales and no rejects so far. Im only averaging about 103.3 Mhash/s, so maybe my slower speed keeps the stales down? on a serious note, can 2 miners discover the same share, and what would happen if they did?

Looking for a quick easy mining solution? Check out
www.bitminter.com

See my trader rep at Bitcoinfeedback.com
!
Pages: [1]
  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!