Why your Train at Home speed test is low (and how to measure your real bandwidth)

If Train at Home's speed test just reported something like 15 Mbps on a connection you know is much faster, you're not wrong to be suspicious — and you're not the only one seeing it. This guide walks through why that happens, using real measurements taken on the same Mac and the same line, and how to check your actual bandwidth separately. See the optimal setup guide for where this fits into the bigger picture.

How Train at Home actually measures your bandwidth

The miner embeds Python's speedtest-cli library directly. It runs a fresh test right before each registration attempt (logged as Running speedtest..., then Speedtest completed with results: {'download_mbps': …, 'upload_mbps': …}), and reuses a cached result the rest of the time (Using cached speedtest result) — roughly 3-4 tests a day in normal operation. Critically, it auto-selects an Ookla test server by latency, with no user control over which one it picks.

There's no local pass/fail threshold

Searching a full day's worth of CLI logs for anything resembling a bandwidth minimum — "insufficient," "too slow," "minimum … mbps," "threshold," "bandwidth" — turns up nothing. On this build, the speed test looks like telemetry that gets reported upstream, not a local gate that blocks you from mining.

The actual numbers

On one Mac, one gigabit fiber line, one afternoon:

Source	Download	Upload
macOS networkQuality (default, multi-stream)	~995 Mbps	~715 Mbps
speedtest-cli, nearby server (536 km)	266 Mbps	289 Mbps
speedtest-cli, distant server (501 km, oddly)	15.5 Mbps	28.7 Mbps
Train at Home's own log, 16:02	371 Mbps	301 Mbps
Train at Home's own log, 17:36	13.8 Mbps	30.0 Mbps

Same Mac. Same line. Same afternoon. The difference between a "15 Mbps" reading and a "370 Mbps" reading was entirely which Ookla server got auto-selected — not the actual connection.

There's a real consequence to this, beyond a scary-looking number: on the same day this data was gathered, the orchestrator's /miner/register/status endpoint returned 500 three times in a row. The miner then re-registered with a brand new queue id — starting over at the back of the queue. Whether that specific failure was caused by the slow reading is not established, but it's a reminder that a bad speed test reading isn't purely cosmetic; if you also end up re-queued, the queue position guide shows how to confirm what actually happened.

Why bandwidth matters mechanically, even if there's no strict minimum

Training across the Internet instead of a datacenter interconnect isn't free. The project's own technical primer describes needing roughly 100-300× compression on activation/gradient transfers to keep transfer times comparable to what a datacenter would offer, and reports achieving around 128× compression in its own experiments — explicitly designed around "typical" home-internet bandwidth in the 50-200 Mbps range. In other words: the system is built to tolerate an ordinary home connection, not to require an exotic one. That context is useful when a single low reading spikes your anxiety — the architecture already assumes home-grade bandwidth, not datacenter bandwidth.

Measure your real bandwidth with networkQuality

macOS ships its own bandwidth and responsiveness tool, independent of anything Train at Home does. From man networkQuality on this Mac:

• Plain networkQuality runs upload and download in parallel (this is the "multi-stream" figure used in the table above) and prints a capacity + responsiveness summary.
• networkQuality -s runs the tests sequentially instead, which is what you need if you want separate uplink and downlink responsiveness (RPM) scores, not just a combined one.
• networkQuality -v adds verbose output.
• networkQuality -c produces machine-readable JSON instead of a human summary.

networkQuality

or, for a fuller sequential breakdown:

networkQuality -s -v

If networkQuality reports something close to your ISP's advertised speed while Train at Home's own reading looks nothing like it, you've confirmed the problem is which test server got picked, not your actual line.

What to rule out before blaming your connection

1. Compare with networkQuality first, as above, before assuming your line is at fault.
2. Report genuinely wild outliers to Macrocosmos — a result 20× off from reality on a stable line is useful signal for them, not just you.
3. Rule out local causes separately: a VPN active at the time (a general precaution worth taking while training, though not something Macrocosmos has published guidance about), a busy uplink from something else on your network, and, less certain, a Wi-Fi connection versus a wired one.

Checklist

1. If a reading looks alarmingly low, don't panic immediately — check networkQuality (or networkQuality -s -v) first.
2. Remember the speed test appears to be telemetry, not a pass/fail gate, on this build.
3. If you were also re-registered around the same time, check the queue position guide to confirm what happened.
4. Rule out a VPN and a busy uplink before assuming anything is broken.
5. If your networkQuality result also looks genuinely bad, that's a real signal worth investigating — this guide is specifically about the gap between the two tools, not about diagnosing an actually slow line.
6. If ports or P2P reachability are also a concern, see the network and ports guide.

For the rest of a stable setup — install, keep-awake, monitoring — see the full optimal setup guide.