A link is sold in bits a second and a payload is measured in bytes, so every bandwidth estimate contains a factor of eight that is easy to drop and impossible to notice afterwards. The second thing in it is overhead: headers are charged once per request whatever the payload, which makes them a fixed cost with a clean crossover — the payload below which most of what crosses the wire is not your data.
Core ideas
Two units and one fixed cost. The units are where the factor of eight lives; the fixed cost is why small requests are expensive in a way that does not scale with their size.
2 000 requests a second at 1 200 bytes each is 2 400 000 bytes a second, and the same traffic is 19 200 000 bits a second, which is 19.2 Mbit/s. The 8 is not a correction or a safety factor; it is the conversion between the unit the payload is measured in and the unit the link is sold in, and an answer that omits it is exactly an eighth of the truth for every possible input.
200 bytes of headers on a 1 000-byte payload is 1 200 bytes on the wire, and the headers are 1/6 of it. Double the payload and the header share falls; halve it and the share rises. Overhead is a fixed cost per request rather than a percentage of the payload, which means “add ten percent for overhead” is a rule that is wrong in one direction for large requests and in the other for small ones.
Headers are at least half the bytes on the wire exactly when the payload is no larger than the header: h/(p+h) ≥ 1/2 rearranges to h ≥ p. So with 200 bytes of headers, a 200-byte payload is exactly half overhead and anything smaller is mostly overhead. It is a one-line result and it is the thing to remember about small requests.
The material
The unit chain in full, the factor of eight, and what per-request overhead does to small payloads.
Bandwidth is a rate of data across a link, measured in bits per second. A megabit per second is 10⁶ bits a second — decimal, like the rest of the units on this course, because that is what a link is sold in. A byte is 8 bits, so bytes per second times 8 is bits per second.
The chain runs requests per second, bytes per request, bits per byte, bits per megabit. Four rows, three of which are conversion factors, and each one carries the unit it leaves behind. Written out like that the factor of eight is unmissable; done in the head it is the single most common defect in a bandwidth estimate, and it is invisible in the answer because an eighth of a plausible number is another plausible number.
Skipping the third row gives 2.4, and calling that Mbit/s is the truth divided by eight. The lab prints both columns side by side with the ratio between them, which is 8 regardless of what the sliders say, because the error is a missing constant and not an approximation.
Overhead is the bytes a request costs beyond its payload — request and response headers, framing, acknowledgements. It is charged per request and does not scale with the payload, so the bytes on the wire are payload + header and the header share is h/(p+h).
Headers are at least half the bytes on the wire if and only if the payload is no larger than the header: h/(p+h) ≥ 1/2 exactly when p ≤ h.
p and h are positive, so p + h > 0 and the inequality h/(p+h) ≥ 1/2 may be multiplied through by 2(p+h) without changing direction, giving 2h ≥ p + h, that is h ≥ p.
Every step is reversible, so the two conditions are equivalent and the crossover sits at p = h exactly, where the share is 1/2.
□
With 200 bytes of headers, each request is 1 200 bytes on the wire and the link carries 19.2 Mbit/s. Headers are 1/6 of that — 16.7% — and the crossover is at a 200-byte payload, where they would be exactly half. Drag the payload slider down past 200 in the lab and the header share crosses 1/2 at precisely the header size, which is what the theorem says it must.
Two hundred bytes is nothing. Two hundred bytes per request, at a rate high enough to matter, is a fixed cost on every one of them, and its share of the traffic is set by the payload rather than by anything about the link. A system whose requests carry kilobytes pays 16.7%; the same system after someone splits those requests into ten smaller ones pays far more, for the same data, without any line of the estimate looking different.
This is the bandwidth version of an argument that recurs on this path: a per-operation cost is the thing to count, and the number of operations is the thing to control. “Latency Numbers on a Log Scale” is the same point about time, and “Round Trips, Not Bytes” on Latency and the Tail is the same point again about the network.
This course is decimal end to end: 1 kB is 1000 bytes, 1 MB is 10⁶, 1 Mbit/s is 10⁶ bits a second. Disks and links are both sold that way. What produces silent errors is mixing the conventions inside one chain — a 1024-based kilobyte multiplied into a decimal megabit — because the discrepancy compounds at every thousand-step and every intermediate figure still looks like a sensible number.
So state the base once, at the top, and use it everywhere. If a figure arrives from somewhere else in the other base, convert it at the boundary rather than partway through, where the conversion is visible in the chain and can be argued with.
Interactive
Per day to per second, one rate into two, and bytes into bits
Method
Bytes per request first, then bits, then the unit the link is sold in.
The bytes on the wire are payload + header, per request. Doing this first means the rest of the chain multiplies a single figure and there is no temptation to add a percentage for overhead at the end, which is the wrong shape of correction.
req/s × B/req = B/s, with the requests cancelling. This is the last figure in the chain that is still in the units the payload was measured in, and it is worth reading out for that reason.
B/s × 8 bit/B = bit/s. Say it out loud as a unit change rather than a factor: the number has not been corrected, it has been re-expressed in the unit the link is sold in.
1 Mbit/s is 10⁶ bits a second. Decimal, like the storage units, and stated rather than assumed — a chain that silently changes base partway through produces an error that grows at every step and looks like nothing.
Divide the header size by the bytes per request. If the share is anywhere near a half, the payload is near the header size and the estimate is mostly about overhead, which usually means the right fix is fewer, larger requests rather than a bigger link.
The full chain with a unit on every row, then the header share and the crossover payload.
The two lines in the middle are the lesson about units. 2.4 and 19.2 are both plausible link rates, and nothing about the smaller one looks wrong; it is wrong by exactly a factor of eight, for every set of inputs, which means it can never be caught by sanity-checking the answer and can always be caught by writing the units down.
The two lines at the bottom are the lesson about overhead. The share is not a property of the system, it is a property of the payload, and it moves fast once the payload gets near the header size. A design that halves the request size does not halve the bandwidth.
For a faded rehearsal: 5 000 requests a second, 300-byte payloads, 200 bytes of headers. The supplied first move is the bytes per request, 500. Produce the link rate in Mbit/s, the header share as an exact fraction, and the payload at which headers would be half — then set the three sliders in the lab and check. Say the header share before you look; it is larger than most people expect.
You should be able to run a request rate to Mbit/s with a unit on every row, say what dropping the ×8 does and why it cannot be caught by inspection, compute a header share as an exact fraction, and give the crossover payload for any header size without computing anything.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.