Five Bytes Shipped for Every One That Matters
Five Bytes Shipped for Every One That Matters
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
Five Bytes Shipped for Every One That Matters
A 12-byte sensor reading picks up 28 bytes of IPv4-plus-UDP header, or 48 bytes over IPv6 — which is why the chapter notes the packet carries “more header than payload”. But “more” is vague, and that ratio is the whole reason a tiny reading can still be expensive to send. This audit puts a number on it, asking how many bytes ship for every one that matters.
Companion to the chapter Devices, Packets, and Layers — every number here comes from that chapter.
See the relationship before changing it
The figure reads from left to right. The blue card is ipv6 and udp header. The middle card applies this page's rule. The green card is payload efficiency. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only ipv6 and udp header, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 48 bytes.
- 2
Name the relationship. efficiency = 12 payload bytes / (12 + header bytes) x 100
- 3
Substitute with units. 12 / (12 + 48) x 100 = 20.0%
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change ipv6 and udp header
Try Predict the direction of efficiency = 12 payload bytes / (12 + header bytes) x 100. Test another ipv6 and udp header, then compare payload efficiency.
Observe A larger fixed header makes the same twelve-byte reading a smaller share of the datagram. Reset ipv6 and udp header to 48 and compare payload efficiency.
Explain A larger fixed header makes the same twelve-byte reading a smaller share of the datagram.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
Ready: use the stated baseline inputs, then compare each displayed result.
Ada: The worked example says a 12-byte reading picks up 28 bytes of IPv4-plus-UDP header, or 48 bytes with IPv6-plus-UDP, and concludes the packet “carries more header than payload.” That is true, but “more” is vague — let me put a number on how much, because the ratio is the whole reason a tiny reading can still be expensive.
The header sums first: 20 + 8 = 28 bytes for IPv4+UDP, and 40 + 8 = 48 bytes for IPv6+UDP. Now the useful fraction of each packet, before any link framing or security is added:
- IPv4 + UDP: total
12 + 28 = 40bytes, payload efficiency12 / 40 = 0.30, that is 30% - IPv6 + UDP: total
12 + 48 = 60bytes, payload efficiency12 / 60 = 0.20, that is 20%
Flip that around and it is starker: 60 / 12 = 5.000 on the IPv6 path, so the device transmits five bytes for every one byte of reading; the IPv4 path is 40 / 12 = 3.333, about three and a third. And this is the optimistic figure — it counts only network and transport headers, before the data-link frame, addressing, and any encryption the chapter says still have to be added on top, all of which push the useful fraction lower.
That is why the chapter starts a network review from the message, not the protocol: at 12 bytes of payload the overhead dominates, so how often the reading repeats — and how much header each repeat drags along — decides the airtime and energy bill, a cost that is invisible if you look only at the reading itself.
Every number above is taken from the chapter’s own material and re-derived step by step.