Diagnose reduced hashrate and missing chains

Start with a precise complaint

A ticket that says ‘low hash’ names a result, not a cause. Before you choose where to look, turn it into a statement another technician can test. Which asset? Which measurement? How far below what expected value? Since when? A miner reporting 80 TH/s could be faulty. It could also be running an approved reduced-power profile, still starting up, or being compared with the wrong model variant. The number alone cannot tell you which.

Use the asset record to confirm the exact model and variant, the installed firmware, the active profile and how many chains the miner should report. (A chain is how the firmware reports one group of hashing chips, often one hashboard.) Then record the uptime, the time you looked and the timezone. A screenshot with no timestamp may show an older state. An inventory name may also be out of date after a control board replacement. If identity records disagree, sort that out before you choose a model-specific procedure.

Keep what someone thinks separate from what was seen. ‘Board 2 is dead’ is a guess at the cause. ‘The current status page lists two of the three chains expected for this training model’ is an observation. Keeping them apart stops an untested guess from becoming the diagnosis.

• Weak report: ‘It is down about a third. Replace a board.’
• Useful report: ‘Training asset R4-17 reports 80 TH/s against its approved 120 TH/s baseline; two of three expected chains are listed. Change first observed after the 08:42 restart.’
• Before a reset or change, preserve the status, relevant logs and current configuration through approved read-only tools.

Follow the measurement from miner to pool

The local hashrate on the miner and the hashrate the pool estimates for that worker are two different observations. The local interface shows the miner’s own report of its work. The pool estimates the work from the shares it receives. Shares arrive at random times, so a short pool window can rise and fall even when the machine is steady. Compare the same time windows, and confirm you are looking at the right worker. A pool average is not a live meter on the machine.

Imagine a machine that looks steady locally, but its short pool estimate dips. First compare the longer and shorter windows, the time of the last share, any rejected work and any connection events. Do not jump to calling it a missing board. The reverse is also true: a healthy local total does not prove that useful work is reaching the right pool account. The miner must both do the work and deliver it.

When the two views disagree, record the disagreement in the ticket. It shows the next person where evidence is still missing. Before blaming hardware, check for renamed workers, duplicate worker names, out-of-date dashboards or the wrong account. Each pool sets its own rules for how it shows accepted, stale (sent after the work was already out of date) and rejected work.

• Read the worker identity and last update, not only the graph color.
• Do not compare raw share counts between workers without checking share difficulty. A share at a higher difficulty represents more work.
• A single low short-window estimate is a reason to inspect context, not a hardware verdict.

Quantify the loss without inventing a cause

Against a comparable baseline, output loss in percent is (expected − observed) ÷ expected × 100. In this fictional example, 120 TH/s expected and 80 TH/s observed gives a 33.3% shortfall. That fits losing one of three equal chains, but fitting is not proof. All three chains running lower could give the same total. Look at how the output is split across the chains.

Time also matters. A machine hashing at 120 TH/s for 45 minutes and doing no work for 15 minutes averages 90 TH/s over the hour (120 × 45 ÷ 60 = 90). So a current local reading of 120 and an hourly figure near 90 do not have to contradict each other. This is simple teaching arithmetic. Real pool estimates also vary by chance and depend on how the pool calculates them.

Always write down what you compared against (the denominator). ‘Thirty-three percent low’ against the nameplate maximum means something different from the same loss against the documented baseline for the active profile. Never treat a fictional figure from this lesson as a manufacturer tolerance or as a reason to increase power.

Read chain status as a pattern

A chain is a group of hashing chips that the control board detects and reports as one unit. How chains match physical boards depends on the design. A missing chain is not listed, or it fails enumeration. Enumeration is the step where the control board detects and lists each chain, usually during startup. A present but underperforming chain is listed but produces less than expected. In a whole-unit reduction, every chain drops. Each of these patterns leads to a different investigation, so do not treat them as the same thing. An absent entry, an entry showing zero output and an out-of-date entry may also mean different things.

Compare the number of chips detected, chain output, related sensor readings and startup events with the reference for the exact model. Do not assume every miner has three chains, the same chip count or the same numbering. A chain label on the screen may not match the physical board position you expect. Record the label exactly, and check the equipment documentation before you match it to a physical board.

Remember that the monitoring system itself may be incomplete. If one source shows a chain as absent but another current source shows all expected chains working, check when each one last updated and how each one defines its readings. Do not blend conflicting data into a confident answer. Record the conflict and get a current reading you can trace to its source.

• Absent: establish what failed to initialize or report.
• Present but weak: compare contribution and related events under the same conditions.
• All reduced: check the profile, operating state and shared limits, such as cooling or curtailment, before focusing on one board.

Reconstruct the first meaningful event

A log is a list of events recorded by software. A message that repeats many times stands out, but that does not make it the cause. Build a short timeline around the first moment behavior changed from normal to abnormal. Include startup, profile changes, environment changes and any maintenance just before. Ask whether a later message could be a result of an earlier event.

