We have a tendency in the industry to oversimplify technical issues. We take a speed test and assume the answer that pops out is our speed. Those same speed tests also measure latency, and even network engineers sometimes get mentally lazy and are satisfied to see an expected latency number on a network test. But in reality, the broadband signal coming into your home is incredibly erratic. From millisecond to millisecond, the amount of data hitting your home network varies widely. Measuring jitter means measuring the degree of network chaos.
Jitter increases when networks get overwhelmed, even temporarily. Delays are caused in any network when the amount of data being delivered exceeds what can be accepted. There are a few common causes of increased jitter:
· Not Enough Bandwidth. Low bandwidth connections experience increased jitter when incoming packets exceed the capacity of the broadband connection. This effect can cascade and multiply when the network is overwhelmed – being overly busy increases jitter, and the worse jitter then makes it even harder to receive incoming packets.
· Hardware Limitations. Networks can bog down when outdated routers, switches, or modems can’t fully handle the volume of packets. Even issues like old or faulty cabling can cause delays and increase jitter.
· Network Handoffs. Any network bottlenecks are the most vulnerable point in the network. The most common bottleneck in all of our homes is the device that converts landline broadband into WiFi. Even a slight hiccup at a bottleneck will negatively impact performance in the entire network.
All of these factors help to explain why old technology like DSL performs even worse than might be expected. Consider a home that has a 15 Mbps download connection on DSL. If an ISP were to instead deliver a 15 Mbps connection on fiber, the same customer would see a significant improvement. A fiber connection would avoid the jitter issues caused by antiquated DSL hardware. We tend to focus on speeds, but a 100 Mbps connection on a fiber network will typically have a lot less jitter than a 100 Mbps connection on a cable company network. Customers who try a fiber connection for the first time commonly say that the network ‘feels’ faster – what they are noticing is the reduced jitter.
Jitter can be deadliest to real-time connections – most people aren’t concerned about jitter if means it takes a little longer to download a file. But increased jitter can play havoc with an important Zoom call or with maintaining a TV signal during a big sports event. It’s easiest to notice jitter when a real-time function hesitates or fails. Your home might have plenty of download bandwidth, and yet broadband connections still fail because small problems caused by jitter can accumulate to make the connection fail.
ISPs have techniques that can help to control jitter. One of the more interesting ones is to use a jitter buffer that grabs and holds data packets that arrive too quickly. It may not feel intuitive that slowing a network can improve quality. But recall that jitter is caused when there is a time delay between different packets in the same transmission. There is no way to make the slowest packets arrive any sooner – so slowing down the fastest ones increases the chance that Zoom call packets can be delivered evenly.
Fully understanding the causes of jitter in any specific network is a challenge because the causes can be subtle. It’s often hard to pinpoint a jitter problem because it can be here one millisecond and gone the next. But it’s something we should be discussing more. A lot of the complaints people have about their broadband connection are caused by too-high jitter.
4 replies on “Jitter – A Measure of Broadband Quality”
Great article, Doug. I have not seen jitter defined and explained so succinctly. Appreciate your work!
Sometimes too much buffering, instead of just dropping a packet can cause TCP jitter massively increase ie. buffer bloat.
When I worked for a cell phone company, I designed a test system to look at the jitter, latency, up and download speeds and connection establishment times at about 45 different cell sites. Each site got tested every couple of minutes to places within the company network and also to multiple places “around the internet”. Each morning the prior day’s results were presented in graphic form. Each week, the prior week’s data was similarly presented.
The results were often “eye opening” and ended up being used to hunt down problems. With the diversity of test “targets” it was possible to figure out where (what company) was the cause of the problem.
Interesting article, Doug. Would you say it’s fair to label Starlink and/or cellular hotspots “jittery” from the perspective of a person using them as their primary home broadband connection? I watched a YouTube video done by Linus Tech Tips reviewing Starlink, and while the speed test and latency numbers were good, they did encounter the odd slowdown that they found difficult to quantify (according to them, more noticeable on a webpage when it’s loading a large number of small independent requests, like thumbnails).
It also reminds me of running DSLReports’ “SmokePing” tool on my home internet connection decades ago. It was (is?) a tool that would ping your home IP repeatedly, from multiple geolocations over the course of a full day, and give you a graph at the end of any latency spikes or packet loss that hint at a “jittery” connection.
In the programming world we sometimes also add jitter to help fix certain network problems. For instance, if I’m trying to connect to a service (say, a website’s API), and that service is down, a classic algorithm to use to wait before retrying is exponential backoff (wait 1 second then retry, then wait 2 seconds, then 4, then 8…). However, if you have thousands of processes running and they’re all encountering this issue, what you’ve set up is thousands of processes all hitting this downed service at roughly the same times like a big hammer, increasing the burden on this downed service to start back up again (this is called the “thundering herd problem”). The fix is to add an extra bit of random delay – jitter – to every process’s retry wait time, so in aggregate the retries are spread out and the downed service isn’t being hit so hard, giving it a better chance at restarting under reduced load.
Jitter is specific to networks and not to technology. A perfectly designed network of any kind that is not overloaded with customers can have decent jitter. But there are many ways a network can be designed in a way to create bottlenecks and other causes of increased jitter.