Edge Offloading: Energy vs Latency Simulator

Task Parameters

Task data size 120 KB

Local CPU frequency 1.2 GHz

Wireless bandwidth 10 Mbps

Policy weight α (energy ⟷ latency) 0.50

Decision Policy

Predicted per Task

Local time

0 ms

Offload time

0 ms

Local energy

0 mJ

Offload energy

0 mJ

Live Session Stats

Battery used

0.0 mJ

Offload ratio

Tasks completed

Tasks in flight

How it works

Each task of size D needs C = D × L processor cycles, where L is a fixed workload density (cycles per bit — a stand-in for how compute-heavy the task is). Two routes compete for every task:

Local:    T_local = C / f_local
          E_local = C × κ × f_local²   (dynamic CMOS power ∝ f²)

Offload:  T_tx      = D / R                (R = wireless bandwidth)
          T_offload = T_tx + C / f_edge     (f_edge is a fast, fixed edge server)
          E_offload = P_tx × T_tx           (radio energy only — the edge server pays its own compute energy)

Adaptive score:  score = α·(T / T_max) + (1-α)·(E / E_max)
                 route with the LOWER score wins this task

Task size / CPU frequency / bandwidth — recompute T and E for both routes live; raising local frequency cuts local time but raises local energy (the f² term), which is the classic mobile-edge-computing trade-off.
α slider — 0 optimizes purely for battery life, 1 optimizes purely for speed, in between blends both (only used in Adaptive mode).
Always Local / Always Offload / Adaptive — force a route or let the scored policy decide per task, exactly as a real MEC (mobile edge computing) offloading controller would.

This is the standard computation-offloading model used in mobile/IoT edge-computing research (e.g. Kumar & Lu's energy-latency offloading analysis): a device with limited battery deciding, task by task, whether local silicon or a nearby edge server is the better place to run the work.

Local compute Offloaded task Wireless link

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.