Edge vs Cloud Latency Workbench

Compare end-to-end latency when compute runs on the device, a nearby gateway, or a remote cloud region

Interactive edge, fog, and cloud latency workbench that shows how payload size, bandwidth, congestion, cloud distance, and compute complexity change network, queue, processing, and response latency.

Animation Edge Fog Cloud

Edge vs Cloud Latency Workbench

Latency is not just distance. A placement decision combines request transfer time, queueing, processing time, and response time. Use this model to see when local edge compute wins, when a gateway is the best compromise, and when cloud compute is fast enough despite the network path.

FogBest current placement

42 msLowest estimate

100 msLatency target

networkMain bottleneck

Scenarios

Controls

Payload size 10 KB

Bandwidth 10 Mbps

Compute complexity 4/10

Congestion low

Cloud distance regional

Latency target 100 ms

Ready to compare placements

What To Watch

The fastest placement is the one with the smallest total, not the smallest network distance alone. Watch the stacked bars to see which component dominates.

PayloadLarge uploads penalize fog and cloud because serialization time grows with data size.

ComputeCloud CPUs are modeled faster, while device-local processing is slower but avoids network hops.

CongestionQueueing and transfer delays can make a good placement miss the target.

TargetA relaxed target may allow cloud; a tight control loop often needs edge or fog.

Compute Placement Route

Focus: fog gateway

Latency Breakdown

request/network queue/wait processing response target

Current State

gateway routeActive path

10 KB requestPayload model

gateway CPUCompute model

target metBudget result

Learning Diagnosis

Calculation Transcript

Quick Reference

EdgeCompute near or on the device. Short path, weaker local compute, strong privacy and control-loop fit.

FogCompute at a gateway or local site. Adds a hop, but usually gives stronger compute than a tiny device.

CloudRemote elastic compute. Strong processing and aggregation, but network RTT and transfer time matter.

How To Read The Animation

• The highlighted route shows where the request is processed for the active placement.
• The result cards show whether each placement meets the selected latency target.
• The stacked bars show why a result is high: request transfer, queueing, processing, or response return.
• Use Step to compare edge, fog, and cloud one at a time without changing the scenario.

Technical Accuracy Notes

• This is an illustrative placement model, not an SLA calculator. Real latency depends on routing, radio access, protocol overhead, server load, packet loss, and implementation details.
• The request serialization estimate uses payload KB * 8 / Mbps milliseconds, treating 1 Mbps as about 1 kilobit per millisecond.
• Cloud distance is modeled as a baseline RTT. Request and response propagation each use half of that RTT.
• Processing multipliers intentionally differ by tier: edge is slower but nearby, fog is moderate, and cloud is faster but farther away.
• Queueing grows with congestion and is separated from transmission time so learners can see congestion effects clearly.