Old-School Networking

• What's on the cable — the bytes before and after that Wireshark doesn't show, and the FCS check value, worked out by hand
• Bits into signals — the order bits go out within a byte, and how 10BASE-T, 100BASE-TX and 1000BASE-T differ
• Three paths — network cable (copper), optical fibre (light) and Wi-Fi (radio)
• What speed really means — set the practice network's “cable” to 10 M, 100 M and 1 G and measure

In a sentence, the physical layer's job is to turn 0s and 1s into signals that reach the other end: voltages on copper, brightness of light in fibre, changes in radio waves for Wi-Fi. The receiver reads the signal at fixed intervals and turns it back into 0s and 1s.

To make that work, physical-layer standards specify a lot of detail: the shape of the connector and its pin layout, the kind and length of cable, voltages or wavelengths, how long each bit lasts, and how the receiver keeps its clock in step with the sender. On the other hand, the physical layer doesn't know the content. It doesn't care whether the bits are IP or JSON.

A word on units. Line speed is counted in bps (bits per second). File sizes are in bytes, so remember to divide by 8. Even a 1 Gbps line carries at most 125,000,000 bytes (about 125 MB) a second.

The submission Wireshark showed us in part 1 was 266 bytes. On the cable, though, a little more goes before and after it.

First comes the preamble: 7 bytes of alternating 0s and 1s (55 in hexadecimal). The receiver listens to it and syncs its clock to the sender's. The SFD (d5) that follows says “the frame starts here”. At the end, the FCS is a 4-byte check value, made with a calculation called CRC-32, for spotting damage on the way. After the frame there must be a gap of at least 12 byte-times.

The sender's NIC (network interface) adds the FCS and the receiver's NIC checks and removes it, so Wireshark normally doesn't show it. So I calculated it myself from part 1's 266 bytes.

# Compute the FCS added at the end on the cable, from part 1's 266 bytes (packet 8, the claim)
>>> import zlib
>>> frame = bytes.fromhex('020000000101 0200000001100800 4500 …')  # 266 bytes
>>> hex(zlib.crc32(frame))
'0xa27156ea'
>>> fcs = zlib.crc32(frame).to_bytes(4, 'little')   # goes on the cable as ea 56 71 a2
>>> hex(zlib.crc32(frame + fcs))
'0x2144df1c'   # the receiver's check: an undamaged frame always gives this value
# if one bit flips on the way and 46851 becomes 56851...
>>> broken = frame.replace(b'46851', b'56851')
>>> hex(zlib.crc32(broken + fcs))
'0xce86b422'   # no match, so the frame is dropped (never handed up)

If even one bit flips, the check fails and the frame is silently dropped. The physical and data link layers go only as far as “never deliver something broken”; they don't resend. Resending is TCP's job, in part 6.

The first thing to watch when turning bits into signals is the order. Ethernet sends bytes from first to last, but within a byte the least significant bit goes first. The SFD d5 is 11010101 in binary, yet it leaves on the cable as 1,0,1,0,1,0,1,1.

With the plain approach (1 is high, 0 is low), a long run of 0s makes it hard for the receiver to count how many bits went by: its clock slowly drifts. So 10BASE-T uses Manchester code, which always flips in the middle of every bit, giving the receiver a transition to re-sync on. The price is a signal that changes twice as fast.

The faster the standard, the cleverer the trick.

1000BASE-T changes the signal 125 million times a second, the same as 100BASE-TX, yet runs ten times faster. It uses twice the wires (4 pairs), carries more per symbol (five levels), and sends and receives on the same pair at once, thanks to “echo cancellation”, which subtracts the reflection of its own signal.

The most familiar path is network cable (twisted pair). Inside are eight copper wires, twisted together in four pairs.

Why twist them? Each pair carries opposite “plus” and “minus” signals, and the receiver reads the difference between the two wires. Noise from outside lands equally on both twisted wires, so taking the difference cancels it. How tightly the wires are twisted (and shielded) is what separates cable categories.

