The Burst-Capacity Ledger: Bytes, Rates, Airtime, and Retry Load

The Burst-Capacity Ledger: Bytes, Rates, Airtime, and Retry Load

Ada carries the chapter’s device ledger through overhead, outage timing, raw airtime, and retry load

foundations
math-foundations
bandwidth
channel-capacity
intermediate
Ada ADA · CALCULATION AUDIT

The Burst-Capacity Ledger: Bytes, Rates, Airtime, and Retry Load

Three hundred devices each sending a 40-byte reading every 5 minutes offer a payload average of just 320 bps — small enough to look like the shared channel has room to spare. But framing and acknowledgements push the real exchange near 100 bytes, and if those same 300 devices reconnect inside a 15-second recovery window the offered load spikes to 16,000 bps, whose raw airtime alone occupies nearly one second on a 250 kbps PHY. This audit carries the ledger past the payload average — through overhead, outage timing, and retries — to ask whether the channel really has usable headroom.

Companion to the chapter Bandwidth and Channel Capacity — every number here comes from that chapter.

See the relationship before changing it

The figure reads from left to right. The blue card is recovery window. The middle card applies the page rule. The green card is offered burst load. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

Recovery window changes offered burst load An input card leads through the rule load = 300 devices x 100 bytes x 8 / window to the offered burst load result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. Compressing the same queued bytes into less time multiplies the shared-channel load.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 15 s.

  2. 2

    Name the relationship. load = 300 devices x 100 bytes x 8 / window

  3. 3

    Substitute with units. 300 x 100 x 8 / 15 = 16,000 bps

  4. 4

    Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change recovery window

Try Predict the direction of load = 300 devices x 100 bytes x 8 / window. Test another recovery window, then compare offered burst load.

15 s
Chapter baseline
Offered burst load

Observe Compressing the same queued bytes into less time multiplies the shared-channel load. Reset recovery window to 15 and compare offered burst load.

Explain Compressing the same queued bytes into less time multiplies the shared-channel load.

Check yourself

What should you do before trusting a moved-control result?
Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only recovery window moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only recovery window. It is not a field prediction.

TryPress Calculate for 300 devices, 100-byte payloads, and the normal reporting interval before loading the 15-second recovery window.
ObserveOffered load jumps to 16,000 bps during recovery and consumes nearly 1 s of raw airtime on the 250 kbps PHY.
ExplainCompressing the same device bytes into a shorter window multiplies offered load; retries then consume the remaining shared airtime rather than create capacity.

Ready: use the stated baseline inputs, then compare each displayed result.

The ledger, line by line

Check Inputs from this chapter Arithmetic Result
Payload average 300 devices, 40 B, 5 min = 300 s 300 x 40 x 8 / 300 320 bps
Exchange average 300 devices, 100 B exchange, 300 s 300 x 100 x 8 / 300 800 bps before retries
Outage burst 300 devices, 100 B exchange, 15 s 300 x 100 x 8 / 15 16,000 bps
Raw burst airtime 300 exchanges, 800 bits each, 250,000 bps PHY (300 x 800) / 250,000 0.96 s of raw data time
Retry stress 100 devices, 100 B frame, 250,000 bps PHY, 20% retries 100 x 800 / 250,000 x 1.20 0.384 s of raw data time

The rounding happens at the end: 0.96 s is already close to the "nearly one second" warning, and the 0.384 s retry case excludes acknowledgement, backoff, and carrier-sense time. Those omitted terms are why a clean record still needs a busy-window proof.

Every number above is taken from the chapter’s own capacity worked examples and re-derived step by step.

Technical boundaries. Burst correlation, MAC backoff, capture, changing PHY rate, header variation, and queue loss are absent from this fixed event-window capacity audit.