An 8x Backhaul Gap No Schedule Can Close
An 8x Backhaul Gap No Schedule Can Close
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
An 8x Backhaul Gap No Schedule Can Close
A factory streams 500 vibration sensors at 1 kHz, 4 bytes a sample — 16 Mbps of raw data — over a cellular backhaul of only 2 Mbps, an 8x oversubscription. One day piles up 172.8 GB against a link that can carry just 21.6 GB, so a single day’s batch upload takes about 8 days. This audit asks whether any smarter schedule or bigger buffer can close that gap, or whether the architecture must discard roughly 87.5% of the data at the edge.
Companion to the chapter IoT Architecture Planner — every number here comes from that chapter.
A factory streams 500 vibration sensors at 1 kHz , 4 bytes a sample — 16 Mbps of raw data — over a cellular backhaul of only 2 Mbps , an 8x oversubscription. Calculate this case.
This audit asks whether any smarter schedule or bigger buffer can close that gap, or whether the architecture must discard roughly 87.5% of the data at the edge. Check shows this.
The design meaning is that an 8x capacity gap is a structural fact, not a tuning knob: no smarter schedule, off-peak window, or larger buffer can move 172.8 GB/day through a 21.6 GB/day pipe, so the architecture either reduces data at the edge by roughly seven-eighths or it fails. Check confirms it.
See the relationship before changing it
Change the input, apply the rule once, then read the result with its unit.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 1000 samples/s.
- 2
Name the relationship. rate = 500 sensors x samples/s x 4 bytes x 8 bits / 1,000,000
- 3
Substitute with units. 500 x 1000 x 4 x 8 / 1,000,000 = 16.00 Mbit/s
- 4
Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.
Predict, then change samples per sensor
Try Predict how raw data rate responds when samples per sensor moves. Calculate samples per sensor; compare raw data rate with that prediction.
Observe Return to 1000 samples/s. Recheck raw data rate with samples per sensor at its chapter value.
Explain More samples grow the raw stream in direct proportion.
Check yourself
What should you do before trusting a moved-slider result?
What does this small model leave out?
Technical boundaries
Only the sampling rate changes; the stream still contains 500 sensors and four bytes per sample. This raw-byte count excludes bursts, protocol overhead, compression, competition for the backhaul, failover, and delay or reliability requirements.
Ada: The factory-sensor question above rests on a few numbers — 16 Mbps of raw data against a 2 Mbps link, and a batch upload that “takes nearly 8 days.” Let me verify them and then show why edge processing is not optional here.
The raw rate:
500 sensors x 1000 samples/s x 4 bytes = 2,000,000 bytes/s = 2 MB/s- In bits:
2,000,000 x 8 = 16,000,000 bit/s = 16 Mbps
Against a 2 Mbps backhaul, the oversubscription is 16 / 2 = 8x. That factor is the whole problem, and batching cannot dodge it. One day generates 2 MB/s x 86,400 s = 172.8 GB, while the link can carry only (2 / 8) MB/s x 86,400 = 21,600 MB = 21.6 GB/day. The ratio is the same 172.8 / 21.6 = 8, so uploading a single day’s data takes 172.8 / 21.6 = 8 days — and every real day adds another 172.8 - 21.6 = 151.2 GB to a backlog that can only grow.
So the only way through is to shrink the data at the source. To fit 16 Mbps into 2 Mbps the edge must discard (16 - 2) / 16 = 87.5% of the volume before it reaches the link — which is exactly why the answer cites a 90-99% reduction, not a modest trim.
The design meaning is that an 8x capacity gap is a structural fact, not a tuning knob: no smarter schedule, off-peak window, or larger buffer can move 172.8 GB/day through a 21.6 GB/day pipe, so the architecture either reduces data at the edge by roughly seven-eighths or it fails.
Every number above is taken from the chapter’s own material and re-derived step by step.