IoT Edge vs Cloud Latency Simulator

Traffic

Data generation rate (λ) 10 pkt/s

Edge Gateway

Edge processing capacity (μ) 12 pkt/s

Overflow threshold (queue length) 6 pkt

Cloud

Round-trip latency to cloud 80 ms

Live Readouts

Edge queue length

Avg latency

0 ms

Cloud offload

Packets processed

How it works

Every sensor reading is a packet that must be processed somewhere. This simulator models the classic IoT choice: process at the edge gateway, right next to the device, or send it up to the cloud.

Edge latency  = 2·T_prop,edge + W_queue + 1/μ
Cloud latency = T_round-trip,cloud + T_service,cloud
W_queue: FIFO wait until the single edge server is free

The edge gateway is modelled as a single first-come-first-served server with fixed service capacity μ (packets/sec). Every new packet checks the current queue length first:

If the queue is below the overflow threshold, the packet queues at the edge. Its latency is a short, fixed local hop (~4 ms round trip) plus however long it waits behind packets already in line, plus its own 1/μ service time — exactly the wait-time term of a single-server queue.
If the edge queue has already backed up past the threshold, the gateway offloads the packet straight to the cloud instead of making it wait — the cloud has near-limitless elastic capacity, but every packet pays the full network round trip you set above.

Raise the arrival rate λ past the edge's capacity μ and the queue grows without bound (an unstable M/M/1-style queue) until the overflow rule kicks in and routes the overflow to the cloud — trading a longer, but predictable, round trip for a bounded queue. This is exactly the design trade-off real IoT gateways (AWS Greengrass, Azure IoT Edge, on-prem MQTT brokers) make between local compute and cloud elasticity.

Device sensor Edge-routed packet Cloud-routed packet

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