Add latency and jitter to an app
Everything works on a fast local connection. Give the app 300 ms of ping and you find out which screens were written as if the answer arrives instantly.
Three different things
| Setting | What it does | Where it comes from in real life |
|---|---|---|
| Latency | Adds the same delay to every packet, in milliseconds. | Distance. A server on another continent, or a satellite. |
| Jitter | Adds a random amount on top, so the delay keeps changing. | Shared WiFi, mobile networks, anything congested. |
| Spikes | Occasional long stalls, set by how often and how long. | A handover between cell towers, a router under load. |
All three are in milliseconds and can run together. Both delay figures accept anything from 0 up, so you can go from a believable 40 ms to an absurd 60 seconds.
From the command line
A steady 200 ms with 80 ms of jitter, on one application:
BeanNetworkTester.exe --latency 200 --jitter 80 --target myapp.exe --duration 60Rare, long stalls instead - roughly one packet in twenty waits an extra second:
BeanNetworkTester.exe --spike-prob 5 --spike-ms 1000 --target myapp.exeNumbers worth trying
- 40 ms - a server in the same country. Nothing should change.
- 150 ms - another continent. Anything chatty starts to feel slow, because each round trip costs.
- 600 ms and up - geostationary satellite or in-flight WiFi. This is where progress bars stall and retry logic finally runs.
The ready profiles carry measured figures: "Distant server (another continent)", "Satellite (low orbit)", "Satellite (geostationary)", "In-flight Wi-Fi", "LTE / 4G".
Measuring it: look at the worst case, not the average
Jitter barely moves an average, and it barely moves a median. A run with 30 ms of jitter and a run without it can report almost the same "typical" ping while feeling completely different.
Compare the 95th percentile against the median instead. The gap between them is the jitter, and that gap is what makes a voice call choppy or a game unplayable while the average still looks fine.