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 until the overflow rule kicks in and routes the overflow to the cloud — trading a longer, but predictable, round trip for a bounded queue. Note this engine runs the arrival/service process as a deterministic fluid approximation (packets spread evenly at rate λ, service exactly 1/μ) rather than drawing random exponential gaps — it keeps the exact same wait-time and overflow formulas as a stochastic M/M/1 queue, just without the randomness, so the trade-off is easier to read on screen. 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.
Drag the network diagram to pan, scroll/pinch to zoom — the queue stack next to the edge gateway grows and shrinks live with the readout above.