Miners are constantly dropping

[GregoryGHarding]

stop solo mining and see if theres an improvement

[CSZiggy]

What version of the bitmain firmware are you using on those machines?

[robeca]

Miner Type Antminer L3+
Hostname antMiner
Model GNU/Linux
Hardware Version 1.0.1.3
Kernel Version Linux 3.8.13 #22 SMP Tue Dec 2 15:26:11 CST 2014
File System Version Fri Aug 25 17:28:57 CST 2017
CGminer Version 4.9.0
Uptime 10
Load Average 1.34, 1.27, 1.24

[alim]

@robeca, My asics look similar to yours. Here's my theory about the spikiness

1. The miner hashes at a near constant rate
2. With the workstarts + penalty, there is a 1.xx second plus delay between submissions and starting the recording for the next block.
3. The graph inadvertently displaces this hash power as a spike between the last time it checked

If the discrepancy is between the 2 hour hash figure and the display on your miner - eg miner says 13.xx TH and Prohashing says something like 25% plus below, I would check the password arguments.

I know that others disagree (@CSziggy included), but since I change the password parameters to include the bit below, my S9 / T9 miners are no longer considered to be bad luck miners..

scan-time=7 expiry=28

[CSZiggy]

There were no settings the users were able to change to change them off of being low-luck miners. The mining pool released updates that relaxed the parameters of what a low-luck miner was. Your adding those settings were not the cause-effect reason you are no longer a low-luck miner.



SCAN TIME - EXPIRY


Quote from: Kalroth from a post 4 years old now.

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*.

--expiry
This 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-time
This 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.

--queue
This 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 http://bitcointalk.org/index.php?topic=108533.0





From here: https://www.reddit.com/r/VertcoinMining ... ime_queue/
or from here: https://bitcointalk.org/index.php?topic ... msg5494025