Network jitter is the variation in packet delay: two packets sent the same way arrive after different amounts of time. A load test cannot measure it directly, because a load generator records HTTP response times, not individual packets. What a test shows is the spread of those response times, which mixes network variation with server queueing. To tell them apart, measure jitter separately with ping or iperf, run the same test from more than one region, and compare.
Key Takeaways
- Jitter is delay variation, not delay. A steady 120 ms path has no jitter; a path that alternates between 20 ms and 40 ms does.
- A load test sees jitter only as wider response time percentiles. It cannot attribute that width to the network or the server on its own.
- Measure jitter next to the test with ping or iperf, from each generator location, and record it with the results.
- Do not filter jitter out. Your users have it too. Report it so the spread in the results can be explained.
What is network jitter?
Network jitter is the variation in delay between packets of the same stream. If every packet takes 40 ms, jitter is zero. If packets take 20, 24, 19, 31 and 22 ms, the delay averages about 23 ms but it keeps moving, and that movement is the jitter.
The standards define it precisely, and the definitions differ in a useful way:
- RFC 4689 (benchmarking terminology for network devices) defines jitter as the absolute value of the difference between the forwarding delay of two consecutive received packets of the same stream.
- RFC 3550 (RTP) defines interarrival jitter as a running estimate of the mean deviation of the difference in packet spacing: for packets i and j, D(i,j) = (Rj - Ri) - (Sj - Si), where R is the arrival time and S is the send timestamp, and the estimate is updated as J = J + (|D| - J) / 16. The 1/16 factor smooths the value, so a single late packet barely moves it.
Take the five delays above. The differences between consecutive packets are 4, 5, 12 and 9 ms, so the RFC 4689 style average is 7.5 ms. The RFC 3550 estimate after those same four differences is only about 1.7 ms, because the smoothing needs many packets to converge. Both are valid; they answer slightly different questions, so say which one a tool reports before comparing numbers.
One practical detail: D compares the spacing of arrivals with the spacing of sends, so a constant clock offset between sender and receiver cancels out. That is why jitter can be estimated without synchronised clocks, while one-way delay cannot.
How is jitter different from latency and packet loss?
Latency is how long a packet takes. Jitter is how much that time changes from packet to packet. Packet loss is how many packets never arrive. A satellite link can have high latency and low jitter. A congested Wi-Fi hop can have low average latency and high jitter. The three are independent enough that you need to look at each one.
| Measure | What it describes | How you usually see it |
|---|---|---|
| Latency | Time for a packet to travel one way or round trip | Round-trip time from ping, time to first byte from a load test |
| Jitter | Change in that time between packets | ping standard deviation, iperf UDP jitter, RTP receiver reports |
| Packet loss | Share of packets that do not arrive | ping loss percentage, iperf UDP lost datagrams, TCP retransmissions |
For the latency half of the picture, including how distance and new connections add to every measurement, see the post on network latency and load testing accuracy. This post does not repeat it.
Can a load test measure jitter?
Not directly. A load generator sends HTTP requests over TCP and records how long each response took. TCP hides the packet-level behaviour: a late packet or a retransmission shows up as a slower request, not as a jitter figure. So a load test reports the effect of jitter, not jitter itself.
What you can read from a test:
- The spread of response times. Compare the median with the 95th and 99th percentiles, and look at the standard deviation. A wide gap on a light load, when the server is idle, points at the path or at something outside your code. See why percentiles beat averages and standard deviation in performance testing.
- Differences between regions. The same endpoint tested from two regions at the same time should show a similar spread if the cause is the server. If one region is wider, the path to it is the likelier cause.
- Differences between runs at different times. Repeating a test at another hour and getting a different spread also points at the network, because your server did not change.
What you cannot read from a test: how much of a given spike was the network and how much was the server queueing requests. To separate them, measure the network on its own.
How do I measure network jitter?
Run a jitter test from the same place the load generator runs, to the same target, at the same time as the test. Three common tools:
- ping. It sends ICMP echo requests and prints the round-trip times and a summary with minimum, average, maximum and a standard deviation (called mdev on Linux iputils, stddev on macOS). That standard deviation is a round-trip figure and is not the RFC 3550 value, but it is a quick, comparable measure of variation.
ping -c 100 example.comgives 100 samples. - iperf in UDP mode. The iperf server reports jitter and lost datagrams for a UDP stream, using the smoothed mean of the differences between consecutive transit times (the iperf documentation describes it this way, and notes the two clocks need not be synchronised). It needs an iperf server on the far end, so it suits paths you control, such as generator to your own staging environment.
- mtr or traceroute. They show per-hop delay and loss, which helps find which hop is the unstable one once ping shows that something is.
Take samples at several times of day, because public paths are busier at some hours. Keep the raw numbers and the time, location and target with your test notes. LoadFocus lets you add notes to a load test result, which is a good place for them.
What jitter value is acceptable?
There is no universal threshold, and claims such as “above 30 ms ruins your latency measurements” do not come from a standard. What is acceptable depends on what the application does with the delay. Voice and video use a jitter buffer, so jitter in the tens of milliseconds matters because the buffer has to absorb it. A web page or an API call cares about the total time to complete a request, so what matters is whether the 95th and 99th percentiles stay inside your target.
A workable approach: record the jitter you measure on each path, run the test, and ask whether the spread in your response times is larger than the network alone would explain. If a path with 5 ms of jitter produces a response time spread of 800 ms, look at the server. If a path with 80 ms of jitter and an idle server produces a 150 ms spread, the network is the likelier cause.
Should I simulate jitter in a load test?
Only for a specific question, such as how a checkout behaves for users on a poor mobile connection. For ordinary capacity testing, the real path between your generators and the target already contains real jitter, and adding more makes results harder to read.
If you do want to add it, do it at the network layer, not in the test script. On Linux, tc with netem can add a fixed delay with a random variation, for example tc qdisc add dev eth0 root netem delay 100ms 10ms distribution normal (see the netem man page, and the example in the latency post). Apply it to the generator or a proxy in front of the target, never to a production host.
A common mistake is to use JMeter’s Gaussian Random Timer or Uniform Random Timer for this. Those timers add a random pause between requests. That models how long users think, not how the network behaves, and it changes the request rate. k6 has no built-in network emulation either; its sleep() is also a pause between iterations. Browser-based tools such as Chrome DevTools can throttle a single page load, which is a different job from load testing.
How do I run multi-location tests to separate the network from the server?
Run the same script, at the same time and at the same load, from at least two regions: one close to the server and one far away. Then compare the median and the 95th percentile for each.
- Both regions show the same widening as load grows: the server is the likelier cause.
- Only the far region is wide, and the near one is stable: the path is the likelier cause.
- Both are wide only at certain hours: something shared on the network, or a noisy neighbour.
LoadFocus runs load tests from 25 cloud regions and reports response time, latency, standard deviation and the 50th, 90th and 99th percentiles per test (loadfocus.com/load-testing, October 2026), so this comparison is possible with a single product. Its page does not describe measuring packet jitter or emulating network conditions, so use ping or iperf for that part. The posts on multi-region deployment and load testing and edge locations cover choosing the regions.
What are the common mistakes when dealing with jitter?
- Filtering outliers until the result looks tidy. The spread is real for users on the same path. Report it, with the jitter you measured, rather than deleting it.
- Measuring once. One ping run at midnight says little about the afternoon peak.
- Measuring from the wrong place. Jitter from your laptop to the server is not jitter from the load generator to the server.
- Reading a spike as a code regression without checking the path. Repeat the test and compare regions before opening a ticket.
- Comparing two numbers from different definitions. A ping standard deviation, an iperf figure and an RFC 4689 mean of differences are not interchangeable.
Frequently Asked Questions
How does network jitter affect cloud load testing results?
Jitter widens the spread of response times: the median may stay the same while the 95th and 99th percentiles move. A load test cannot tell you how much of that came from the network. Measure the path separately and compare regions to find out.
Should I remove jitter from my load tests?
No. Real users experience it. Remove only the jitter you can avoid, for example by running generators close to the server for a capacity test, and report the measured jitter next to the results so readers can interpret the spread.
How do I tell whether a latency spike is jitter or my application?
Repeat the test at a different time and from a second region. A spike that follows the server across regions and times is likely the application. A spike that appears in one region or one time window is more likely the network. Confirm with ping or mtr from the same generator.
Does jitter affect all applications equally?
No. Real-time voice, video and gaming are the most sensitive, because they need packets to arrive at a steady pace. Web pages and APIs mostly care about the total time to complete a request, so jitter matters through the tail of the response time distribution.
How do I document jitter findings?
Record the date and time, the generator location, the target, the tool and which definition it reports, and the numbers, and keep them with the test result. A note on the result in LoadFocus is enough for most teams.
Sources
- RFC 4689, Terminology for Benchmarking Network-layer Traffic Control Mechanisms, section 3.2.5 (rfc-editor.org, read October 2026).
- RFC 3550, RTP: A Transport Protocol for Real-Time Applications, section 6.4.1 and appendix A.8, interarrival jitter (rfc-editor.org).
- iperf documentation, UDP jitter and datagram loss (iperf.fr/iperf-doc.php, read October 2026).
- Linux tc-netem manual (man7.org/linux/man-pages/man8/tc-netem.8.html).
- LoadFocus load testing page (loadfocus.com/load-testing, October 2026).
