SRBMiner 3.8.2 revises the power tuner and targets NVIDIA 5000-series Pearl mining
Source report: 2026-10-29 · Editorial analysis published: 2026-10-30
The October 29 release improves the efficiency tuner, lists minor pearlhash improvements for NVIDIA 5000-series GPUs and fixes bugs. It supplies no numerical speed or power-saving guarantee.
A follow-up release, with a narrower change list
SRBMiner-Multi 3.8.2 was published on October 29 at 13:48:17 UTC as a regular release, not a prerelease. Its new change list covers improvements to the efficiency fine-tuner, minor pearlhash improvements for NVIDIA 5000-series GPUs and bug fixes. The author provides no measured percentage improvement. Users with that GPU and algorithm combination have a concrete reason to compare versions, without putting an invented gain into a revenue forecast.
Version 3.8.1 introduced the tuner described in our earlier report. Version 3.8.2 revises that existing feature; it does not introduce it for the first time again. The new release does not identify every fixed bug or promise that all NVIDIA generations and algorithms become faster. Its scope matters more than the version number alone.
The tuner still has specific prerequisites
The release describes the power tuner as a Linux/NVIDIA feature requiring root access (administrator privileges). It fine-tunes an existing overclocking configuration, meaning settings that change the GPU’s operating clocks. A locked core clock is required; devices left at automatic or stock core clocks are skipped. Downloading the new version therefore does not mean the feature runs on every installed GPU or on a Windows rig.
The option can lower consumption, but some configurations produce no efficiency gain and retain the original settings. The miner may restart several times while searching, resume tuning and either find a sufficiently stable result or restore the starting settings. That behaviour affects the useful work delivered during a test. Record when tuning ends rather than comparing the search period directly with an ordinary steady run.
A permitted speed loss is not a saving estimate
The current official parameter reference lists --gpu-power-tuner-loss with an allowed range of 1–25% and a default of 2.5%. This sets the permitted hashrate loss during tuning. It is not a promise of a 2.5% electricity saving, and allowing a larger loss does not establish that profit will improve. The release and the parameter page describe controls; they do not supply a universal result for an owner’s GPU, driver and clock combination.
A useful comparison keeps the same card, algorithm, pool and intended clock setup. Observe accepted work over a comparable period and measure actual electricity consumption, including relevant shared system loads. A lower displayed wattage can accompany lower output. Whether the trade is useful depends on the local tariff and the value of accepted work, rather than the smallest power number on the screen.
Pearl changes concern a named GPU generation
The new algorithm note specifically names pearlhash on NVIDIA 5000-series GPUs and calls the improvements minor. A reader using another algorithm or generation should not assume the same effect. This is a mining-client update: it does not announce a new Pearl consensus rule, activation height or guaranteed compatibility with a future network change.
For the stated target, a controlled trial can compare the new client with the previous working setup. Keep a copy of the working configuration and note version, driver, pool and measurement period. A very short burst of higher local speed is less informative than sustained accepted work. We reviewed the release and configuration reference; we did not install the executable or benchmark a graphics card.
Check the software source and the actual payment settings
The project publishes a 3.8.2 custom-miner archive for Hive OS. Its instructions require manual algorithm, pool and wallet configuration through the extra arguments field. The custom package does not decide those destinations for the owner. After a planned update, confirm the intended pool and receiving address and check that the worker returns to normal accepted submissions.
The release also publishes MD5 archive values. A matching checksum can identify an accidental download change, but it is not an independent signature or a guarantee of safety. Obtain the release through the author’s project rather than an unsolicited replacement link. For a stable rig, the practical decision is whether the specific tuner or pearlhash change improves a measured result enough to justify the change, not whether the newest label alone looks more profitable.
Use a controlled maintenance period for a trial that may restart the miner. Preserve the previous working client and its settings so a disappointing result can be compared with the real starting point. Avoid changing pool, driver and clock policy at the same time as the executable; otherwise even a correct measurement cannot isolate the software update.
The distinction between device selection and tuning selection also matters. The official parameter reference says GPUs to receive individual values must be selected with --gpu-id. Check which workers actually ran and which devices were skipped before aggregating a whole-machine result. This is configuration guidance, not a claim that every listed device has been tuned successfully. Measure electricity at the same wall-meter point in both runs. GPU telemetry and total installation input can cover different equipment, so comparing one with the other can manufacture an apparent efficiency gain.
Source: SRBMiner-Multi / doktor83 ↗ · Official parameter reference ↗ · Previous 3.8.1 release for comparison ↗
Mining calculator ↗
