The Offload Break-Even
The Offload Break-Even
Ada re-derives the offload break-even — time and battery for the transcode, local vs surrogate
ADA · CALCULATION AUDIT
Foundations · optional mathematics
The Offload Break-Even
The chapter transcodes a 4K clip two ways: locally it takes 320 s and drains 248.9 mAh, while offloading the three legs to a nearby laptop takes 149.3 s and just 18.7 mAh. Offloading only wins if transfer plus remote compute beats the local run. This audit computes the offload break-even to the second, showing it saves 53% of the time but 92% of the battery.
Companion to the chapter Edge Cyber-Foraging and Caching — every number here comes from that chapter.
Ada's Calculation Audit: the offload break-even — time and battery for the 4K transcode, local vs surrogate, ~4 minutes
Offloading only wins if transfer time plus remote compute beats the local run. Here is the break-even for the chapter's transcode, computed to the second.
See the relationship before changing it
The figure reads from left to right. The blue card is upload rate. The middle card applies this page's rule. The green card is upload time. 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 upload rate, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 50 Mbit/s.
- 2
Name the relationship. upload time = 3,840 Mbit / link rate
- 3
Substitute with units. 3,840 / 50 = 76.8 s
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change upload rate
Try Predict the direction of upload time = 3,840 Mbit / link rate. Test another upload rate, then compare upload time.
Observe A faster link shortens one offload leg, while remote compute and download remain fixed costs. Reset upload rate to 50 and compare upload time.
Explain A faster link shortens one offload leg, while remote compute and download remain fixed costs.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
The working
1. Time is size over rate; battery is current over time.
2. Run it locally. 3840 MB ÷ 12 MB/s = 320 s. Battery = 2800 mA × 320 s = 896,000 mA·s ÷ 3600 = 248.9 mAh.
3. Offload the three legs. Upload 3840 ÷ 50 = 76.8 s; remote transcode 3840 ÷ 180 = 21.3 s; download 2560 ÷ 50 = 51.2 s; total = 149.3 s. Battery = 450 mA × 149.3 s = 67,200 mA·s ÷ 3600 = 18.7 mAh.
| Path | Time arithmetic | Time | Battery |
|---|---|---|---|
| Local | 3840 ÷ 12 | 320 s | 248.9 mAh |
| Offload: upload | 3840 ÷ 50 | 76.8 s | — |
| Offload: remote | 3840 ÷ 180 | 21.3 s | — |
| Offload: download | 2560 ÷ 50 | 51.2 s | — |
| Offload: total | 76.8 + 21.3 + 51.2 | 149.3 s | 18.7 mAh |
| Saving | (320−149.3)/320; (248.9−18.7)/248.9 | 53.3% | 92.5% |
What the audit buys you: the phone's radio draws 450 mA but for only 149 s, while its CPU draws 2800 mA for 320 s — so offloading wins on battery (92%) by a far wider margin than on time (53%), because it is the surrogate, not the phone, that pays the compute energy.
The offload comparison deliberately does not simulate connection setup, rate variation, contention, privacy controls, remote queueing, thermal throttling, or failed transfers; size/rate and current/time are held constant for each leg.
Work the audit first, then check the displayed derivation.
Every number above is taken from the chapter's own cyber-foraging offload example and re-derived step by step.