Testing Overclock Stability: Why Ten Minutes Is Not a Test
You set a preset, it holds for ten minutes without crashing — "stable, ship it". Three days later the rig restarts every night. Instability rarely shows itself immediately: it hides in rare events that only a long run with a log can catch.
TL;DR (for those skipping the read)
- A short test only catches gross overshoot. Subtle instability shows up as rare errors — once every few hours or days.
- A reference run is at least 24 hours of real work on the preset, with a log of errors, restarts and temperatures.
- Signs of instability: compute errors counted by the miner, restarts, a rising share of stale shares, drifting hashrate.
- Change one parameter at a time, with a fresh run after each change — otherwise you never learn what helped.
- Stability must be re-verified after every algorithm, miner or driver change — and after seasonal warming.
Why short tests lie
Overclock errors are probabilistic events. A preset "on the edge" may produce one error per hour: in ten minutes you see nothing, but over a week that is 170 errors and several restarts. Worse, some errors do not crash the miner — they just get rejected by the pool, while the "rig-side" hashrate looks great (see the pool-vs-rig article).
The second reason is temperature. A card reaches full heat in 20–40 minutes; the room and enclosure take hours. A preset that is stable "cold" may drift by evening, once everything around it has soaked. A short cold test measures a different system than the one that will run for weeks.
And third: mining load is not constant. Different tasks stress the card differently, and a borderline preset crashes exactly on the "awkward" work — which may simply not occur within ten minutes.
What counts as instability
- Compute errors counted by the miner. A small background level is tolerable on aggressive memory, but growth is a direct signal to step memory back.
- Miner or rig restarts. One restart per day is already instability, not a "glitch". Causes vary, and the preset is only one of them (the hang checklist is here).
- A rise in stale and rejected shares with an unchanged network — the card finishes the math but gets it wrong.
- Drifting hashrate with no external cause: the card keeps dropping into self-protection and recovering (throttling looks similar — how to tell them apart).
The run protocol and the log
The working protocol is simple: apply the preset → 24 hours of work → read the log. Clean — the preset is accepted. An error or a restart — roll back the last step and repeat for 24 hours. Yes, it is slow: full manual tuning stretches into weeks exactly this way (the arithmetic is in the manual-vs-auto article).
The log beats gut feeling: "seems fine" does not survive against records. The minimum set — time, card, event (error, restart), temperature at the moment of the event. The log also reveals patterns: errors every hot night are temperature, not tuning; errors after a preset change are tuning.
And remember re-verification: presets "expire". An algorithm change (see core vs memory), a miner update (when to update), a new card in the rig (the burn-in), summer heat — each is a reason for a fresh run, not for faith in the old one.
Where automation fits
A long logged run is a perfect job for automation: boring, slow, demanding discipline. OCBot validates every tuned preset through extended operation rather than a ten-minute glance, and keeps a per-card event history — patterns appear without a hand-written diary. If a preset drifts a month later, you see it in the log, not in fallen revenue.
This article is general information summarizing common practice; actual stability limits depend on your GPU and algorithm. OCBot is an independent project, not affiliated with NVIDIA or HiveOS/Hiveon. Use at your own risk: disclaimer.