In 1973 there were several ways to build a local network, and nearly all of them were orderly — a central device handing out turns, reservations made before transmitting, guarantees that data would never collide.
Ethernet did the opposite of every one of those. It let any machine speak whenever it liked, accepted that collisions were certain, and planned only for what to do afterwards.
Forty years later every orderly design is dead, and the one that tolerated collisions is in every building on earth.
This page is about why, and about where the numbers 64, 1500 and 1536 that network people meet daily actually come from.
It sits at the bottom of this site's series, one layer below MAC address, because Ethernet is what defined MAC addresses in the first place.
If you have never noticed, start here
$ ifconfig en0 | grep mtu
... mtu 1500That 1500 is on your machine right now, and it was fixed in a document written before the web was invented, before Wi-Fi existed, and before most people reading this were born.
Every time you meet an MTU problem of the kind described in the ping article, you are meeting the consequence of one decision made in 1980.
1971 in Hawaii — a network that accepted collisions
The University of Hawaii had an unusual problem: its campuses were on different islands, and cabling between them was not worth it, so they used radio.
Radio has a constraint cable does not. Nobody can tell anybody else to be quiet. A station on one island cannot know whether another is transmitting.
ALOHAnet therefore chose what looks like the laziest option — just transmit; if no acknowledgement comes back, it collided, so wait a random moment and try again.
It worked, at 4800 to 9600 bits per second, and more importantly it proved that a network with nobody in charge of turn-taking is viable — an idea nobody had dared believe until then.
Bob Metcalfe wrote his thesis on the throughput analysis of such systems, so he understood both its strengths and its limits better than anyone.
22 May 1973 — the memo that named it
Metcalfe moved to Xerox PARC, which was building a personal computer called the Alto and had a problem: how to let many Altos in one building talk to each other and share a laser printer.
On 22 May 1973 he typed a memo on an IBM Selectric describing a broadcast network to connect them.
And in it he proposed a name, borrowed from what nineteenth-century physicists believed was the medium light travelled through — the luminiferous ether, later proved not to exist:
Let's call it "the ether".
The name fits better than he intended, because what Ethernet does is simulate the air that radio uses, inside a copper cable. Every machine on one cable hears everything, exactly as the island stations heard each other.
Metcalfe recruited David Boggs to build the prototype with him, and it first ran on 11 November 1973.
A speed that came from what was already there
The first Ethernet ran at 2.94 Mbit/s, a suspiciously un-round number.
The reason is entirely practical: the Alto's system clock was 5.88 MHz, and they halved it. No extra circuitry required.
5.88 MHz ÷ 2 = 2.94 Mbit/sThat is the signature of good engineering — not picking a pretty number and building hardware to reach it, but making the most of what was already in hand. And it was still three hundred times faster than ALOHAnet.
The design thinking — accept the chaos rather than forbid it
Early Ethernet had five rules, and none of them needed a central device.
- Listen first. If somebody is sending, wait.
- Send. If it is clear, just send; ask nobody's permission.
- Keep listening while sending. A distorted signal means a collision.
- Jam the line so every machine agrees this frame is ruined.
- Wait a random interval, then retry.
Rule five is the heart of it, and the detail is cleverer than it looks: the random interval doubles with every repeated collision.
collision 1 pick from 2 slots
collision 2 pick from 4 slots
collision 3 pick from 8 slots
... up to 1024 slots
collision 16 give up and drop the frameThe result is that the busier the network, the further every machine backs off by itself. Nobody commands it, nobody measures it, nobody negotiates, yet the system finds its own equilibrium.
This is the same idea that made Internet Protocol win — guarantee nothing, in exchange for no device having to remember anything about anyone. A machine that fails simply disappears, and the rest carry on without noticing.
Why the minimum frame is 64 bytes
Rule 3 hides a constraint from physics: to know a collision happened, you must still be transmitting.
Suppose A starts sending. The signal takes time to reach B, and if B happens to start before A's signal arrives, the two collide and the wreckage travels back towards A.
If A has already finished transmitting before that returns, A will never know the frame was ruined, and nobody will resend it.
So frames must be long enough that a sender is still transmitting for the longest possible round trip.
maximum span allowed 2500 m (five segments of 500)
round trip 5000 m plus the delay of repeaters
budget set at 51.2 microseconds
at 10 Mbit/s 51.2 µs = 512 bits
512 bits = 64 bytes64 is therefore not a number anybody chose for elegance. It is the speed of light in copper multiplied by the cable length allowed, expressed in bits.
The side effect is that shorter frames must be padded with zeros. Sending one byte of data still occupies 64 bytes of cable.
What is inside a frame
preamble 7 bytes 10101010 repeated seven times
SFD 1 byte 10101011
destination 6 bytes receiver's MAC
source 6 bytes sender's MAC
type/length 2 bytes see the next section
payload 46–1500 the actual data
FCS 4 bytes the check valueThe preamble is not counted as part of the frame. It is an alternating 1 and 0 wave sent ahead so the receiver can lock its clock to the sender's, because copper carries no separate clock signal.
The last bit of the SFD flips from 0 to 1, signalling "the real data starts with the next byte."
The FCS covers the whole frame; one wrong bit and the entire frame is discarded — with no retransmission and no notification. It vanishes silently, exactly as IP does with packets.
1536 — the number that separates two standards
In 1980 the DIX group — DEC, Intel and Xerox — published what became known as the Ethernet Blue Book, on 30 September 1980, at 10 Mbit/s.
Later IEEE produced its own standard, 802.3, as a draft in 1983 and a full standard in 1985.
The problem was that the two used the same two-byte field for different things: DIX said what protocol was inside, IEEE said how long the data was.
The resolution was to let the number itself decide:
value ≤ 1500 = length IEEE 802.3 format
value 1501 – 1535 undefined must not be used
value ≥ 1536 (0x0600) = EtherType Ethernet II formatAnd this is why the payload cannot exceed 1500 — a longer length value would collide with the range reserved for EtherTypes, and a receiver could no longer tell which format it was reading.
1500 and 1536 are therefore directly linked, not a coincidence.
Common EtherTypes:
0x0800 IPv4
0x0806 ARP
0x86dd IPv6
0x8100 a VLAN tag followsEvery IP packet that crosses a cable travels inside a frame carrying 0x0800 here — the join between this article and Internet Protocol.
The byte budget, and the price of small frames
Every frame carries a fixed 38 bytes of overhead, whatever it holds.
preamble + SFD 8
frame header 14 (destination 6 + source 6 + type 2)
FCS 4
gap before the next 12
---
38 bytes that are not data largest frame 1500 of 1538 on the wire = 97.5%
smallest frame 46 of 84 on the wire = 54.8%That pair of numbers explains something that confuses people often — a 1 Gbit/s link measuring only half that is usually not faulty. It is carrying many small frames, where nearly half the cable goes to overhead.
It is also why some data centres enable jumbo frames, letting the payload exceed 1500 to push the overhead proportion down further.
From a shared cable to a switch — and the death of CSMA/CD
10BASE5 was the first real deployment: coaxial cable 9.5 mm thick, in segments of 500 metres, with machines attached by piercing the insulation to reach the core using a connector known as a vampire tap.
Every machine was on the same cable and therefore in the same collision domain. One break anywhere took the whole network down.
Twisted pair and hubs followed, which looked better but were still one collision domain — a hub merely repeats the signal out of every port.
Then switches changed everything. Every machine gets its own cable and can send and receive simultaneously, competing with nobody.
The result is that CSMA/CD has nothing left to do. It is still in the standard and still in driver code, but on a fully switched, full-duplex network it never runs.
Its legacy remains entirely intact, though — frames are still a minimum of 64 bytes although there are no collisions to detect, payloads still stop at 1500, and the 12-byte gap is still required. Every one of those numbers solves a problem that disappeared in the nineties.
Worked examples from real work
Case 1 — a link that is full before the number says so
Monitoring reports a 1 Gbit/s link at only 400 Mbit/s, while users say it is slow.
How to read it. Look at frames per second alongside the byte rate. If the average frame works out at 64 to 100 bytes, nearly half the cable's capacity is going to overhead, and that 400 Mbit/s may already be consuming almost all of the real capacity.
Not yet proved. We do not know why the frames are small. It may be the nature of the traffic, or something may be fragmenting data unnecessarily.
Case 2 — error counters that mean something
switch# show interface Gi1/0/14 | include error|collision
0 input errors, 0 CRC, 0 frame, 0 overrun
127 output errors, 0 collisions, 0 interface resetsHow to read it. A non-zero collisions count on a link that should be full duplex means one side is configured half duplex — the classic duplex mismatch, which is very slow without being completely broken.
A non-zero CRC points at the physical layer: cable, connector or module, matching the case diagnosed with ping -p in the ping article.
Not yet proved. These counters accumulate since boot. Clear them and measure again to learn whether the problem is current or historical.
Case 3 — oversized frames dropped in silence
Jumbo frames are enabled on two servers and something breaks.
How to read it. Jumbo frames work only if every device along the path agrees. A switch still set to 1500 discards anything larger without telling anyone, because Ethernet has no mechanism to report it.
The symptom is exactly the PMTU black hole from the ping article: connections establish fine and then hang when a large body is sent.
Not yet proved. We do not know which device is the bottleneck. Walk the MTU of every interface along the path.
What Ethernet teaches
Ethernet beat every orderly design for the same reason Internet Protocol did — it guarantees nothing, so no device has to remember anything.
Networks with a central arbiter work better when everything goes to plan, fail completely when the arbiter fails, and scale badly because the arbiter must be upgraded to match.
A network that accepts chaos just needs another machine plugged in.
And the numbers 64, 1500 and 1536 still in your machine today are the fossil of one 2500-metre coaxial cable that nobody has used for thirty years.
References
History
- Robert Metcalfe's memo of 22 May 1973 at Xerox PARC, the origin of the name Ethernet and of the line proposing it be called the ether
- Ethernet — Wikipedia the first run on 11 November 1973 at 2.94 Mbit/s · the DIX Blue Book of 30 September 1980 · IEEE 802.3 as a draft in 1983 and a standard in 1985 · the details of 10BASE5
- ALOHAnet — Wikipedia the system whose idea Ethernet borrowed
Technical detail
- Ethernet frame — Wikipedia the frame layout · the 1536 boundary between EtherType and Length · the 64-byte minimum derived from the 512-bit slot time · the 96-bit interframe gap
- The current IEEE 802.3 standard, which still carries the CSMA/CD requirements although almost no network uses them any more
Manuals
ifconfigorip linkon the machine you are sitting at, to see the 1500 that has been there since 1980show interfaceon a switch, for the CRC and collision counters that still mean something