What it is
Latency is the time a packet takes to get from one place to another. Most teams measure round-trip time because it is easy: ping, a TCP handshake, or an HTTP request gives you a number. A steady 40 ms round trip is usually fine for voice and remote desktop. A steady 150 ms is not, even if no packets are lost.
Jitter is the change in latency from one packet to the next. If packet A takes 30 ms and packet B takes 90 ms, the network has jitter even if the average looks good. Real-time traffic cares about jitter because the receiver has to decide when to play audio or draw video. A jitter buffer absorbs some variation, then it runs out or grows too large.
Packet loss means packets never arrive. They can be dropped by a full queue, a bad cable, a wireless retry limit, a policer, or a routing loop. TCP hides loss by retransmitting, so a file download may still finish while latency climbs. UDP does not hide it: a voice call drops syllables, and a video frame freezes. The three problems are related but you troubleshoot them in different places.
How it works
Every hop adds four kinds of delay: serialization (putting bits on the wire), propagation (distance through fiber or air), processing (routers and firewalls looking at headers), and queueing (waiting behind other packets). Queueing is the one you can usually control. A link that is busy in short bursts will show low average latency and high jitter, because some packets wait and some do not.
Jitter comes from uneven queueing, load-balanced paths, wireless retries, and devices that batch packets. It shows up on a graph as a wide spread around the average. Packet loss comes from queues that overflow, interfaces with errors, duplex mismatches, MTU problems, and policy that drops traffic. A clean interface counter should show no CRC errors, no runts, and no discards. Check both ends of a link, because a duplex mismatch often shows errors on one side only.
Measure with more than one tool. Ping and mtr show round-trip time and loss along a path. iperf3 in UDP mode can show jitter and loss under load. tcpdump or Wireshark can show retransmissions, out-of-order packets, and RTP stream behavior. For one-way delay you need synchronized clocks, often with PTP or NTP; many teams skip that and use round-trip time plus loss.
Then test under the conditions users see. Run a probe while the finance team closes the month, not only at idle. Compare wired and wireless from the same spot. Check the uplink, because home and branch uploads saturate first. If latency rises with load and stays high, look for bufferbloat and enable an active queue management scheme such as CoDel or fq_codel on the router.
Why it matters for a business
Real-time traffic has a deadline. Voice and video need packets to arrive close together and on time. A packet that arrives after the playout deadline is as useless as one that never arrived. Remote desktop and VDI feel the same: keystrokes and mouse moves queue behind screen updates when latency or jitter rises. Warehouse scanners, payment terminals, and VoIP handsets all fail in ways users describe as 'the network is slow'.
Business apps also suffer from latency because they make many round trips. A page load can involve DNS, TLS, authentication, API calls, and database queries. Add 80 ms to each round trip and the page feels broken even when throughput is fine. Packet loss makes it worse: TCP retransmits, shrinks its congestion window, and sometimes waits on a timeout. That is why a link with plenty of bandwidth can still be painful.
For operations and finance, the practical point is that one number is not enough. Track latency, jitter, and packet loss separately by site, by app, and by hour. Put them in the same view as ISP tickets and change records. When a vendor says the circuit is up, you can show whether it is usable for the workload. Service targets should name each measure, not just availability.
Common mistakes
Testing with ping alone. Ping measures small ICMP packets, and many networks treat ICMP differently from business traffic. A clean ping does not prove that a voice call or a TLS handshake is clean. Use ping and mtr as a first pass, then test the real protocol and packet size.
Looking only at averages. An average latency of 50 ms can hide spikes that ruin calls. Watch the maximum, the spread, and the loss rate over short windows. Jitter is a spread measure by design, so a single average hides it. Also check the direction: a branch may have good download and a saturated upload.
Adding bandwidth to fix loss. If queues overflow because the uplink is oversubscribed, more bandwidth can help. If the loss comes from a bad cable, a duplex mismatch, a Wi-Fi retry storm, or a policer, more bandwidth changes nothing. Check interface errors and queue drops before you buy a bigger circuit.
Marking all traffic as high priority. QoS only works when classes are limited and trusted. If every packet gets the voice queue, the queue is just another best-effort queue. Mark voice and video at the edge, police unwanted marks, and shape the uplink below the access rate so the provider queue does not build up ahead of yours.
How to get started
Start with a budget per app. Decide what round-trip time, jitter, and loss a call, a remote desktop session, and an ERP screen need. Write those targets down with the site and the hour. Then measure from where users sit, on the same Wi-Fi or cable, with the same VPN or proxy. A test from a data center tells you little about a bad conference room.
Build a simple baseline. Run ping and mtr to the app endpoint at idle and at peak. Run iperf3 in UDP mode across the path and watch jitter and loss while you increase load. Pull interface counters for errors, discards, and queue drops. On Wi-Fi, check retries, signal, channel width, and roaming events. Fix local problems first: cables, duplex, access point placement, and uplink shaping.
Then change the network in small steps. Classify traffic, mark voice and video with DSCP, give those classes a priority queue, and enable active queue management on the WAN edge. If the app is internal, look at round trips too: connection pooling, regional endpoints, fewer redirects, and retry logic with backoff and jitter can beat a circuit upgrade. Keep a before and after trace so you know what worked.
Set ongoing monitoring. Use synthetic probes from each site to each critical app, and alert on packet loss and jitter, not only on uptime. Keep a path trace when alerts fire. Review the data monthly with the ISP and the app owner. If you want a second opinion before a circuit renewal or a cloud move, the Expert architecture session from Cloudverg is $450 one-time for a 90 minute call plus a written summary. That session is one option among others.
Frequently asked questions
What is the difference between latency and jitter?
Latency is how long a packet takes to reach the other side, usually measured as round-trip time. Jitter is how much that time changes from packet to packet. A link can have low average latency and still have bad jitter, which is why calls break up on a connection that looks fast in a speed test.
Does packet loss always mean a bad cable?
No. Packet loss can come from congested queues, Wi-Fi interference, a policer, an MTU mismatch, or a routing problem. A bad cable or duplex mismatch is one cause, and interface error counters help you rule it in or out. Start at both ends of the link and work outward.
How do I test jitter and packet loss?
Use ping and mtr for a quick path check, then run iperf3 in UDP mode under load to see jitter and loss. Capture traffic with tcpdump or Wireshark when you need to see retransmissions or RTP behavior. Test from the user location at peak time, not only from a server.