I see a lot of complaining about people asking about high rejection rates, but are we any closer to figuring out if expiry and scan-time really have any effect on reject rates with CM?
In all my experiments with settings, I couldn't seem to find a combination that really made a difference.
Also there's a lot of poor and misguided advice on how the expiry, scan-time and queue settings actually influence the rejections you're experiencing.
A lot of these settings were made for HTTP communication and not the much more efficient stratum protocol*.
--expiryThis setting defines how long time it takes before a work share is declared stale.
It is
not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the statrum server is broken, then the setting is used as a fallback value.
Recommendation: Leave at default setting. Server will supply a proper setting.
To verify above simply follow the opt_expiry variable in cgminer.c source file.
--scan-timeThis setting defines how long time, in seconds, the client should spend scanning current active work.
Again a setting that is
not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the setting is lower than the server supplied setting, then it'll potentially generate more stale work.
Recommendation: Leave at default setting, which is 30 seconds for scrypt.
To verify above simply follow the opt_scantime variable in cgminer.c source file.
--queueThis setting defines how many work items you minimum got waiting in queue.
It is only relevant to prevent downtime when the stratum server is too slow at serving new work shares.
Recommendation: Leave at default setting, which is 1.
To verify above simply follow the opt_queue variable in cgminer.c source file.
* Stratum mining protocol:
http://mining.bitcoin.cz/stratum-mining and
https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533
