RTT — latency, what the numbers mean, and why 'no reply' isn't 'down'

Round-trip time decides how snappy everything feels, far more than bandwidth does for small files, SSH and web pages.

What it is. The time for a packet to reach the target and the reply to come back. n check measures it with ICMP ping and, for shares, with TCP connects to the service port (what SMB actually pays per request).

What the numbers mean

| RTT | Where you are |

|---|---|

| < 1 ms | same LAN, wired |

| 2–10 ms | Wi-Fi on the same LAN |

| 5–30 ms | your ISP, nearby servers |

| 40–100 ms | the same continent |

| 100–300 ms | intercontinental, or a VPN/relay detour |

| wildly varying | *jitter*: Wi-Fi interference, a saturated link, bufferbloat |

Why it matters more than bandwidth. Copying one big file is bandwidth-bound. Almost everything else — opening a folder of small files, SSH keystrokes, a web page's dozens of requests — is a chain of round trips. 64 small files at 5 round trips each over a 40 ms link is 13 seconds *before any data moves*. n bench shows this directly in its small-file phase.

"No ICMP echo reply" does not mean down

Windows blocks ping by default on public/private profiles; many servers drop it; some ISPs rate-limit it. When ping fails, netscrew tries the service ports — a host answering on 445 or 22 is very much up. Only trust "down" when nothing answers.