Whatsminer – NTP Time Sync Failed

Reboot the miner from WhatsMinerTool or the web UI for a clean restart of the time-sync service. A surprising number of WM_NTP_FAIL cases (15-20% of the D-Central queue) clear on reboot because the underlying cause was a transient DNS hiccup, a momentary upstream NTP host outage, or a router that had quietly dropped the miner's UDP state. Wait two minutes after boot, then recheck the System Time page. If the clock now matches reality, log the event and monitor for recurrence before assuming root cause.

Set an explicit NTP server in WhatsMinerTool. Open System / Network settings → NTP server. Replace whatever is there (often the BTMiner default, sometimes empty, occasionally a deprecated MicroBT host) with time.cloudflare.com. Cloudflare's anycast NTP is reachable from almost every jurisdiction, low latency, well-maintained. Save, reboot, recheck the clock. This is the single highest-leverage fix on the page — it resolves easily half of WM_NTP_FAIL cases and costs nothing.

Try alternate NTP hosts if Cloudflare doesn't work. Cycle through time.nist.gov, time.google.com, time.windows.com, then pool.ntp.org. Each has its own jurisdictional reachability profile and DNS resolution behaviour. Some corporate egress firewalls allow specific NIST or Microsoft hosts but block generic NTP pools, so cycling exposes which upstream your network actually permits. Save, reboot, recheck after each attempt — don't try to evaluate all four at once.

Verify the miner has working internet otherwise. Open the miner's pool status page or web UI dashboard. Pool connections healthy? Hashrate normal? If yes, your IP egress works for TCP — the issue is specifically UDP 123 egress. If no — if the miner has zero pool connectivity — then WM_NTP_FAIL is downstream of a broader network outage and you should fix that first per the Whatsminer Error 2020 (Stratum Connect Fail) playbook.

Check time on a workstation on the same LAN. Phone, laptop, or any other LAN device. Is its clock right? Are other smart devices on the LAN keeping correct time? If the rest of the LAN is fine but only the miner drifts, the fault is miner-side or miner-egress-specific. If the whole LAN is drifting, you have a router or ISP-level NTP block — go straight to Tier 2 router fixes.

Configure your router as an NTP relay. The cleanest, most permanent fix for any environment where outbound UDP 123 is blocked. On most modern consumer routers — Asus (WAN → NTP server), OpenWrt (/etc/config/system), pfSense (Services → NTP), OPNsense, UniFi (network settings → NTP server) — enabling NTP-server mode is one or two clicks. Once enabled, configure the miner to use the router's LAN IP as its NTP server. The router does the egress; the miner queries a local IP that's never filtered.

Stand up a Raspberry Pi as a LAN NTP source. If your router can't relay NTP, a Raspberry Pi 3 or newer running chrony with pool.ntp.org as upstream is a $40 set-and-forget LAN time source. Install Raspberry Pi OS Lite, apt install chrony, edit /etc/chrony/chrony.conf to add allow 192.168.1.0/24 (your LAN), enable the service, point your miners at the Pi's LAN IP. Standard fix for industrial mining containers, air-gapped operations, and any home setup where ISP filtering is permanent.

Check your router's UDP 123 egress rules. Log into the router admin interface. Look for any anti-DDoS toggle, NTP server enabled option (which in some routers means block clients from talking to outside NTP), or firewall rule blocking outbound UDP 123. Disable any such restriction for the miner's IP. Save, reboot router, retest. Document what you changed — these toggles are often re-enabled silently by router firmware updates.

Disable IPv6 on the miner's network interface as a test. If your LAN is dual-stacked and the miner's NTP client is preferring AAAA records on a broken IPv6 path, disabling IPv6 forces the miner back to IPv4 where NTP works. WhatsMinerTool's Network Settings has an IPv6 toggle on most builds; disable, save, reboot. If the clock now syncs you've found the dual-stack issue. Either keep IPv6 disabled on the miner or fix the upstream IPv6 routing.

