Fog Node Task Offloading

Fog Node Task Offloading

Animate local, fog, and cloud placement decisions from latency, queue, transfer, and compute time.

Interactive fog task offloading workbench with scenario presets, animated dispatch paths, deadline checks, queue and transfer calculations, energy estimates, and mobile learning support.

Architecture Fog computing Task placement

Fog Node Task Offloading

Compare the same IoT task across local execution, a nearby fog node, and a cloud service. The recommendation changes when queue delay, transfer time, compute work, deadline, privacy, and device-energy goals change.

Recommendation Fog node

Response time 144 ms

Deadline margin 36 ms spare

Main bottleneck Compute at fog

Current Task

Deadline met

Bearing anomaly

A vibration gateway needs an anomaly score while the machine is still operating.

Deadline 180 ms Payload 0.22 MB Work 520 local-ms Site data

Selected tier Fog node

Device energy 29 mJ

Queue delay 25 ms

Transfer delay 15 ms

Decision formula total_ms = queue_ms + compute_ms + transfer_ms + rtt_ms

Fog wins because local execution misses the deadline while cloud adds too much WAN delay.

Animated Dispatch Path

Profile

Profile

Estimate

Filter

Dispatch

Result

Source IoT device Samples and task profile

Decision engine Compare tiers Deadline, queue, transfer, compute

Local MCU or edge SoC 0 ms network, limited compute

Fog Site fog node Low RTT, shared queue

Cloud Regional service High RTT, strong compute

Placement Scorecards

Deadline first

Controls

Scenario

Decision goal

Live conditions

Fog node load

35%

Device to fog bandwidth

120 Mbps

Cloud round trip time

160 ms

WAN bandwidth

35 Mbps

Keep sensitive data on site

When enabled, sensitive tasks cannot be placed in the cloud. A trusted site fog node is still allowed.

Fog node selected

Fog meets the deadline after adding LAN transfer, queue delay, and fog execution time.

The model is a teaching estimate. Field systems should measure real queue delay, retransmissions, radio state, and server load before automating placement.

Learning Support

Latency trade-offs Latency simulator Fog outage resilience

What the animation compares

Every tier gets the same task profile: deadline, input size, result size, and local-equivalent compute work. The animation compares the time needed to finish and return the result.

Formula and units

transfer_ms = MB * 8 / Mbps * 1000

total_ms = queue_ms + compute_ms + transfer_ms + rtt_ms

Local execution has no transfer or network RTT. Fog and cloud include upload, download, remote execution, queue delay, and round-trip time.

Why fog can lose

• A large payload can make LAN transfer dominate.
• A loaded fog node adds queue delay before compute starts.
• A very short deadline can fail before offloading helps.
• A cloud service can beat fog for very heavy compute if the payload is small and the deadline is loose.

Decision caveats

This is not an optimal scheduler. It is a transparent placement model for learning. Production systems also need admission control, retries, security policy, pricing, thermal limits, and failure handling.

TrySet Cloud round trip time to 160 ms and choose Deadline first. Press Play, then raise Fog node load to compare local, fog, and cloud placement.

ObserveAt a 160 ms Cloud round trip time, cloud slack disappears as WAN transfer consumes the deadline. A loaded fog node adds queue time despite its shorter network path.

ExplainThe displayed latency adds 4 terms: upload, queue, compute, and return. Faster remote compute cannot recover time already spent moving or waiting.

Technical boundaries. Placement uses deterministic component times; contention distributions, pre-emption, cache locality, migration overhead, thermal throttling, node failures, and network energy are not simulated.