When you first learn about ‘jitter’, you might think it’s a resurgence of a 1940’s dance craze. Happy people dancing around is not what results from a network that has problems with jitter – unhappy users complaining about poor quality VoIP/UC and video sessions are the real-world result.
In a perfect world, packets transmitted every 10ms should arrive at their destination every 10ms so the listener has a perfect experience. This would equate to a jitter of 0ms because there is no variability in the received packets.
This “break”, and the discarded chocolates, all equates to missing audio and video information that the receiving codec can’t process.
Related Post: Intro to Voice Quality: Jitter
Jitter affects real-time protocols like VoIP and video by creating drop-outs, clipped words, and video artifacts. It ends up sounding the same as if there was packet loss, but there are no actual lost packets – just delayed ones that are too late to be used by the receiving codec.
In general, jitter should be below 30ms when received by the endpoint.
Most video and audio codecs can deal with a certain amount of jitter, and some are better at handling jitter than others. Devices contain jitter buffers that are used to reduce the effect of jitter. If jitter is higher than 30ms, then the codec in the receiving endpoint will have problems splicing the conversation back together to have the audio sound smooth to the listener. All of this re-assembly of the conversation has to be done in real time. As a result, a jitter buffer can only accomplish so much repair before it has to give up and discard a packet that arrived out of its time window.
When packets are sent over a network interface, it must put the packet into a queue to be transmitted. If the queue is empty (no other packets to be sent), then the packet can be immediately dispatched to the network.
Note: | If the interface is configured to run 10meg or 100meg half-duplex, then there is a chance for collisions to occur. This has the potential to add a few microseconds of delay, as the collision backoff algorithm will delay a random number of Ethernet timeslots. This delay is insignificant and won’t add to jitter or latency calculations, but may add to packet loss. For more information, check Wikipedia: Carrier-sense multiple access with collision detection. |
If there are other packets to be sent, then the queue may get very long and jitter will increase as the VoIP packets are stuck inside buffers. This is made worse if there are data packets, as they tend to be larger (1518 bytes) and will create more delay.
Note: | Jumbo frames may be configured on interfaces. These permit payloads of 9018 bytes and larger to be sent on links. This can further exacerbate jitter if there is a lot of jumbo data frames on links that are also configured for VoIP. For more information about Jumbo frames, check Wikipedia: Jumbo Frames. |
This “queueing delay possibility” will occur on every network interface involved along the path through the network. This means that there may be hundreds of interfaces involved in passing traffic for a VoIP/UC or video call, and each of them may be queuing other packets that will create a little bit of jitter for the conversation.
Note: | Jitter is exponentially worse on slower links that are congested. This is due to serialization delay of getting the data on the wire. Even if an interface has low utilization and is not dropping packets due to bandwidth limitations, it may still be causing problems for jitter. Increasing bandwidth will help improve this and reduce jitter. |
Jitter can also be caused by CPU limitations on network devices. If a network device is “CPU bound” and is not using hardware ASIC chips to route or switch packets, the CPU may become a stalling point, thus causing some packets to be slowed down on their way to the destination.
Preventative steps to avoid creating jitter in networks are:
Troubleshooting where jitter is coming from can be challenging due to the number of network interfaces and devices that need to be checked.
Troubleshooting Jitter can be a two-step process:
Notes: |
VPN tunnels will typically add latency and jitter to a conduit due to the encryption overhead that is typically performed on tunnels. Involved firewalls should have their CPU tracked to make sure they are not having problems with the encryption activities for the VPN tunnels. End station clients running VPN software might also create significant jitter if the CPU spikes due to other applications running at the same time. |
Since Jitter is a sporadic problem, you may not be able to find the source of the problem if you don’t have a historical perspective of the above information.
A little bit of jitter detected on a single router or switch may not be of much concern, but consideration should be given to its affect throughout the entire network. If a little bit of jitter is added during each step across the network, you may end up with some very large jitter swings (between 5ms and 50ms) at the remote end of the network.
Additionally, if you reduce jitter in the parts of the network that you control, it will help reduce the effect of jitter added in parts of the network that you do not control: SIP Trunks, and VPN tunnels.
Overall, jitter can be prevented if the right information is brought to bear about your network’s performance.
Interested in learning more? Download our VoIP troubleshooting white paper.r