Topic: Pool mining: why are some shares rejected? (Read 17992 times)

Me too. Using https://mines.smartcash.cc/ My rejection is around 98% 78 shares rejected out of 79. WTF?

P.S. using Win10, Claymore dual 11.8, RX460, tried different difficulties, same $#it.

What does it mean to push a miner too hard?

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?

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. 

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

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.

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?

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.

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