Miner Uptime and Drops: Maximizing Operating Time

Miner uptime is measured by the time a machine hashes valid work and gets it accepted by the pool. A green interface with zero pool hashrate does not count. A drop is a break somewhere in that chain, and the diagnostic work is to name the link before ordering a part.

The full chain

For a share to exist you need, all at once: utility power and PSU, stable rails, live hashboards, a control board that holds, a network path to the pool, a job that is not stale, and a thermal envelope that stays inside limits. Breaking any one of those links takes hashrate to zero.

That is why hunting for "the" fault without naming the link ends in parts replaced for nothing. The six sections below cover each link and its characteristic symptom.

PSU

A PSU can die outright, in which case nothing powers on, or sag under load. In that second case the interface returns, boards go dark, a rail blinks, and an OVP, OCP, or OTP protection opens. Symptoms are usually collective: several boards, sometimes the whole machine, sometimes a reboot loop.

Look at the rack side before blaming the brick: a weak phase, a warm breaker, or a loose lug produces exactly the same symptoms as a tired PSU.

Heat

Overheating is either local, with one board, a dead fan, or dust, or hall-wide, with air recirculation or a seasonal effect. Firmware derates first, trips next, and sometimes reboots after that.

The time pattern is the best clue. A drop that repeats at the same hour every afternoon names the hall and its outdoor temperature curve, not the silicon. Always compare behaviour against the manual's thermal policy and against the machines in the same row.

Network

Network faults sort into three layers: no IP at all, an IP but no interface, or an interface but no pool. Each points at different causes, from cable and switch through VLAN, DHCP, firewall, DNS, MTU, and the route out.

The classic trap: a miner still hashing an old job sends stales while displaying a flattering local hashrate. A controller rebooting on a flaky link, from odd PoE, an STP loop, or weather on a copper row, imitates a hardware fault perfectly.

Pool

Wrong endpoint, a certificate refused because of a drifted clock, wrong credentials, pool-side saturation or maintenance, a Stratum dialect that stopped matching after a flash: in all of those, the hardware can be perfect.

The test that settles it is immediate. If another worker on the same site sees the same hole over the same window, the problem is at the pool. If neighbours mine normally, the problem is on that machine or its network segment. Switching pools when a single IP is affected just hides the symptom.

Hashboard

When a board drops, hashrate steps down, errors appear on one line, and the board shows as missing. Possible causes are the silicon, the connector, that board's own rail, or firmware that no longer recognizes it.

When several boards drop together, step back one level: PSU, controller, shared heat, or firmware image. Isolating the role before replacing the part consistently shortens the diagnosis, as detailed in the article on hashboards and the control board.

The method in five points

1. Which link broke? The hash itself, pool acceptance, or network presence. Those three separate in about a minute with the interface and the pool page.
2. One machine or many? One unit, one row, one model, one firmware image. The scope names the cause almost on its own.
3. When did it happen? After a flash, a storm, a PSU change, a heat wave. The timeline beats any hunch.
4. Roll back the last change before adding a second one. Two simultaneous modifications make the result unreadable.
5. Write down what you saw: interface logs, the state of neighbours, the action taken, the time. Without that journal, the same fault gets diagnosed from scratch every time it recurs.

A drop is a dated signal. What costs money is not the fault itself, it is the time between the machine dropping off and someone naming the right link.