In the example timeline below, a pool reconnect happens after a chain is lost. Because it came later, the reconnect is a weak explanation for the chain problem. On its own, the order does not identify a failed board. It also does not prove the chain problem caused the reconnect. The order of events narrows what an explanation must account for. It does not replace a test.

Some logs reset their clock at boot, use a different timezone or have gaps. Note those limits before you line up events from different systems. Keep enough of the log around an error to show what came before it. Use the reference for the exact firmware when you read real error codes. The messages below are plain-language training records, not commands or real manufacturer output.

Build a hypothesis that can lose

A hypothesis is your best explanation so far, stated so that a check could prove it wrong. A useful one predicts something you would not see if another explanation were true. ‘Something is wrong with the miner’ cannot guide a check. ‘The lower total is explained by the newly approved reduced-power profile’ can. If it is true, the profile record should show that change, and the output of each chain should fit that profile. An unchanged profile and one absent chain would weaken it.

Use a small evidence table. For each possible explanation, write what supports it, what conflicts with it, the next authorized check and what result would change your mind. Start with the read-only evidence you already have and the fault procedure that applies. Choose checks that tell causes apart without clearing the fault, so it can still be examined. A reboot out of habit can erase useful evidence without answering the question.

Do not assume recent maintenance caused the fault. The timing makes it worth checking, but the last person to touch a machine is not automatically responsible. In the same way, replacing a part can restore service without showing exactly what was wrong. Your report should keep three things separate: the fault area the evidence supports, the approved action that restored service and a confirmed root cause.

• Configuration hypothesis: compare the approved change record and active profile.
• Reporting hypothesis: compare current sources and their update times.
• Chain-path hypothesis: use guidance for that model to tell apart a board, connection, power supply or control problem, within your authorized scope.
• If the required next check exceeds your authorization, specify the evidence and question for the responsible specialist.

Choose an action with a verification contract

A diagnosis should end in a clear, limited recommendation. State the fault area the evidence supports, the procedure or specialist needed, the effect on operation and the evidence that will show recovery. Agreeing on that evidence before anyone acts is your verification contract. BITMAIN’s guidance treats a missing board differently from other low-hashrate problems. It is a reference for compatible Antminer equipment, not a sequence for every manufacturer. Read the exact current procedure before you use it.

This digital lesson does not ask you to disconnect, probe or swap live equipment. Physical inspection, isolation, swapping a module and returning a unit to service follow approved site and manufacturer procedures, carried out by authorized people. Your task here is to decide what those actions would test and how you would read the result they report. Component-level soldering is outside this curriculum.

A good escalation is actionable: ‘Chain C is absent after startup; A and B remain near baseline. Evidence is attached. Please follow the compatible fault procedure to investigate the chain path, then report the observed result.’ That is stronger than ordering a board with no supporting record.

Verify the original failure, not just a successful boot

Decide how you will verify before you act. If the complaint was an absent chain, check after return to service that every expected chain is detected and producing output. If the problem appeared only after long periods under load, watching the startup screen is not enough. Include relevant alarms, whether sensor readings make sense, the active profile and useful work reaching the right worker. How long to watch comes from the failure pattern and your approved process. This lesson does not set one fixed time for every case.

A longer pool window can still include downtime from before the fix. Record when the fix was made. Do not mistake an average that is slow to catch up for a current failure. Watch the current readings while you wait for the comparison window to fill with data from after the fix. One accepted share does not prove normal performance.

If your observation period ends before the known failure condition has been tested, write ‘service restored; verification open’. Name who does the follow-up and what should trigger it. If output recovers but the cause is still unclear, say so. Being honest about what you do not know is part of a complete technical record. It is not a reason to hide the result.

Write the handoff another shift needs

A useful final note lets someone else follow and repeat your investigation. Start with the asset identity and the first symptom. Add the measurement source, the comparison window, the approved baseline and the output of each chain. Summarize the key evidence instead of pasting a wall of logs with no explanation. State the authorized action that was actually reported, its result and any open question.

Compare these conclusions: ‘Fixed after reboot’ and ‘Service restored at 10:20; three expected chains now enumerate and contribute near the approved profile baseline. The pool worker is receiving accepted work. The previous fault occurred after extended load, so recurrence verification remains assigned to the next shift.’ The second tells the reader what is established and what still needs attention.

Before you submit the note, check every claim about cause against its evidence. If a conclusion is not supported, rewrite it as a narrower observation. Add a reopening condition: the result that should make the next owner reopen the ticket. This builds real technical judgment, not just a list of parts to replace.

Worked example: symptom versus component claim

A fictional miner keeps reporting two active chains when its confirmed configuration expects three. The same chain is missing every time you check under comparable conditions.

This supports a persistent missing-chain symptom. Without more evidence, it does not tell you whether the problem is the hashboard, its connections, its power path, the control board or a compatibility issue. Your ticket should name the absent chain and give the timestamps, the profile and any relevant recent changes. The next authorized procedure decides how to tell the remaining explanations apart.