For a home or office, buying Cat6A today keeps you out of trouble. Whatever the category, the basic limit is 100 m per run. Beyond that, you use the optical fibre in the next section.

Optical fibre traps light inside glass as thin as a hair. With no electricity involved, it shrugs off noise and reaches far. Between buildings, inside data centres, all the way to cables on the sea floor, long distances are almost all light.

On the switch side, a plug-in part called an SFP converts between light and electricity. The same switch can take multimode, single-mode or even copper, depending on which SFP you plug in.

Light in glass travels at about two-thirds of its speed in a vacuum: roughly 5 microseconds per kilometre. We'll use that number again in section 9.

Wi-Fi is a physical layer that carries bits by radio (IEEE 802.11 defines its data link rules too). Each generation has got faster.

In Japan, 5925–6425 MHz of the 6 GHz band opened up for wireless LAN on 2 September 2022. Wi-Fi 7 certification began in January 2024.

The figures in the table, though, are theoretical maxima under perfect conditions. Radio is shared by everyone in the air, so only one device can talk at a time (half duplex). Walls and distance weaken it, and it clashes with the neighbours' Wi-Fi. For machines where speed matters, or a PC that never leaves the desk, a cable is the surest choice.

There are two kinds of box for bringing many cables together. The old hub is a physical-layer machine: whatever arrives on one port, it repeats out of every other port.

Machines on a hub effectively share one line. If two send at once the signals collide, so they took turns by a rule (CSMA/CD): listen until the line is free before sending, and if a collision happens, wait a little and send again.

A modern switch reads the destination MAC address and sends the frame only to the port where that device sits (more in part 3). Each port has its own path, so nothing collides. Full duplex, sending and receiving at the same time, became the norm, and collisions are mostly history.

The light above each port is the physical layer's “connected” sign: the link. When you plug in a cable, the two ends tell each other what speeds and modes they support (auto-negotiation) and pick the fastest combination. That's why the light takes a moment to come on.

Back to the opening question: how much faster is a 1 Gbps line than a 10 Mbps one? On part 1's practice network I put a “this many bits per second at most” tap on both sides of the router, setting the cable speed to 10 M, 100 M and 1 G (using a Linux feature called tc), and measured.

# put a “10 megabits per second max” tap on both router ports (tbf)
$ tc qdisc add dev lan0 root tbf rate 10mbit burst 15kb latency 100ms
$ tc qdisc add dev wan0 root tbf rate 10mbit burst 15kb latency 100ms
# same for 100 Mbps and 1 Gbps; remove it to go back

I measured two things: downloading a 5-million-byte file, and the same single submission (POST) as in part 1.

The big download scaled with speed, 4.175 s → 0.416 s → 0.042 s: exactly a hundred times faster (the actual rates were 9.6, 96.3 and 951.2 Mbps, a little under the line speed because of the headers). The submission, however, went 1.21 → 1.07 → 1.03 ms: just 1.2 times faster. 266 bytes go through in about 0.2 ms even at 10 Mbps.

A line has two kinds of speed: width (bandwidth) and length (latency). This practice network lives inside one machine, so its length is nearly zero. On a real network, the time light takes to travel alone looks like this (a theoretical floor, at about 5 microseconds per kilometre of fibre).

Real cables don't run in straight lines and routers along the way add waits, so actual figures are higher. However wide you make the line, light doesn't get faster. To speed up small API calls, cut the number of round trips or move the server closer. That idea will matter when we build the back end.

By the way, here is how the “cable” in the practice network from part 1 describes itself.

# ethtool on the PC's “cable” in part 1's practice network
$ ethtool eth0
    Speed: 10000Mb/s
    Duplex: Full
    Auto-negotiation: off
    Port: Twisted Pair
    Link detected: yes
$ ethtool -i eth0
    driver: veth
# veth = a virtual cable that exists only in software; the speed and “twisted pair” are nominal

Here is how to see what speed your PC is connected at.

From the other layers, physical-layer faults look like “somehow slow” or “drops out now and then”. Here are the usual suspects.