Rejected and stale shares: diagnose the cause
Distinguish connection delays, configuration errors and unstable hardware before changing performance settings.
ASIC.tools · Reviewed
Understand the counters
A share is evidence of work submitted under a pool’s rules; it is not necessarily a block. Accepted, stale, duplicate and invalid submissions describe different outcomes. The labels and accounting can differ between firmware and pools. Record which interface produced each value and the interval it covers. Comparing a miner counter since boot with a pool’s daily report can create a misleading rejection rate.
Collect a comparable baseline
Observe the device after normal startup and tuning have finished. Save pool status, worker identity, firmware version and the time window alongside the counters. If the interface counts all submitted shares consistently, the rejected fraction is rejected submissions divided by total submissions. Do not use raw counts to compare workers with different assigned share difficulty unless the pool explains that this comparison is meaningful.
Investigate delayed submissions
For stale work, inspect connection interruptions, unstable routes, gateway logs and the time of pool changes. Compare a nearby supported endpoint on one device over a similar observation period. Physical distance alone does not determine network quality. A single round-trip latency measurement cannot describe intermittent packet loss or congestion. Keep the original endpoint available until the alternative produces stable accepted work.
Investigate invalid submissions
Repeated invalid work can require checking algorithm compatibility, connection settings, firmware support and hardware stability. Compare the behavior at a documented normal profile before blaming a pool. Save diagnostic logs before rebooting. If errors coincide with temperature alarms, missing boards or aggressive tuning, restore an approved configuration and investigate the underlying fault. Do not hide the symptom by disabling protection or repeatedly restarting the miner.
Escalate with usable evidence
Send the operator a precise time interval, worker identifier, relevant error messages and the changes already tested. Remove passwords and private data from shared logs. Change one variable at a time and compare like-for-like periods afterward. There is no universal rejection percentage that proves every model is healthy: the outcome should be stable accepted work and an explained reduction in the specific error category.
