Latency, jitter and packet loss: what each measure means
A fast download result does not guarantee a smooth call or game. Interactive traffic also depends on latency, changes in latency known as jitter, and packet loss. Each describes a different aspect of the connection, so measure them separately before changing equipment or blaming a server.
Three measurements, three different questions
Latency is the time data takes to travel between points. A ping result usually reports round-trip time (RTT): the interval from sending a probe to receiving its reply. Jitter describes variation between successive delays. Replies arriving in 20, 21, 90 and 18 milliseconds may have an acceptable average yet still contain a disruptive spike. Packet loss means a probe or its reply did not arrive within the test’s time limit. Congestion is one possible cause; deliberate filtering of diagnostic traffic is another.
These measures interact without being interchangeable. A link capable of transferring a large file quickly can build a queue in the router during an upload, delaying short packets used by a call. A single slow response from an intermediate router is weak evidence of an end-to-end problem: routers can give ICMP replies low priority while forwarding normal traffic.
A practical test sequence
Send a series of probes to the same destination using ping and traceroute. Record the destination, time, minimum and maximum RTT, and unanswered probes. Repeat over Ethernet or another network. Run the speed test separately; throughput and delay answer different questions. If Wi-Fi has spikes that Ethernet does not, investigate signal quality, interference and other devices on the local network first.
Keep conditions comparable: same server, device, method and approximate time of day. Check both an idle connection and one carrying a large upload. A large increase in RTT under load points toward queueing; changing DNS alone is unlikely to fix it. Multiple short tests over time are more useful than one screenshot taken during an unexplained spike.
Interpret results in the application
There is no universal jitter threshold that makes every game or call good. Applications differ in how they buffer audio, recover from loss and choose network paths. Lost ICMP replies are not automatically lost media packets. If only one service has trouble, inspect that service’s own statistics and status. A route trace can help locate a pattern, but its probes may take a different path from the application.
RFC 792 describes the ICMP Echo messages commonly used by ping. It defines the mechanism, not a single quality score for every application. Compare repeated results with the symptoms users actually notice.