Test outbound UDP 123 from a Linux/macOS workstation. Run nc -uvz time.cloudflare.com 123 and ntpdate -q time.cloudflare.com. If both succeed from the workstation but the miner still can't sync, you have a miner-specific block (rare — usually a misconfigured NTP host, a wedged ntpd, or the IPv6 issue). If the workstation also fails, you have a LAN/WAN-wide UDP 123 block — escalate to router relay or ISP. Decisive evidence either way in 30 seconds.

SSH into the miner and inspect the time-sync daemon. Most BTMiner builds expose SSH (default credentials documented for older builds; newer builds require explicit enablement via WhatsMinerTool). Once in, run chronyc tracking or ntpq -p depending on which daemon ships. Read the output — daemon running? Server configured? Last reported offset? This is the ground-truth view of the time-sync state and tells you immediately whether the daemon is wedged, missing, or unable to reach a server.

Force an immediate sync via shell. With SSH access: chronyc makestep (chrony) or ntpdate -u time.cloudflare.com (ntpd). This bypasses the daemon's step-refusal logic and pulls the clock to real time in a single shot. Useful when the RTC has drifted far enough that the daemon refuses to step on principle. After stepping, restart the daemon (systemctl restart chrony / systemctl restart ntp) so it resumes normal slew operation from a sane baseline.

Capture packets on the miner's switch port. Mirror the miner's port on a managed switch and run tcpdump -i eth0 -w /tmp/ntp.pcap udp port 123 on a workstation, or run tcpdump directly on a Linux router. Open in Wireshark. Three patterns: (a) NTP request egresses but no response returns (upstream is blocking the response), (b) no NTP request egresses at all (miner-side daemon is dead or misconfigured), (c) request and response both visible but the daemon ignores the response (clock skew exceeds panic threshold).

Edit the miner's chrony.conf directly (advanced). If WhatsMinerTool's NTP-server field doesn't expose enough configuration — for example, if you need to force iburst, force IPv4-only via -4 in the daemon flags, or add multiple servers with explicit weights — SSH in and edit /etc/chrony/chrony.conf (path may vary by BTMiner build). Restart the daemon. Caveat: edits to the BTMiner image survive reboots but not firmware updates. Document anything you change for re-application after a future flash.

Roll back BTMiner firmware if NTP broke after a recent update. Burn the prior stable image with Raspberry Pi Imager, insert the SD card into the control-board slot, hold the reset button through your model's recovery sequence (M30S family: 10s through boot; M50/M60: model-specific). Some BTMiner builds have shipped broken time-sync configs (deprecated NTP hosts, broken systemd dependencies, restrictive chrony.conf rules); rollback is a valid and routine fix.

Stop DIY: cycled four NTP hosts, configured a router relay, disabled IPv6, packet-captured the egress, manually stepped the clock, and rolled back the firmware — and the miner still can't sync. That is a compound fault: a damaged control-board RTC, a corrupted persistent config that SD recovery didn't clear, or a hardware-level NIC fault on UDP that doesn't show on TCP. Time to bench it — book a D-Central remote diagnostic before shipping.

D-Central bench process: live diagnostic on a known-good network with tcpdump on the upstream switch, RTC battery test, control-board NIC-level test (some MicroBT control boards have UDP-specific NIC quirks that only surface under load), full firmware re-flash from a clean MicroBT release, post-repair 24-hour soak with NTP audit. If the RTC battery is the issue and your control board has one we replace it; if your board doesn't have one we document that and move on — fix is just reliable NTP.

Open a remote-diagnostic session before shipping. D-Central offers remote screen-share diagnostics that catch a meaningful fraction of WM_NTP_FAIL cases without ever shipping the miner. Often it's a router setting we can fix in five minutes that the operator missed. Cheaper than freight, faster than turnaround, and worth a try before boxing the miner. Book at d-central.tech/services/asic-repair/.