Latency math

The latency formula

One-way propagation delay = distance / signal speed.

Light in vacuum: 300,000 km/s. Light in glass fibre: ~200,000 km/s (the glass slows it by ~33%). These numbers give you latency floors no software can beat.

Per-technology latency

Real RTT is always higher than the propagation floor because routing adds distance, each router adds a small processing delay (~1 µs for modern hardware), and queuing can add milliseconds under load.

Why real RTT exceeds the floor

Take NYC → London (theoretical floor: 55 ms RTT at 200,000 km/s). Real RTT is 70–90 ms — 30–60% above the floor. The excess comes from:

1. Routing overhead: cable routes are not straight lines; the actual cable path is longer than the great-circle distance.
2. Router processing: each intermediate router reads the IP header and looks up the routing table (~microseconds each, dozens of hops).
3. Serialisation delay: time to push a full packet (1500 bytes) onto the wire at the link rate. At 1 Gbps: 1500 × 8 / 10⁹ = 12 µs. Negligible for high-bandwidth links, significant at 10 Mbps.
4. Queueing delay: at any bottleneck link, packets wait behind others. Under load this can add tens of milliseconds — covered in lesson 04.

These four components stack: items 1–3 are roughly fixed for a given path, but item 4 is variable and under your control. A path that looks fine at low load can blow up to 10× its idle RTT under saturation — and that gap is almost always queueing, not physics.

The Internet’s submarine backbone

~500 submarine cables connect the continents. Key facts:

• Each cable carries 10–30 Tbps via DWDM (Dense Wavelength-Division Multiplexing): dozens of wavelengths on one fibre pair, each wavelength ~100–400 Gbps.
• EDFAs (erbium-doped fibre amplifiers) regenerate the optical signal every ~80 km without converting to electrical.
• Cable failures (anchor strikes, undersea landslides, ship anchors) happen monthly; redundancy and BGP rerouting keep traffic flowing.
• Hyperscalers (Google, Meta, Microsoft) own private cables — MAREA, Dunant, Curie — to guarantee capacity for their traffic.

Practical debugging at the link layer

Before reaching for packet captures or service logs, spend two minutes at the physical layer — one bad cable or a NIC auto-negotiating down to 100 Mbps can look like application slowness and waste hours of debugging time.

When a network path behaves unexpectedly, these tools locate the layer:

# Linux: interface counters — errors, drops, overruns
ip -s link show eth0

# NIC settings: speed, duplex, auto-neg
ethtool eth0

# Vendor NIC statistics: CRC errors, link restarts
ethtool -S eth0 | grep -E "rx_crc|rx_error|tx_error"

# Wi-Fi signal and rate
iw dev wlan0 link

# Traceroute with ICMP timestamps (shows per-hop RTT)
traceroute -I 8.8.8.8
mtr --report 8.8.8.8

Interpreting what you see:

• rx_crc_errors > 0: frames arriving garbled — bad cable, dirty SFP, or marginal signal. Replace cable or transceiver first.
• Link auto-negotiated to 100 Mbps when you expected 1 Gbps: cable or port issue forced fallback. Replace the cable (Cat5e damaged pair).
• Traceroute RTT jump at hop N: latency added at that router or the link between hop N-1 and N. Not necessarily the router’s fault — ICMP rate-limiting can make it look slow.
• Wi-Fi “connected at 54 Mbps”: client is using legacy 802.11g rates — very far from AP, or old device. Move AP or device closer.