Humans perceive latency in three tiers. Under 100ms feels instantaneous — the system responds before you consciously register the delay. 100-300ms feels responsive. Over 500ms feels like lag. In consumer apps, the difference is frustration. In industrial environments, it's a safety issue.
At 200 RPM spindle speed, a 500ms sensor-to-dashboard delay means the machine has rotated 1.6 times before the operator sees an alarm. At 1000 RPM, it's 8.3 rotations. By the time the alert fires, the damage is done. We target 14ms — one frame at 60fps — because human reaction time (250ms) should be the bottleneck, not the technology.
The Edge Advantage
// Interactive: Latency Simulator
Edge processing path: sensor (2ms) → ESP32 (4ms) → MQTT (4ms) → WebSocket (4ms) → React (2ms) = 14ms total
Cloud round-trip path: sensor → 4G → API → DB → WebSocket → browser = 200–800ms
By moving detection logic from cloud to edge (the microcontroller itself), we eliminate the entire round-trip: sensor → ESP32 → cloud API → database → WebSocket → browser. That path takes 200-800ms over a typical 4G connection. Edge processing compresses it to 8-20ms — the time it takes to run the anomaly calculation on-chip.
What 14ms Actually Means
14ms is our measured end-to-end latency from sensor threshold breach to dashboard alert for systems on a stable local network. It's not a marketing number. It's the result of: edge detection (2ms), local MQTT publish (4ms), WebSocket push (6ms), React state update (2ms). Each number has a measurement to back it.