The operator begins with a number in mind. The target TH/s goes into the plan. The profile is selected. Only later does the real constraint appear: wall power rises farther than expected, a PDU margin disappears, the PSU behaves differently from its neighbor, or the cooling system cannot hold the new load through the full observation window.
The mistake happened before the setting changed. The desired output was treated as the starting boundary.
A hashrate target is a request for an outcome. A watt budget is a physical operating constraint. The request can be useful, but it has to live inside the site's approved electrical and cooling envelope. That is why the watt cap comes first.
This does not mean that a configured firmware power limit predicts an exact hashrate or measured wall power. It does not. Treat it as a control setting. Run autotune as a separate recorded stage, then evaluate the result against the site-approved wall-power ceiling, cooling, accepted work and stability.
The number at the wall has a specific meaning
The official BITMAIN specification for the exact base Antminer S21 lists 200 TH/s and 3,500 W power on wall at 25 degrees C. Those figures belong to that named model and those stated conditions. They are not a generic specification for every machine whose label begins with S21.
That distinction is useful in a mixed fleet. S21-class is an operating shorthand, not a measurement standard. Different models, control boards, PSUs, individual chips, cooling arrangements and machine histories can produce different results under what looks like the same request.
The wall reading is also not interchangeable with a number shown by firmware. If an interface labels a value as watts, record it with that exact label and source. Unless the source explicitly defines it as wall power, do not rename it. The site power meter and the firmware interface can both be useful, but they answer different questions and can have different measurement boundaries.
Five signals, five different jobs
An operator needs a chain of evidence, not one heroic number.
1. Requested hashrate
This is the operating target sent to the control system. It expresses intent. It is not proof of delivered hashrate, pool credit, power draw or stability.
The VNISH platform page separates the requested and observed operating point in its interface description. That is the right mental model: request first, then observe what the machine actually does.
2. Firmware-reported power
This is the power value reported by the current firmware build, with the label and measurement basis available in that build. It helps compare behavior within a consistent setup. It should not be silently promoted to measured wall power.
Record the build, label, units, active profile and time window. Demo values on the VNISH platform page are interface examples only. They are not test results and they promise no outcome for another machine.
3. Measured wall power
This is a reading taken at the defined site measurement boundary with an appropriate instrument and procedure. Name the boundary. A single-machine outlet, a PDU branch and a container feed are not the same measurement.
The responsible electrical specialist for the site must approve the ceiling, measurement method, protective-device margin, wiring context and operating procedure. Firmware cannot certify the electrical capacity of a circuit.
4. Accepted pool work
This is the work recognized by the selected pool over the chosen observation window. It is an outcome to observe separately from a requested or device-side hashrate. Keep the pool, endpoint, network path and window consistent when comparing a canary with its untouched peer.
Do not use one short pool snapshot to overrule every other signal. Accepted work belongs beside uptime, rejected or stale work, resets and the length of the observation window.
5. Stability
Stability is not the absence of one red warning at one moment. It is the machine holding an approved operating point through the chosen window without unacceptable errors, repeated resets, missing boards, power anomalies, thermal anomalies or deterioration in accepted work.
Define the stop conditions before the test. If the rules are invented after the graph moves, the test is no longer controlled.
What a configured power limit can and cannot do
The official VNISH 1.3.5 release page lists an optional power limit and, separately, autotune fixes across chip architectures. It also keeps installation, autotune and final stabilization as separate stages. The VNISH platform page describes autotuning as an observable loop: baseline, tune, observe, then accept or revert.
Treat the configured power limit as a firmware control setting. Do not call it the site ceiling or proof of wall power. Record it, run autotune as a separate stage, and then compare the result with measured wall power and the rest of the Power Envelope Card. The setting cannot promise an exact TH/s, J/TH, watt reading, fan response or temperature.
Neither the setting nor autotune can repair a weak PSU, damaged hashboard, blocked airflow path, unstable circuit, poor power quality or unsuitable site ceiling. A control setting does not remove a physical constraint.
Why two similar machines can land differently
Before comparing outcomes, record the sources of variation that can move them.
Exact model and control board. VNISH currently maps supported builds across AML, XIL, CV and BB control-board families. The board is part of the route and operating context. Do not infer it from a broad family label.
PSU and electrical input. PSU condition, input quality, connection integrity, protective devices, wiring and the site's approved loading plan affect what can be attempted safely. These are electrical questions for qualified personnel, not tuning guesses.
Silicon variation. Individual chips and boards do not all reach the same operating point at the same voltage and frequency relationship. Autotune observes the machine in front of it. It does not erase unit variation.
Ambient conditions and airflow. Inlet conditions, dust, recirculation, altitude, fan state and cooling capacity can change the thermal result of the same request. The base S21 specification itself ties its reference power and efficiency figures to 25 degrees C and lists environmental conditions for that exact model.
Build and profile state. Record the exact firmware build and active profile. VNISH 1.3.5 notes that presets were reworked for several model families, including S21, and that autotune and stabilization follow installation separately. An old baseline cannot be treated as a new-build result without a new observation.
Hardware condition. Hashboard health, sensors, fans, connectors and prior errors affect whether a unit is a clean canary. A machine already showing unexplained instability should be diagnosed before it is used to judge a new power envelope.
Build the Power Envelope Card first
Complete one card for the canary and one for the untouched peer. Keep the two observation windows aligned.
| Field | Record before the change | Why it matters |
|---|---|---|
| Exact identity | Model, control board, PSU context, current build, active profile | Keeps unlike machines from becoming a false comparison |
| Baseline at wall | Instrument, measurement boundary, start and end, observed range | Establishes real site demand before a new request |
| Firmware signal | Exact watts label, requested and observed hashrate, temperatures, fans, board state, errors | Preserves what the interface actually reported |
| Site-approved ceiling | Approved limit, who approved it, and what electrical boundary it applies to | Turns the cap into an accountable site constraint |
| Configured firmware limit | Exact interface label, configured value, build, time and operator | Records a control setting without relabeling it as wall power or the site ceiling |
| Cooling state | Inlet context, airflow condition, fan state, ambient event, altitude if relevant | Shows whether cooling changed with the load |
| Untouched peer | Asset ID, location, why it is comparable, same pool and window | Separates a profile effect from a shared site event |
| Pool outcome | Accepted work, rejects or stale work, pool, endpoint and observation window | Keeps requested output separate from recognized work |
| Stop rules | Electrical, thermal, error, reset, missing-board, uptime and accepted-work conditions | Makes STOP possible before the test begins |
Do not put a universal watt number on this card. The ceiling belongs to the exact site, circuit, machine, PSU, cooling arrangement and responsible specialist.
The seven-step watt-budget canary
1. Record the exact route
Confirm the exact model, control board, current firmware build and supported route. First, choose the correct VNISH firmware route. If identity is unresolved, do not begin a power test.
2. Measure the baseline at the wall
Use the approved instrument and name its boundary. Run the canary and untouched peer through a representative matched window. Preserve requested and observed hashrate, firmware power label, wall reading, pool outcome, temperatures, fans, errors, resets and uptime.
3. Set the approved ceiling
The responsible site specialist sets the electrical ceiling with the circuit, PDU, PSU, wiring, protective devices, cooling capacity and operating policy in view. The technician records that limit and its owner. Do not reverse-engineer a site ceiling from a desired TH/s.
4. Configure the control, then run autotune
Configure only a supported, site-approved firmware limit. Record the exact label and value without calling either one measured wall power. Run autotune as a separate stage. Then verify the result against measured wall power, cooling, accepted work and stability. Installation, tuning and stabilization remain separate events in the record.
5. Observe the whole chain
Watch measured wall power, the firmware-reported power signal, requested and observed hashrate, accepted pool work, rejects or stale work, inlet and device temperatures, fan response, board state, errors, resets and uptime. Preserve time-series evidence when available.
6. Compare with the untouched peer
Keep the peer on its original build and profile during the comparison. Use the same pool and matched window. If both machines move during a site or network event, do not assign the whole change to the canary profile.
7. Decide GO, HOLD or STOP
The canary stayed inside the approved electrical and cooling envelope and met the site's prewritten stability and accepted-work criteria. It authorizes only the next controlled stage, not the whole fleet.
The evidence is incomplete, the window is not representative, the machine is still stabilizing, the peer is not comparable, or the signals do not yet support a decision. Keep the fleet unchanged while the gap is resolved.
A prewritten limit or fault condition was reached. Contain the canary, preserve the evidence, and follow the qualified support or recovery procedure. No universal threshold is implied.
STOP examples include electrical or thermal anomalies, repeated resets, persistent errors, missing hardware, deteriorating accepted work, or stability falling outside site criteria.
Save this before the next profile change
- Exact model, board, build, PSU context and active profile recorded
- Canary and untouched peer named
- Wall measurement boundary and instrument recorded
- Baseline window completed for both machines
- Site-approved watt ceiling and responsible specialist recorded
- Configured firmware limit, exact label, build, time and operator recorded separately
- Cooling state and relevant ambient conditions recorded
- Requested hashrate, firmware power label, wall power and accepted work kept separate
- Errors, resets, boards, temperatures, fans, rejects and uptime observed together
- GO, HOLD and STOP rules written before configuration and autotune
- One canary accepted before any wider stage is considered
A configured power limit is a control setting, not a prophecy and not proof of wall power. Start with the wall-power ceiling the site can responsibly support. Record the firmware setting separately. Then decide from measured wall power, the pool, the thermals and the stability record together.
Start with the exact route
Set the envelope before the target
Identify the machine, choose the verified build, test one canary and keep one untouched peer beside it.
Before copying a power target or install route, compare six source-linked operator reports and preserve the machine context. Open the independent field reports.