Energy & Power · Study deck

Compute Offloading and Placement

Picture a battery camera that must spot a person before opening a gate.

Battery Bruno is your guide for this deck.

contextoffloading
Battery Bruno, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Build a local-versus-remote energy ledger for an IoT workload.
  • Explain why upload size, result size, radio state, retries, and latency affect offloading decisions.
  • Apply MAUI-style runtime profiling without treating cloud execution as automatically cheaper.
  • Decide when edge offload, cloud offload, local acceleration, partial offload, or deferral is the best placement.
Local and remote energy ledgers feed latency, privacy, connectivity, and reliability gates before an offload decision.
Local and remote energy ledgers feed latency, privacy, connectivity, and reliability gates before an offload decision.
iotclass.org

Major section

Start With a Choice: Compute Here or Transmit

The first useful comparison measures the same decision both ways.

  • DSP means digital signal processing, or math that changes or extracts meaning from sampled signals.
  • A gateway means a device or service that joins two system paths.
  • Latency means the time from an input event to the result that matters.

Key terms

None of those choices
None of those choices is automatically cheaper; the winner depends on radio energy, data size, latency, privacy, and accelerator fit.
iotclass.org

Major section

Start With a Choice: Compute Here or Transmit (continued)

Weaken the link, repeat the request, restart the gateway, and keep a safe local response when the remote answer is missing or stale.

  • This runway does not prove that local or remote work is always cheaper.
  • The deeper sections compare processor fit, radio states, transfer size, privacy, waiting cost, and the break-even evidence for each placement.
  • A device can process data locally, send features to an edge node, or push raw samples to the cloud.
  • None of those choices is automatically cheaper; the winner depends on radio energy, data size, latency, privacy, and accelerator fit.
iotclass.org

Major section

The Offloading Ledger

An offloading decision starts by comparing two ledgers at the same workload boundary.

  • The local branch counts processor power over run time.
  • The remote branch counts upload, wait, download, radio tail, server cost, and retries.
  • A faster remote run does not always save energy.
  • Those values alone do not prove that offloading wins.

Key terms

Vendor datasheet currents
Vendor datasheet currents are useful for early sizing, but promotion decisions need current traces or power-monitor logs.
MAUI Code Offloading Decision: Local vs. Remote
MAUI Code Offloading Decision: Local vs. Remote
iotclass.org

Major section

Worked Example: Feature Extraction

Scenario: A wearable collects a 150 kB motion window and runs a feature-extraction model.

  • Local CPU execution takes 5 seconds at 180 mW.
  • Wi-Fi offload path: upload the 150 kB window, receive a small result, and wait for remote processing.
  • Cellular offload path: the same transfer uses a higher-power radio and includes state-transition overhead.

Why it matters

For this workload, Wi-Fi offload is attractive because the compute is heavy and the transfer is moderate.

iotclass.org

Major section

Heterogeneous Local Computing

For heterogeneous local computing, a result at checks workload type, deadline, is incomplete without: CPU baseline.

  • Tooling and fixed-point constraints can make integration harder.
  • Setup power can dominate small tasks; speedup is not the same as energy savings.
  • Unsupported layers, memory pressure, or model conversion can force fallback.

Key terms

checks workload type, deadline,
checks workload type, deadline, is incomplete without CPU baseline.

Why it matters

Heterogeneous computing changes the offloading tradeoff because the local option is no longer only "general CPU." Many IoT and mobile-class devices include lower-power accelerators for specific work.

Heterogeneous SoC placement: a context-aware scheduler chooses the lowest-energy local engine that fits the workload before comparing edge or cloud offload.
Heterogeneous SoC placement: a context-aware scheduler chooses the lowest-energy local engine that fits the workload before comparing edge or cloud offload.
iotclass.org

Major section

Reading the Keyword-Spotting Benchmarks

An optimized local GPU path was about 6.5 times faster than the cloud comparison in one measurement and about 21.3 times faster than a sequential CPU implementation in another.

  • and always name AAA, BBB, the batch size, model, precision, data-transfer boundary, and whether setup time is included.

Why it matters

Higher link throughput reduces the payload-time terms in EcloudE_{cloud}Ecloud​, yet it does not erase attach, wait, retry, or tail energy.

Low-power edge scheduler joining a sensor-job buffer with workload and resource monitors before dispatch to CPU, DSP, or GPU.
Low-power edge scheduler joining a sensor-job buffer with workload and resource monitors before dispatch to CPU, DSP, or GPU.
iotclass.org

Major section

Reading the Keyword-Spotting Benchmarks (continued)

Cloud energy also changes with bandwidth and batching.

  • Ecloud=Eattach+PtxDupRup+Pwaittremote+PrxDdownRdown+Etail, E_{cloud}=E_{attach}+P_{tx}\frac{D_{up}}{R_{up}}+P_{wait}t_{remote} +P_{rx}\frac{D_{down}}{R_{down}}+E_{tail}, Ecloud​=Eattach​+Ptx​Rup​Dup​​+Pwait​tremote​+Prx​Rdown​Ddown​​+Etail​,.
  • Increasing batch size bbb amortizes the fixed local wake and setup costs, but it also delays the oldest sample by roughly the batch-formation time.
  • Its output is not merely an engine name: the retained record includes the inputs, chosen placement, measured outcome, and fallback, allowing a later review to explain why the decision changed under another load or energy condition.

