PeakMiner tests automatic recovery after an internet outage
Source report: 2026-11-08 · Editorial analysis published: 2026-11-09
The November 8 release candidate separates connection recovery from the stable 2.20.7 efficiency changes for Pearl and Quantus.
A lost connection should not require a visit to the rig
PeakMiner published test build 2.20.8rc1 on November 8 to address a practical problem: an internet outage could stop a GPU (graphics-card) mining rig instead of leaving it ready to reconnect. The developer says a lost connection is no longer mistaken for deliberate blocking of the developer-fee connection. The software can keep running and reconnect when connectivity returns.
This matters for an unattended home rig or a machine at another location. An internet fault should be distinguished from a crashed miner before an operator decides what needs attention. Continuing to run without internet does not create accepted pool work: the important outcome is that the rig can return to submitting work after the connection is restored. The release is explicitly a prerelease for testing, not the recommended production build. The internet-channel repair also needs to be distinguished from a power outage. If the computer or router has lost electrical supply, this software change does not establish that either device will start automatically. Their return to operation needs its own check before reconnection can be observed.
The stable release changes a different part of the job
Earlier on November 8, stable version 2.20.7 introduced claimed efficiency improvements for Pearl and Quantus. For Pearl, the developer names NVIDIA GTX 16 and RTX 20, 30 and 40 cards with memory clocks locked at 405 or 810 MHz. For Quantus, the stated scope is RTX cards at those memory locks. These are specific software settings and supported families, not new specifications for every GPU.
Hashrate is the amount of mining work attempted per second; efficiency compares that work with the electricity used. A better rate per watt can come from more work, lower power, or both. The notes provide no universal percentage increase, so there is no sound basis for turning this announcement into a promised daily income gain. A miner should compare the same algorithm and settings over a similar period, including accepted work at the pool and power at the wall.
Pool support decides whether compression is used
Version 2.20.7 also lets Pearl share submissions use zstd compression. A share is a piece of work sent to the pool to demonstrate participation. The miner offers compression during login and the pool chooses whether it supports it. Where accepted, the developer reports substantially lower CPU use on the submission path; an incompatible pool continues with the ordinary format.
The useful distinction is between the GPU doing mining calculations and the computer packaging and sending the result. Reducing the latter workload is not proof that the GPU hashes faster. It may be relevant where the host processor is already busy, but no CPU-saving percentage or extra reward is established here. No new command-line option is needed to negotiate compression, and the release adds or removes no flags.
A frozen Windows card gets a different response
The later 2.20.8rc1 candidate changes Windows error handling: a frozen GPU or fatal device error ends the worker immediately rather than waiting indefinitely on a stuck driver. The intended result is an automatic restart. This is recovery from an error, not a repair to a physically faulty card or evidence that an unstable setting has become reliable.
Two other candidate changes need modest expectations. Pearl's displayed hashrate is steadier, while the actual GPU and pool work are unchanged by that display adjustment. Quantus receives a host-side correctness and stability fix whose results are described as bit-for-bit identical. A smoother number on the screen alone should therefore not be recorded as a performance improvement. The developer still asks testers to verify the Windows display sleep-and-wake case; it is not confirmed.
The version selected by the platform matters
The stable and test packages coexist. The developer says Docker's latest tag remains on 2.20.7, while the rc tag or the exact 2.20.8rc1 tag selects the candidate. Published HiveOS flight sheets also still point to 2.20.7; a custom installation URL is needed to select the test package. mmpOS likewise requires the chosen custom package. The candidate identifies itself with build 20261108-873e9d.
An interface saying that a miner is installed does not establish which of these versions is running. Record the reported version, operating system, GPU and driver before comparing results. Keep the working configuration and an identifiable previous package available. The author describes the stable 2.20.7 binaries as the same Linux and Windows files used for its preceding release candidate; a new version label should not itself be treated as another speed increase.
What a useful recovery check records
The developer requests an interrupted-uplink test lasting half an hour, followed by a check that the miner recovers without intervention. For an operator, the relevant records are when connectivity disappeared, when it returned, when the worker resumed and when the pool next accepted work. These are different events. A running process or an increasing local counter is not enough to establish successful reconnection.
ASIC.tools reviewed the official releases, versioned documentation and linked fault report; it did not install the binaries or reproduce the performance and recovery claims. The immediate choice is clear: 2.20.7 is the stable efficiency release, while 2.20.8rc1 is a separate opportunity to test recovery on a suitable spare rig. Neither announcement changes electricity prices, the coin's market price or the amount a pool will pay for a given accepted share.
Source: PeakMiner / official release notes ↗ · Stable 2.20.7 release ↗ · Original connection failure report ↗ · Versioned miner documentation ↗
Mining calculator ↗
