Part 3 — Layer 1: Physical
Job
Turn a stream of 1s and 0s into something that can travel through a medium (radio waves, voltage on copper, pulses of light), and turn it back into bits at the other end with as few errors as possible.
In our story
Your click crosses three completely different physical media before it even leaves the neighbourhood, and several more after that:
| Hop | Medium | Standard | What's physically happening |
|---|---|---|---|
| Laptop → router | Radio, 5 GHz band | Wi-Fi 6 (802.11ax) | Bits are encoded as changes in the amplitude and phase of a radio wave (1024-QAM: each symbol carries 10 bits), spread over many sub-carriers (OFDM/OFDMA) |
| Router → ONT | Copper, Cat6 cable | 1000BASE-T | Four twisted pairs at once, each carrying 5-level voltage symbols (PAM-5) at 125 Mbaud, in both directions simultaneously |
| ONT → ISP | Single-mode fibre | GPON | Pulses of laser light: 1490 nm downstream (2.488 Gb/s shared), 1310 nm upstream (1.244 Gb/s shared) |
| ISP core / Internet | Fibre | 100G/400G Ethernet over DWDM | Many wavelengths ("colours") on one fibre, each carrying 100–400 Gb/s using PAM4 or coherent optics |
| Inside the cloud data centre | Fibre + copper DACs | 25G/100G Ethernet | Short-reach optics or direct-attach copper |
How it works
1. Bits become symbols. Physical media can't carry "a 1". They carry a symbol: a voltage level, a light intensity, or a radio wave with a particular amplitude and phase. The more distinct symbols a link can reliably tell apart, the more bits each symbol carries:
2 levels (NRZ) → 1 bit / symbol
4 levels (PAM4) → 2 bits / symbol
1024-QAM (Wi-Fi 6) → 10 bits / symbol ← needs a very clean signal (high SNR)
That's why your Wi-Fi speed drops as you walk away from the router. The signal-to-noise ratio (SNR) falls, so the radios automatically fall back to simpler modulations (a lower MCS index) that carry fewer bits per symbol but survive noise better.
2. Clocking and line coding. The receiver has to know when to sample. Line codes (8b/10b, 64b/66b) and scrambling make sure the signal changes often enough for the receiver to recover the sender's clock from the data itself.
3. Error correction. Modern links add Forward Error Correction (FEC): redundant bits that let the receiver fix small errors without retransmitting. This adds a little latency and costs nothing at higher layers. Anything FEC can't fix becomes a bad frame at L2.
4. The three delays L1 controls. Most latency discussions mix these up:
| Delay | Formula | Our numbers |
|---|---|---|
| Propagation (speed of light in the medium) | distance ÷ (~200,000 km/s in fibre) | ≈ 5 µs per km. A region 1,500 km away costs ≥ 7.5 ms one way, ≥ 15 ms round trip, before any equipment |
| Serialisation (time to put the bits on the wire) | frame size ÷ link rate | 1,500 B at 1 Gb/s = 12 µs. At 10 Mb/s upstream = 1.2 ms |
| Duplex / medium access | Wi-Fi is half-duplex and shared: devices take turns | Under contention it adds anywhere from 1 ms to 50 ms or more |
Propagation delay can't be engineered away. You can buy more bandwidth. You can't buy a faster speed of light. That's the physical reason CDNs, edge regions, and "deploy close to users" exist.
5. Wi-Fi is the weakest link in most user journeys. It's shared, half-duplex, subject to interference (microwaves, neighbours' networks on the same channel), and it retransmits at L2 when frames are lost. That turns packet loss into latency jitter that higher layers see as random slowness.
Try it yourself
# macOS: Wi-Fi signal (RSSI), noise, channel, PHY mode, transmit rate
sudo wdutil info | sed -n '/WIFI/,/BLUETOOTH/p'
system_profiler SPAirPortDataType | head -40
# macOS: end-to-end capacity + responsiveness under load ("bufferbloat")
networkQuality
# Linux: wired link speed, duplex, auto-negotiation
ethtool eth0
# Linux: L1/L2 error counters. Rising CRC/rx_errors = physical problem
ip -s link show eth0
ethtool -S eth0 | grep -Ei 'err|crc|drop|fcs'
# Linux: Wi-Fi signal and bitrate
iw dev wlan0 link
What healthy looks like: Wi-Fi RSSI better than −65 dBm, noise around −90 dBm (an SNR of 25 dB or more), wired links at their full speed in full duplex, and zero CRC errors that keep increasing.
What breaks
| Symptom you see higher up | Physical cause |
|---|---|
| "Wi-Fi is slow in the bedroom", video calls freeze | Low SNR → low MCS rate + L2 retransmissions |
| TCP throughput is fine at night and terrible at 8 pm | Channel congestion (shared medium), or the shared GPON/cable segment is saturated |
| Steady trickle of CRC errors, slow transfers | Damaged cable, dirty fibre connector, failing optic (check DOM/DDM light levels) |
| A link that keeps going up and down | Bad cable, auto-negotiation fight, overheated transceiver |
| A server NIC stuck at 100 Mb/s | Cable with a broken pair. 1000BASE-T needs all 4 pairs and silently falls back to 100BASE-TX on 2 |
War story: "The database is slow on Tuesdays"
A team spent two weeks tuning queries on a database whose p99 latency spiked at
random. In the end someone ran ethtool -S on the database host and found
rx_crc_errors rising steadily. A fibre patch lead had been crushed under a
rack door. About 0.1% of frames were corrupted, which meant 0.1% packet loss,
which made TCP retransmit after a 200 ms or longer timeout. The "Tuesday"
pattern was the weekly batch job: more traffic meant more corrupted frames.
Lesson: when the latency tail is bad and the median is fine, check for
packet loss first, and check the error counters at the bottom of the stack
before profiling the top.
Why it matters to you
- Latency has a physical floor. If your SLO needs a p50 under 50 ms worldwide, no amount of code optimisation will get you there from one region. That's an architecture decision (CDN, multi-region, edge compute), not a performance ticket.
- Packet loss usually starts physical, but shows up as an application tail-latency problem. Make "check the interface error counters" step 1 of your runbooks.
- "Bandwidth" and "latency" are different budgets. More bandwidth doesn't make a chatty API with 30 sequential calls any faster.
- In the cloud you never touch L1. You just need to know it exists. Choosing an instance type with "up to 10 Gbps" networking is an L1/L2 capacity decision, and "up to" often means burst credits.
Go deeper in the series
- Physical and Wi-Fi in more detail: TCP/IP guide, Chapter 8 (Wi-Fi) and Chapter 27 (latency, bandwidth, bufferbloat).
- Interface counters on a server: Linux guide, Chapter 37.