The same experiments reported two different speedups because they used two different baselines.

An optimized local GPU path was about 6.5 times faster than the cloud comparison in one measurement and about 21.3 times faster than a sequential CPU implementation in another.

Keyword-spotting placement comparison linking local accelerator runtime to cloud radio energy across batch size and bandwidth.
Keyword-spotting placement comparison linking local accelerator runtime to cloud radio energy across batch size and bandwidth.
iotclass.org

Deck summary

Key takeaways

The first useful comparison measures the same decision both ways.

  • Weaken the link, repeat the request, restart the gateway, and keep a safe local response when the remote answer is missing or stale.
  • An offloading decision starts by comparing two ledgers at the same workload boundary.
  • Scenario: A wearable collects a 150 kB motion window and runs a feature-extraction model.
  • For heterogeneous local computing, a result at checks workload type, deadline, is incomplete without: CPU baseline.
iotclass.org

Retrieval practice

Recall check 1 of 5

Battery Bruno says: answer from memory, then check your reasoning.

Q1A device spends 900 mJ running a feature-extraction task locally. The Wi-Fi remote path costs 240 mJ upload, 9 mJ download, and 12 mJ wait energy. If latency and privacy are acceptable, what should the policy choose?

AUse local CPU to avoid transfer because the 900 mJ task cost is lower than the radio path.
BUse local CPU because upload costs more than the small download.
CUse cloud offload for every radio path because transfer energy stays below local processing energy.
DUse Wi-Fi offload: its 261 mJ total is below 900 mJ local cost.
Show answer

Answer: D The offloading ledger compares total local energy with total remote-path energy, then applies latency, privacy, availability, and reliability gates.

iotclass.org

Retrieval practice

Recall check 2 of 5

Battery Bruno says: answer from memory, then check your reasoning.

Q2A wake-word detector runs every second and can execute on either the CPU or an always-on DSP. Which evidence most strongly supports moving it to the DSP?

AThe DSP has a higher peak clock speed than the CPU for this workload.
BA cloud model is larger than the model supported on this detector.
CA measured DSP trace has lower current at equal accuracy and latency.
DThe GPU exists, so all wake-word processing should move onto it.
Show answer

Answer: C Heterogeneous computing is useful only when the selected processor lowers total energy while preserving timing, accuracy, and integration requirements.

iotclass.org

Retrieval practice

Recall check 3 of 5

Battery Bruno says: answer from memory, then check your reasoning.

Q3What can veto remote offload despite its attractive energy estimate?

AWorkload boundary
BLocal compute ledger
CRemote transfer ledger
DPolicy gates
Show answer

Answer: D Privacy, connectivity, deadline, trust, battery, and fallback constraints can veto an attractive energy result.

Q4Which workload is the best candidate to offload from a battery node for energy reasons?

AA seconds-long inference with a small feature vector.
BA one-line threshold comparison applied to a large raw image.
CA short calculation sent over an already connected radio.
DA workload whose input is huge and whose computation is tiny.
Show answer

Answer: A Offloading wins when you avoid a lot of computation while moving only a little data.

iotclass.org

Retrieval practice

Recall check 4 of 5

Battery Bruno says: answer from memory, then check your reasoning.

Q5A 2 s inference costs 30 mA-s locally. The radio costs 0.00096 mA-s per byte. The node must decide placement for an 80 KB raw input. What is the energy-correct choice?

AOffload because cloud execution is faster, without counting radio charge.
BOffload because per-byte radio cost looks small in isolation.
CTreat both paths as equal energy because the 80 KB upload has negligible radio cost.
DCompute locally: an 80 KB upload costs about 79 mA-s, above 30 mA-s.
Show answer

Answer: D see answers page

iotclass.org

Retrieval practice

Recall check 5 of 5

Battery Bruno says: answer from memory, then check your reasoning.

Q6An offload decision computed from active transmit time alone shows offloading a small payload over cellular is cheaper than local compute, but the measured battery drain says the opposite. What is the most likely missing cost?

ACellular setup energy and the post-transfer radio tail.
BCloud-server energy mistakenly charged to the device battery.
CMCU compute energy accidentally counted twice in the ledger.
DNo missing cost; active transmit time covers the whole offload.
Show answer

Answer: A Cellular attach and the post-transmission tail draw significant current that a payload-only estimate ignores.

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. D · The offloading ledger compares total local energy with total remote-path energy, then applies latency, privacy, availability, and reliability gates.
  2. C · Heterogeneous computing is useful only when the selected processor lowers total energy while preserving timing, accuracy, and integration requirements.
  3. D · Privacy, connectivity, deadline, trust, battery, and fallback constraints can veto an attractive energy result.
  4. A · Offloading wins when you avoid a lot of computation while moving only a little data.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. D · 81920 x 0.00096 = 79 mA-s to offload, versus 30 mA-s to compute on the node. The 80 KB payload is well above the ~30 KB break-even, so local wins on energy. (Also: more than double the 30 mA-s local run.).
  2. A · Cellular attach and the post-transmission tail draw significant current that a payload-only estimate ignores.
iotclass.org