Diagnostics Hub: Verify Network Quality Like an Engineer

# Verify network quality like an engineer: reproducible evidence over marketing copy Test nodes, test IPs, MTR reading — one workflow for both pre-purchase verification and post-incident diagnosis. The measurement muscle lives in the site's speed test tool: multi-carrier latency/loss matrices and copyable methods, free and open. ## Quick decision block - Pre-purchase node check → online speed test (Telecom/Unicom/Mobile direction latency & loss) - Locating slow/lossy → the MTR three-step method below - Bandwidth short of spec → iperf3 multi-stream or a big-file pull - Site slow but ping fine → `curl -w` phase split (TTFB points at the backend) ## Measuring correctly - Pick nodes in **your users' region**, and measure across time slots (at least one evening-peak 20:00–23:00 round and one off-peak). - Browser tests absorb your Wi-Fi and extensions; important conclusions get cross-checked with a server-side big-file download. - Single-stream not filling the pipe is normal (TCP window × RTT); bandwidth claims need multi-stream (`iperf3 -P 4`) or large files. - Record full conditions (time, source + carrier, tool, stream count). Unconditioned numbers are incomparable numbers. ## MTR reading: the three-step method 1. **Last hop first.** Only loss/latency at the final hop (the target) is a real problem. Loss on middle hops with a clean last hop = that router rate-limiting ICMP — ignore it. 2. **Both directions.** Your local MTR measures the outbound; log into the server and MTR back to your IP (or use the provider's Looking Glass) for the return. A detouring return path is the classic "ping fine, download slow" root cause (line background in the routing hub). 3. **Persistence.** At least 100 packets (`mtr -c 100 -r`). Sporadic 1–2% jitter is acceptable; sustained >5% loss or staircase latency is ticket-worthy. ## Toolbelt ```bash # reachability + per-hop quality mtr -c 100 -r traceroute -n # geo + AS annotated trace (line identification: AS4809=CN2, AS4837=Unicom) nexttrace # real bandwidth stress (both ends cooperating; -P = streams) iperf3 -c -P 4 -t 20 # HTTP phase split (DNS / connect / TTFB / total) — the "site slow" locator curl -o /dev/null -s -w 'dns:%{time_namelookup} conn:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://example.com # server side: connections, live traffic, per-process attribution ss -s && ss -antp | head -n 20 iftop -i eth0 # or nethogs per process ``` ## Five classic misreadings - **"The server loses packets":** eliminate local Wi-Fi and carrier last-mile first — retest from a phone hotspot; ten minutes kills half the false positives. - **"Latency too high":** physics sets the floor (~200,000 km/s in fibre); South-China → US-West at ~150 ms is normal and no vendor can renegotiate light speed (region hub). - **"Bandwidth insufficient":** check dedicated vs shared, FUP throttling, single-stream testing — in that order. - **"Site slow = network slow":** not necessarily; high TTFB is usually backend/database. Split phases with `curl -w`. - **"Ping works = service works":** ping is ICMP; your site is TCP 80/443. Firewalls can pass one and block the other — verify with curl. ## Filing a good ticket Attach three things and resolution accelerates: bidirectional MTR reports (local→server and server→local), exact timestamps plus affected IPs, and the eliminations you already ran (e.g. hotspot retest). A ticket that says only "it lags" earns only one reply: "please provide MTR". ## Eliminate your own last ten metres first A fair share of "server problems" live in the last ten metres: ① **change medium** — Wi-Fi → phone hotspot retest separates wireless from link; ② **go direct** — cable straight into the modem's dial port, excluding your router (ageing firmware, QoS policies, device-count overload are regular offenders); ③ **check occupancy** — pause video/downloads/cloud sync during tests; a saturated uplink distorts every downlink number. Only after these three stay abnormal does the server-and-link investigation begin. ## Unit traps: Mbps vs MB/s and the "multiplier lie" Bandwidth is little-b (bits); files are big-B (bytes); 1 MB/s = 8 Mbps. A 100 Mbps line tops out at 12.5 MB/s — complaints of "100M line gives 11MB/s" describe a saturated line. Add protocol overhead (TCP/IP headers ~5–10%) and single-stream limits: reaching eight-to-nine tenths of the label is a pass. The marketing trick to watch is "port speed" sold as "usable bandwidth" — a 1G port is not a 1G dedicated pipe.