This chapter covers the troubleshooting of latency and jitter, two critical performance metrics in modern networks. For the N10-009 exam, these concepts appear in roughly 10–15% of network troubleshooting questions, often in the context of voice and video quality issues. You will learn the precise definitions, measurement methods, common causes, and step-by-step troubleshooting approaches. Mastery of this topic is essential because latency and jitter directly impact user experience and are frequent sources of help desk tickets.
Jump to a section
Imagine a daily commute on a freeway between two cities. Latency is the average travel time from home to office—normally 30 minutes. But one day, a lane closure reduces capacity, and traffic backs up. The travel time stretches to 45 minutes. That's increased latency. Jitter is the variability in travel time: on a normal day, you might take 28–32 minutes; with the lane closure, some days you take 40 minutes, other days 50 minutes. The inconsistency is jitter. Now, think of a voice call as a convoy of cars leaving every 20 milliseconds. If the travel time is steady, the convoy arrives in order. But if jitter causes some cars to arrive early and others late, the convoy gets scrambled—the voice becomes choppy. To fix jitter, you install a buffer (like a holding lot) that collects the cars and releases them at a steady pace, but that adds delay (latency). The network engineer's job is to balance this trade-off: too little buffer causes packet loss; too much buffer adds unacceptable delay. This mirrors how jitter buffers in VoIP phones work: they trade latency for smooth playback.
What Are Latency and Jitter?
Latency, also called delay, is the time it takes for a packet to travel from source to destination. It is measured in milliseconds (ms). One-way delay is the time from sender to receiver; round-trip time (RTT) is the time for a packet to go and come back. For the N10-009 exam, you must know that latency is additive: propagation delay (distance/speed of light in fiber ~200,000 km/s), serialization delay (time to put bits on wire = packet size / link speed), processing delay (router/switch forwarding time), and queuing delay (time waiting in buffers) sum to total latency. Typical values: 1–10 ms on LAN, 20–100 ms on WAN, 150–300 ms on satellite links.
Jitter is the variation in latency over time. It is calculated as the difference in one-way delay between consecutive packets. For example, if packet A arrives in 10 ms and packet B in 12 ms, jitter is 2 ms. Jitter is more harmful than latency for real-time applications because it disrupts the timing of playback. The ITU-T G.114 standard recommends one-way latency below 150 ms for good voice quality, and jitter below 30 ms.
Why Do Latency and Jitter Matter?
Real-time applications like VoIP, video conferencing, and online gaming have strict latency and jitter requirements. VoIP typically needs one-way latency <150 ms and jitter <30 ms. Video conferencing (e.g., Zoom, Teams) requires similar or tighter bounds. Streaming video can tolerate higher latency but is sensitive to jitter causing buffer underruns or overflows. The exam tests your ability to identify when latency/jitter are problems and what tools to use.
Common Causes of Latency
Propagation delay: Physical distance. A 1000 km fiber link adds about 5 ms one-way (1000 km / 200,000 km/s = 0.005 s = 5 ms).
Serialization delay: Depends on packet size and link speed. A 1500-byte packet on a 1.544 Mbps T1 link takes (1500*8)/1,544,000 = 7.77 ms. On a 1 Gbps link, it takes 0.012 ms.
Processing delay: Router CPU time for forwarding. Usually microseconds, but can spike with ACLs or NAT.
Queuing delay: Packets waiting in interface output queues. This is the most variable and often the root cause of jitter.
Network congestion: High utilization causes queues to fill, increasing queuing delay.
Bufferbloat: Excessively large buffers in routers/switches increase latency even under moderate load.
Wireless links: Wi-Fi adds variable delay due to CSMA/CA, retransmissions, and interference.
Satellite links: High propagation delay (250–300 ms one-way due to geostationary orbit ~36,000 km).
Common Causes of Jitter
Variable queuing delay: The primary source of jitter. When traffic is bursty, queue depths fluctuate.
Route changes: Dynamic routing protocols (OSPF, EIGRP, BGP) can change the path, altering latency.
Wireless interference: Wi-Fi uses contention-based access; retransmissions cause delay spikes.
Traffic shaping/policing: Token bucket implementations can introduce delay variation.
Multipath routing: ECMP or LAG can cause packets to take different paths with different delays.
CPU overload: Slow processing of some packets due to high CPU utilization.
Troubleshooting Methodology
The CompTIA Network+ troubleshooting methodology applies. For latency/jitter: 1. Identify the symptom: Users report choppy voice, video freezes, or slow response. 2. Determine scope: Is it one user, one application, or the whole network? 3. Establish baseline: Measure normal latency/jitter during quiet times. 4. Implement a solution: E.g., QoS, jitter buffers, link upgrades. 5. Test and verify: Re-measure to confirm improvement. 6. Document findings.
Tools for Measuring Latency and Jitter
ping: Measures RTT. Use ping -n 100 <target> to get average, min, max. Jitter can be inferred from max-min variation, but not precise.
tracert/traceroute: Shows per-hop latency. Useful to locate where delay spikes occur.
iperf3: Generates UDP traffic and reports jitter. Command: iperf3 -c <server> -u -b 1M -t 30. The server output includes jitter (ms).
Wireshark: Capture traffic and analyze inter-arrival times. Use Statistics > Flow Graph or filter rtp to see jitter.
SNMP: Monitor interface utilization and queue depths.
PathPing: Combines ping and traceroute; calculates per-hop loss and latency.
VoIP quality tools: MOS (Mean Opinion Score) from 1 to 5; R-factor; both are derived from latency, jitter, and packet loss. The E-model (ITU-T G.107) computes R-factor.
QoS Mechanisms to Reduce Jitter and Latency
Classification and Marking: Use DSCP (DiffServ) to mark traffic. Voice typically uses EF (46), video AF41 (34), and data best-effort (0).
Policing and Shaping: Policing drops packets exceeding a rate; shaping buffers them, which adds jitter. For real-time traffic, policing is preferred.
Queuing: Priority Queuing (PQ) gives strict priority to voice but can starve other traffic. Low Latency Queuing (LLQ) is recommended: it uses a priority queue with a policer to prevent starvation.
Congestion Avoidance: WRED (Weighted Random Early Detection) drops packets before queues fill, but it can cause jitter if applied to real-time traffic. Avoid WRED for EF.
Link Fragmentation and Interleaving (LFI): On low-speed links (<768 kbps), fragment large packets and interleave small voice packets to reduce serialization delay.
Compression: cRTP (Compressed RTP) reduces header overhead from 40 bytes to 2–4 bytes, lowering bandwidth usage and serialization delay.
Jitter Buffers
A jitter buffer is a memory buffer at the receiver that stores incoming packets and plays them out at a steady rate. There are two types: - Fixed jitter buffer: Has a constant size (e.g., 50 ms). Simple but adds fixed latency. If jitter exceeds buffer, packets are dropped. - Adaptive jitter buffer: Dynamically adjusts size based on measured jitter. Common in VoIP phones. Trade-off: larger buffer increases latency but reduces packet loss.
Exam-Specific Numbers and Standards
ITU-T G.114: One-way latency <150 ms good, 150–400 ms acceptable, >400 ms unacceptable.
Jitter <30 ms for VoIP.
Packet loss <1% for VoIP, <0.1% for toll-quality.
MOS >4.0 good, 3.5–4.0 acceptable, <3.5 poor.
R-factor >80 good, 70–80 acceptable, <70 poor.
Ethernet MTU 1500 bytes; serialization delay formula: (packet size in bits) / (link speed in bps).
Common Misconfigurations
Bufferbloat: Modern routers have large buffers (e.g., 1000+ packets). Under load, queuing delay can reach hundreds of ms. Solution: limit queue sizes or use active queue management like CoDel or FQ-CoDel.
QoS misconfiguration: Marking voice as Best Effort or not enabling LLQ on WAN interfaces.
Incorrect jitter buffer size: Too small causes packet loss; too large causes echo or talk-over.
Speed/duplex mismatch: Causes collisions and retransmissions, increasing jitter.
Half-duplex links: Collisions cause variable delay. Always use full-duplex.
Step-by-Step Troubleshooting Process
Verify the symptom: Use ping to check RTT and loss to the destination. High loss indicates congestion or errors.
Isolate the hop: Use tracert to see where latency spikes. Look for hops with >10 ms increase.
Check interface utilization: Use show interfaces or SNMP. High utilization (>70%) suggests congestion.
Examine queue drops: show interface <int> | include queue|drop. Output drops indicate congestion.
Check QoS configuration: show policy-map interface <int>. Verify voice traffic is marked EF and placed in priority queue.
Measure jitter: Use iperf3 -u between endpoints. Jitter >30 ms is problematic.
Adjust jitter buffer: On VoIP endpoints, increase buffer size if packet loss is high; decrease if latency is high.
Update firmware/drivers: Especially for NICs and VoIP phones.
Check for bufferbloat: Use ping during download; if latency spikes significantly, bufferbloat is present. Implement AQM.
Verify physical layer: Check cable quality, distance, and interference for wireless.
Interaction with Other Technologies
NAT: Adds processing delay; can cause jitter if CPU is overloaded.
VPN: Encryption adds processing delay; IPsec can increase jitter if multiple SA negotiations occur.
Load balancing: ECMP can cause out-of-order packets, increasing jitter.
Wireless: CSMA/CA, retransmissions, and beacon intervals add variable delay. Use WMM (Wi-Fi Multimedia) to prioritize voice.
MPLS: Label switching reduces processing delay but can introduce jitter if TE tunnels are used.
SD-WAN: Can steer traffic based on latency/jitter measurements, but adds overhead.
Advanced Concepts
One-way delay measurement: Requires clock synchronization (NTP). Tools like OWAMP (One-Way Active Measurement Protocol) are used.
RFC 3550: RTP includes a timestamp and sequence number for jitter calculation. The formula: jitter = (|D(i-1,i)| + ...) / (number of packets).
Active vs. passive measurement: Active (iperf, ping) injects traffic; passive (NetFlow, sFlow) observes existing traffic.
SLA monitoring: IP SLA on Cisco devices sends probes to measure latency, jitter, and packet loss. Configuration example:
ip sla 1
udp-jitter 192.168.1.1 16384 codec g711alaw
frequency 60
ip sla schedule 1 life forever start-time nowY.1731: For Ethernet OAM, measures frame delay and delay variation.
Common Pitfalls on the Exam
Confusing latency and jitter: latency is average delay; jitter is variation.
Thinking jitter is always caused by bandwidth; actually queuing delay variation is the main cause.
Forgetting that serialization delay matters on slow links.
Assuming QoS eliminates jitter; it only reduces it. Jitter buffers are still needed.
Overlooking the impact of bufferbloat on latency.
Summary of Key Commands
ping -n 100 <target>: Measure RTT and packet loss.
tracert <target>: Per-hop latency.
iperf3 -c <server> -u -b 1M: Measure jitter.
show interfaces <int>: Check utilization, errors, drops.
show policy-map interface <int>: Verify QoS.
show ip sla statistics: View IP SLA results.
Identify the symptom and scope
Begin by confirming the user's complaint. For example, 'Voice calls are choppy' or 'Video freezes every few seconds'. Determine if the issue affects one user, a group, or the entire network. Use a structured interview: ask when it started, what changed, and whether it happens with specific applications. For the exam, you must differentiate between latency (delayed response) and jitter (uneven flow). A simple test: a VoIP call with high latency but low jitter sounds like a satellite call (delay but clear); high jitter causes robotic or choppy audio.
Establish a baseline with ping
Use ping to measure round-trip time (RTT) to the destination. Run at least 100 pings to get average, min, max, and packet loss. For example: `ping -n 100 192.168.1.1`. If average RTT is >150 ms, latency is an issue. If max-min >30 ms, jitter is likely. However, ping measures RTT, not one-way delay, and includes both directions. For jitter, ping is only an indicator; use iperf3 for precise measurement. Note: ping may be blocked by firewalls; use a tool that can send UDP probes.
Isolate the problematic hop with traceroute
Run traceroute (tracert on Windows, traceroute on Linux) to the destination. Look for hops where latency jumps significantly (e.g., from 5 ms to 100 ms). This identifies the router or link causing delay. Also note if some hops show asterisks (* * *), indicating no response (possibly due to ICMP filtering). On the exam, remember that traceroute sends packets with increasing TTL and measures RTT per hop. If a later hop shows lower latency than an earlier hop, that's normal because the earlier hop's response time includes its own processing.
Check interface utilization and errors
Use `show interfaces` on the suspected router/switch. Look for high output queue drops, CRC errors, or collisions. For example: `show interfaces GigabitEthernet0/1`. Key fields: 'output queue drops' indicates congestion; 'input errors' may indicate physical issues. Also check utilization: if >70% for extended periods, queuing delay increases. For wireless, check channel utilization and retransmission rates. Use SNMP to collect historical data if possible.
Measure jitter with iperf3
Run iperf3 in UDP mode between two endpoints. On the server: `iperf3 -s`. On the client: `iperf3 -c <server> -u -b 1M -t 30`. The server output includes jitter (ms) and packet loss. For voice, use a bandwidth of 64-128 kbps (G.711 codec). For video, use 1-4 Mbps. If jitter >30 ms, the network is problematic. Also note the number of out-of-order packets; that indicates jitter or multipath. iperf3 is a key tool for the exam—know the syntax.
Verify QoS configuration
On routers and switches along the path, check that QoS is properly configured. Use `show policy-map interface <int>` to see which classes are matching traffic and what actions are taken. Verify that voice traffic (DSCP EF) is placed in a priority queue. If the priority queue is dropping packets, the policer may be too low. Also check that marking is consistent end-to-end. Misconfigured QoS is a common exam scenario: e.g., voice marked as best effort or not classified at all.
Adjust jitter buffer and retest
On VoIP endpoints, adjust the jitter buffer size. For example, in Cisco IP phones, you can set the jitter buffer from 20 ms to 150 ms via the web interface or CLI. Start with a moderate size (e.g., 50 ms) and test. If packet loss decreases but latency increases, find a balance. If jitter is high (e.g., >50 ms), a larger buffer is needed. After adjustment, rerun iperf3 and verify improvement. Document the final buffer size.
Enterprise VoIP Deployment
A multinational company deploys Cisco IP phones across 50 sites connected via MPLS WAN. Users in the Asia-Pacific region complain of choppy audio during calls to Europe. The network team uses IP SLA with UDP jitter probes to measure one-way delay and jitter. They discover that the average latency is 180 ms (exceeding G.114's 150 ms threshold) and jitter spikes to 40 ms during peak hours. The root cause is a congested WAN link at the Singapore hub. Solution: They implement LLQ on all WAN interfaces, marking voice as EF (DSCP 46) and giving it strict priority with a policer of 1 Mbps per site. They also increase the jitter buffer on the IP phones from 40 ms to 80 ms. After changes, latency remains at 180 ms (due to distance), but jitter drops to 15 ms, and call quality improves to MOS 3.8.
Video Conferencing in a Campus Network
A university deploys Zoom rooms across campus. During class hours, video freezes intermittently. The network team uses Wireshark to capture traffic between the Zoom client and server. They filter for RTP packets and analyze inter-arrival times. The jitter calculation in Wireshark shows values up to 60 ms. They trace the path and find a 100 Mbps switch port operating at half-duplex due to a misconfigured auto-negotiation. This causes collisions and retransmissions, introducing jitter. Fix: Set the port to full-duplex manually. After the fix, jitter drops to 5 ms. The team also enables WMM (Wi-Fi Multimedia) on the access points to prioritize video traffic.
Cloud-Based UCaaS
A company uses Microsoft Teams for voice. Remote workers report one-way audio delays. The help desk runs ping -t to the Teams edge server and sees RTT of 250 ms. Traceroute shows the traffic traverses a VPN concentrator that adds 50 ms processing delay. The VPN is using software encryption on a low-end router. Solution: Upgrade to a hardware VPN accelerator or move to a direct internet breakout for Teams traffic using SD-WAN. After implementing direct internet access (DIA) for Office 365 traffic, latency drops to 30 ms, and jitter is negligible. The key lesson: VPNs can introduce significant latency and jitter, especially when CPU-bound.
What N10-009 Tests
Objective 5.3: 'Given a scenario, troubleshoot common network issues.' Latency and jitter are specifically listed under 'Performance issues'. The exam expects you to identify symptoms, use appropriate tools (ping, traceroute, iperf, Wireshark), and apply fixes (QoS, jitter buffers, link upgrades). Common scenario questions: 'A user reports choppy VoIP calls. Which tool should you use to measure jitter?' Answer: iperf3. Or 'Which QoS mechanism reduces jitter?' Answer: LLQ.
Common Wrong Answers
'Use ping to measure jitter' – Ping measures RTT, not jitter. Jitter requires inter-arrival time variation, which ping does not directly provide. iperf3 is the correct tool.
'Increase bandwidth to reduce jitter' – Bandwidth alone does not reduce jitter; it reduces queuing delay only if congestion is the cause. Jitter is about variation, not average delay.
'Jitter is caused by long propagation delay' – Propagation delay adds constant latency, not variation. Jitter is caused by variable queuing delay, route changes, or wireless interference.
'QoS eliminates jitter completely' – QoS reduces jitter by prioritizing traffic, but it cannot eliminate it due to remaining variable delays. Jitter buffers are still needed.
'Latency and jitter are the same thing' – This is a fundamental distinction. Latency is the time delay; jitter is the variation in delay.
Specific Numbers to Memorize
G.114: <150 ms one-way latency good, 150-400 ms acceptable, >400 ms unacceptable.
Jitter threshold: <30 ms for VoIP.
Packet loss: <1% for VoIP, <0.1% for toll-quality.
MOS: >4.0 good, 3.5-4.0 acceptable, <3.5 poor.
R-factor: >80 good, 70-80 acceptable, <70 poor.
Serialization delay formula: (packet size in bits) / (link speed in bps).
Default jitter buffer size: typically 20-50 ms.
Edge Cases and Exceptions
Satellite links: High latency (250-300 ms) is normal; jitter is usually low. Troubleshooting focuses on jitter buffers and codec selection (use G.729 to save bandwidth).
Bufferbloat: Even on high-bandwidth links, large buffers can cause high latency under load. Use CoDel or FQ-CoDel to mitigate.
Wireless: Jitter can spike due to interference or retransmissions. Use WMM and ensure clean channels.
VPN: Encryption adds processing delay; use hardware acceleration or split tunneling for real-time traffic.
MPLS TE: Traffic engineering tunnels can introduce jitter if not properly configured with priority.
How to Eliminate Wrong Answers
If a question asks about measuring jitter, eliminate any answer that mentions ping or traceroute alone. Look for iperf3, Wireshark RTP analysis, or IP SLA with UDP jitter. If a question asks about reducing jitter, eliminate answers that only increase bandwidth or change propagation delay. Look for QoS (LLQ), jitter buffers, or fixing duplex mismatches. Always consider the underlying mechanism: jitter is variation in delay, so the solution must address the source of variation (e.g., queuing, route flapping, wireless retransmissions).
Latency is the time delay (ms); jitter is the variation in delay (ms).
ITU-T G.114: one-way latency <150 ms good, 150-400 ms acceptable, >400 ms unacceptable.
VoIP jitter must be <30 ms; packet loss <1%.
Use iperf3 -u to measure jitter accurately; ping only measures RTT.
LLQ (Low Latency Queuing) is the recommended QoS mechanism for real-time traffic.
Jitter buffers trade latency for reduced packet loss; adaptive buffers are preferred.
Bufferbloat (excessive buffers) increases latency; use CoDel or FQ-CoDel to mitigate.
Wireless links introduce jitter due to CSMA/CA and retransmissions; use WMM.
Half-duplex links cause collisions and jitter; always use full-duplex.
VPNs add processing delay and can increase jitter; use hardware acceleration or split tunneling.
These come up on the exam all the time. Here's how to tell them apart.
Fixed Jitter Buffer
Constant size (e.g., 50 ms) regardless of network conditions.
Simple to implement and predictable latency.
If actual jitter exceeds buffer size, packets are dropped.
Adds fixed latency equal to buffer size.
Suitable for networks with stable jitter.
Adaptive Jitter Buffer
Dynamically adjusts size based on measured jitter.
More complex but adapts to changing conditions.
Reduces packet loss by increasing buffer when jitter spikes.
Latency varies but is optimized for current jitter.
Preferred for networks with variable jitter (e.g., internet).
Mistake
Latency and jitter are the same thing.
Correct
Latency is the average time delay; jitter is the variation in delay over time. They are measured differently and have different impacts on applications.
Mistake
Ping measures jitter directly.
Correct
Ping measures round-trip time (RTT). While you can infer jitter from the min-max variation, it is not precise. Use iperf3 or Wireshark for accurate jitter measurement.
Mistake
Increasing bandwidth always reduces jitter.
Correct
Bandwidth reduces queuing delay only if congestion is the cause. Jitter is about variation; even on high-bandwidth links, bursty traffic can cause jitter. QoS and jitter buffers are more effective.
Mistake
QoS eliminates jitter completely.
Correct
QoS reduces jitter by prioritizing real-time traffic, but it cannot eliminate it. Residual jitter from route changes, wireless interference, or processing delays still exists. Jitter buffers are necessary.
Mistake
Jitter is only a problem for voice traffic.
Correct
Jitter affects any real-time application, including video conferencing, online gaming, and streaming. It can also cause TCP performance issues due to spurious retransmissions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Latency is the time it takes for a packet to travel from source to destination, measured in milliseconds. Jitter is the variation in that delay over time. For example, if three packets arrive at 10 ms, 12 ms, and 11 ms, the jitter is the average deviation from the mean. Latency affects responsiveness; jitter affects the smoothness of real-time streams. On the exam, remember that latency is constant delay, jitter is variable delay.
Use iperf3 in UDP mode. On the server, run `iperf3 -s`. On the client, run `iperf3 -c <server> -u -b 1M -t 30`. The server output includes jitter in milliseconds. Alternatively, use Wireshark to capture RTP traffic and view the inter-arrival time statistics. IP SLA with UDP jitter probes is another option on Cisco devices. Do not rely on ping alone.
For good voice quality, jitter should be below 30 ms. Between 30 ms and 50 ms, voice quality degrades. Above 50 ms, calls become choppy. The ITU-T G.114 standard recommends one-way latency below 150 ms and jitter below 30 ms. Packet loss should be less than 1%.
A jitter buffer at the receiver stores incoming packets and plays them out at a steady rate. It absorbs delay variations. A fixed buffer adds constant delay (e.g., 50 ms) regardless of jitter. An adaptive buffer dynamically changes size based on measured jitter, trading latency for packet loss. For example, if jitter spikes to 60 ms, the adaptive buffer increases to 70 ms to avoid dropping packets, but adds 70 ms delay.
Bufferbloat is the presence of excessively large buffers in network devices. Under load, these buffers fill up, causing queuing delay to increase dramatically (e.g., from 5 ms to 500 ms). This increases latency and jitter. Bufferbloat is common in consumer routers. Solutions include limiting queue sizes or using Active Queue Management (AQM) algorithms like CoDel or FQ-CoDel.
No, QoS reduces jitter but cannot eliminate it. By prioritizing real-time traffic (e.g., using LLQ), QoS ensures that voice packets are dequeued first, minimizing queuing delay variation. However, jitter from other sources (route changes, wireless interference, processing delays) remains. A jitter buffer is still required to smooth out residual jitter.
Common tools: ping (RTT), traceroute (per-hop latency), iperf3 (throughput and jitter), Wireshark (packet analysis), and IP SLA (Cisco). For example, if ping shows high RTT, use traceroute to find the slow hop. Then check interface utilization and errors on that hop. If utilization is high, implement QoS or upgrade the link.
You've just covered Latency and Jitter Troubleshooting — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?