Network Conditions Emulator
Interactive workbench for seeing how latency, jitter, packet loss, and bandwidth limits change IoT delivery behavior
Network Conditions Delivery Workbench
Send the same IoT message through different network conditions and watch how delay, jitter, loss, and bandwidth limits change delivery time. The default rural cellular case is intentionally imperfect so retries and payload cost are visible immediately.
What Changes
Latency shifts the whole exchange later, jitter makes timing uneven, packet loss forces retries, and low bandwidth makes large payloads take longer on the wire.
Why It Matters
A device that works on office Wi-Fi may fail on cellular, satellite, or LPWAN links unless payloads, retry timing, and protocol choices match the network.
Try First
Press Step through the rural cellular preset. Then switch Raw UDP and compare delivery speed against data loss.
Common Mistake
Do not treat bandwidth and latency as the same problem. A tiny message on a satellite link waits mostly for RTT; a large payload on LPWAN waits mostly for serialization.
Network Presets
Delivery Path
Message 1 is ready to leave the sensor.
Message Timeline
Each row is one message in the batch. Bar length shows time from send to delivery confirmation or final failure.
Learning Support
Latency
The slider is round-trip time (RTT). MQTT, HTTP, and CoAP confirmation paths depend on RTT because the sender waits for an acknowledgment or response.
Jitter
Jitter is delay variation. It does not always lose packets, but it makes timing less predictable and can trigger timeouts when retry timers are too tight.
Packet Loss
Loss means a packet or acknowledgment does not arrive. Reliable protocols can recover, but they pay with retries, duplicate traffic, and longer waits.
Quick Reference
Serialization Time
time_ms = bytes x 8 / bps x 1000. This is why a 4 KB payload can dominate on a narrow link even when RTT is modest.
MQTT QoS 1
Uses PUBACK and can retransmit. It gives at-least-once delivery, so applications must tolerate duplicates.
CoAP Confirmable
Adds reliability above UDP with CON and ACK messages. It is often lighter than HTTP for constrained IoT links.
HTTP POST
Usually rides on TCP and often TLS, so connection setup and headers can dominate small telemetry messages.
Raw UDP
Low overhead and low waiting time, but a lost packet is gone unless your application adds sequence numbers, acknowledgments, and retry logic.
Testing Link
Linux tc netem can inject delay, jitter, loss, and bandwidth limits in a lab before devices go to the field.
Guided Practice
1. Compare reliability
Use Rural cellular with MQTT QoS 1, then Raw UDP. Ask which is faster and which actually delivers every message.
2. Find the bottleneck
Set loss to 0%, then increase payload size on the LPWAN narrow preset. Notice when serialization, not packet loss, becomes the limiting factor.
3. Tune a test case
Build a CI network test with 500 ms RTT, 5% loss, and bursty behavior. The goal is to catch retry and buffering bugs before deployment.