Avalon 1266 – Low Hashrate vs Nameplate
Warning — Should be addressed soon
Symptoms
- `GHSmm` vs `GHSavg` divergence greater than 8% sustained for 30+ minutes on the CGMiner API (port 4028)
- Pool-reported hashrate 10-30% below nameplate (~90-100 TH/s) despite miner UI reporting close-to-nameplate
- One `MW0`/`MW1`/`MW2` array shows fewer than 26 entries or entries below `3000`
- `ECHU[x x x]` reads all zero (no comm fault) but realized hashrate is still low
- `PVT_T` (per-chip temperature) shows one or more chips at or above 95 C
- `PVT_V` (per-chip voltage) shows scatter greater than +/-30 mV across a board
- AUC3 LED solid green (no comm errors) but realized TH/s is flat and low
- Chassis inlet air at the front mesh reads above 30 C under load
- Controller log shows intermittent `mm_work_send_timeout`, `asic_freq_set_fail`, or `CODE_MMCRCFAILED` on one MM slot
- Hashrate degrades gradually over weeks (aging, paste, caps) rather than dropping suddenly (OC, PSU, fresh chip failure)
- PSU fan duty above 80% at steady state despite normal ambient
- Miner has been running 12+ months since last thermal paste refresh
Step-by-Step Fix
Hard power-cycle at the PDU for 5 minutes. Not a soft reboot - full power-off long enough that the hashboard capacitors discharge and the AUC3/MM re-initialize cleanly. Clears wedged driver or comm state that survives a warm reboot and is often enough on its own to restore nameplate after a firmware update, a stratum glitch, or a transient brownout. Record the API `stats` baseline before and after so you know whether this step alone fixed it.
Shop-vac the intake mesh, front grille, and fan blades. Dust build-up on the 1266 intake is the single most common mystery low-hashrate cause - the A3206 runs closer to its thermal ceiling than the 1166's A3205, so the same 30 days of dust costs you more hashrate on a 1266. Use a soft-bristle brush for stubborn build-up. Do not use canned air near the hashboards (pushes dust into chip sockets). Monthly task.
Confirm ambient at the miner intake is at or below 30 C using an IR thermometer aimed at the front mesh (not room-middle, not the hallway). A Canadian garage in July can easily hit 33-35 C at the intake. Above 30 C the 1266 firmware caps chip frequency to preserve thermal stability - you lose hashrate and see no named fault. If you cannot keep the room under 30 C, relocate the miner or add forced extract ventilation before touching anything else.
Verify firmware matches hardware revision. Read the sticker on the MM control board, cross-reference Canaan's firmware portal at avalonminer.org/firmware-document, and confirm you are not running a foreign firmware (e.g. 1246 firmware on a 1266 board, or a mismatched A1266 hardware revision). Mismatched firmware advertises hashrate the chassis cannot deliver. Roll to the stock firmware matching your hardware revision and re-baseline.
Pull API `stats` and record a baseline. From the controller or any LAN host: `echo -n '{"command":"stats"}' | nc <miner-ip> 4028`. Save the output. Record `GHSmm` (theoretical), `GHSavg` (actual), `MW0`/`MW1`/`MW2` (per-board work counts, should have 26 entries each >= `3000`), `PVT_T`/`PVT_V` (per-chip temps and voltages), `ECHU` (should be all zero), and `ECMM`. Compare against this baseline after every subsequent fix step.
Measure AC input voltage at the PSU under full load. Multimeter on AC, probe at the PSU input while the miner is hashing at steady-state. Canaan spec: 180-264 V. Real-world nameplate hashrate requires >= 220 V sustained. Anything below 220 V drops hashrate silently because the PSU works harder, voltage droops, and the A3206 chips down-clock to stay stable. If AC is low, you have a circuit problem - call an electrician before blaming the miner.
Measure DC rail at the PSU-to-hashboard connector under full load. Probe all three hashboard connectors in turn with the miner hashing. Rail voltages should match each other within a few mV. One rail materially below the others points at a tired PSU, a damaged cable, or a fault on that specific board. If all three rails sag together under load, the PSU is tired; swap with a known-good unit - the 1266 shares PSU hardware with the 1056/1066/1066 Pro/1126 Pro/1146 Pro/1166 Pro/1246 per Canaan's own listing.
Swap hashboards between MM slots to isolate the fault. Label the three slots 0/1/2 with tape first. Power off at the PDU, move the suspect board to a known-good slot, power back up, re-pull API `stats` after 15 minutes. If the thin `MW` array follows the board, the board is at fault (go to Tier 3). If the fault stays in the slot, the MM/AUC3/cable path is at fault. Cleanest hardware-vs-control-path isolation available without a bench.
Clean or replace any aftermarket intake filter. Some commercial 1266 deployments run a filter in front of the intake. A clogged filter adds 3-5 C to inlet temp even when the room is cold. If you have one, clean or replace it on the same 30-day cadence as the dust vacuum. No filter at all is fine for most home setups - focus on 15 cm intake clearance and room air quality instead.
Reseat every cable in the chassis. Power off at the PDU. Pull each hashboard data cable and power cable in turn, visually inspect pins for oxidation or blackening, reconnect firmly with a click. Reseat the AUC3 USB cable at both ends. A poorly-seated connector adds resistance, drops voltage, and caps hashrate without tripping a named fault. Zip-tie any loose USB to the chassis frame so fan vibration cannot walk it loose again.
Run cgminer with conservative AUC3 bus settings. Add `--avalon7-aucspeed 200000 --avalon7-aucxdelay 24000` to the cgminer launch command. The 1266 uses the same `avalon7` flag family in cgminer as the 1166/1246 - documented in the cgminer `ASIC-README`, absent from Canaan's materials. Conservative values double IIC bus headroom and eliminate intermittent `CODE_MMCRCFAILED` retries that silently reduce effective hashrate on marginal bridges.
Override the default DNS in miner network config. Stock Canaan firmware defaults to `114.114.114.114`, a Chinese public DNS that resolves unreliably outside China. Set DNS to `1.1.1.1` or `8.8.8.8` to eliminate stratum-side flapping that looks like hashrate loss on the pool dashboard. Documented nowhere in the English manual. Applies to every AUC3-based Avalon, 1266 included.
Refresh thermal paste on all three hashboards. Use Arctic MX-6 or Thermal Grizzly Kryonaut. Remove heatsinks, clean old paste with 99% IPA and lint-free wipes, apply a uniform thin layer (do not glop it on), reassemble with correct heatsink torque. 12+ month paste on an A3206 accounts for 2-5 C of junction-temp headroom; expect hashrate recovery of 3-8% on a miner that had drifted thermally. Plan the paste refresh cycle every 12-18 months for the 1266 - tighter than the 1166 because the A3206 runs hotter.
Reflow the worst chip identified by `PVT_T`/`PVT_V` outliers. Remove heatsink, flux the BGA, preheat the bottom of the board to 150 C, top-side hot air at 310-330 C for 30 seconds, let it cool naturally, re-apply paste, reassemble. A3206 BGA packages tolerate a single reflow cycle well. If HW% or `PVT` numbers return to median after 20 minutes of run-time, the reflow took; if the chip drifts again within 30 days, the silicon is failing and must be replaced, not reflowed twice.
Roll firmware one version back or forward from the Canaan firmware portal at avalonminer.org/firmware-document. Cross-reference the BitcoinTalk A1266 thread for community A/B reports - Canaan publishes no changelog, so tribal knowledge is your changelog. The 1266 has less published community data than the 1246; expect to run your own small-batch A/B: flash, burn in 2 hours, pull `stats`, compare. A conservative chip-frequency table costs real hashrate without any named fault.
Inspect and replace voltage-domain capacitors. Bulging electrolytics or cracked MLCCs near the PMIC on any hashboard = replacement job. Soldering iron + hot-air rework + correct-value caps, working from the board schematic. Continuous 85 C operation drifts stock electrolytics in 2-3 years. Not a reflow job. If you are not comfortable with fine-pitch SMD rework, stop here and ship the board - a botched cap replacement can damage adjacent components and increase the final repair bill.
Swap the AUC3 with a known-good unit. If every other layer has been cleared and conservative bus tuning did not help, the AUC3 itself may be dying. FTDI bridges age poorly in the Avalon's fan-vibration, ESD-exposed environment - D-Central's repair-queue data shows a seasonal spike in AUC3 replacements every Canadian winter from dry-air static discharge. A fresh AUC3 is cheap insurance. If a known-good AUC3 also caps hashrate, pivot back to Step 8's board-vs-slot isolation.
Stop DIY when `PVT_T`/`PVT_V` isolates three or more failing chips on the same board, a reflow on a suspect chip returned within 30 days, a PMIC/voltage-domain IC is suspected, you see visible capacitor bulging or burnt-component damage you are not equipped to rework, or a known-good AUC3 swap and conservative bus tuning still leave `GHSmm`-vs-`GHSavg` divergence above 15%. You are now in test-fixture territory. Book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/ and include your `stats` dump plus observed symptoms in the shipment note.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
