Latency math

A support ticket says “latency spiked from 30 ms to 500 ms.” Is that the database? The network? The CDN? Before you read a single log, you need the floor numbers — the latency physics forces on every route. Once you know them, anomalies become obvious.

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.

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

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.