Edge Computing Latency Simulator

Network Topology

Edge nodes 3

Edge capacity (slots/node) 4

Edge processing time 8 ms

Request rate 6 req/s

Live Metrics

Avg latency

0 ms

Edge offload rate

Throughput

0 req/s

Edge Node Load

How it works

Every client request is routed to its nearest edge node first. If that node still has a free processing slot, it is served locally; otherwise the request is forwarded to a distant, centralized cloud. Total end-to-end latency is modelled as:

L = 2·d·k_prop + t_proc + q·t_proc

d      = distance to the serving node
k_prop = propagation constant (ms per world-unit, round trip)
t_proc = fixed processing time at that node
q      = number of requests already being served there (queueing delay)

This is a simplified M/M/c-style queue: each node can serve up to capacity requests concurrently; a request that arrives when all slots are busy overflows to the cloud, which is far away (large propagation delay) but effectively never saturates.

Edge nodes — more nodes shrink the average distance a request has to travel, cutting propagation delay.
Edge capacity — more concurrent slots per node reduce queueing delay and keep more traffic off the slow cloud path.
Processing time — faster local processing reduces both direct service time and the queueing penalty for requests behind it.
Request rate — higher load fills edge queues faster, pushing more traffic to the cloud and raising average latency.

Real-world relevance: this is the core trade-off behind CDN edge caches, 5G MEC (multi-access edge computing) and IoT gateways — process close to the user when you can, fall back to a centralized data center when local capacity runs out.

Edge-served request Cloud-served request Client device

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