Network Latency is the time it takes for data to travel from a source to a destination. While network engineers occasionally measure "One-Way Latency," almost all standard troubleshooting tools measure Round-Trip Time (RTT)—the time it takes for a packet to reach the destination and the response to travel all the way back, measured in milliseconds (ms).
The Four Components of Latency
Latency is not a single number; it is the sum of four distinct delays:
- Propagation Delay: The unavoidable laws of physics. Light in a fiber optic cable takes time to travel from New York to London (roughly 70ms RTT).
- Transmission Delay: The time it takes a router to physically push the bits of a packet onto the wire. Faster links (10 Gbps) have lower transmission delay than slow links (10 Mbps).
- Processing Delay: The time a router or Stateful Firewall takes to examine the packet header, check security rules, or perform NAT.
- Queueing Delay: The most variable factor. If a router is congested, packets sit in a buffer waiting their turn to exit. This is why latency spikes wildly during large downloads.
Network Latency vs Application Response Time
This is the most critical distinction in IT troubleshooting: A slow application is not automatically a network latency problem.
Imagine the traffic flow:
User ➔ LAN Switch ➔ Firewall ➔ ISP ➔ Internet ➔ Cloud Database Server
If a user clicks a button in their CRM and it takes 15 seconds to load, they will say "the network is slow." However, if a ping to the Cloud Database Server shows a steady 30 ms RTT, the network is delivering the request instantly. The delay is entirely Application Response Time (e.g., the database server is running a badly optimized SQL query that takes 14.9 seconds to process before it replies). Do not waste time rebooting switches when the server CPU is maxed out.
Acceptable Latency Guidelines
Avoid arbitrary claims like "anything over 100 ms is bad." Acceptable latency depends entirely on the geography and the application:
- Local Area Network (LAN): Should be < 1 ms.
- Cross-Country (e.g., NY to LA): Roughly 60–80 ms is perfectly healthy.
- Satellite Internet: 500–700 ms is standard due to distance to orbit.
For applications, Voice over IP (VoIP) degrades noticeably above 150 ms one-way (300 ms RTT). Conversely, downloading a large file works perfectly fine at 200 ms latency, provided there is zero Packet Loss.
Troubleshooting Latency Workflow
- Establish a Baseline: What is the normal latency to this specific destination? If the destination is in Australia and you are in Canada, 200 ms is the healthy baseline.
- Compare Wired vs Wireless: Wi-Fi inherently adds latency and Jitter due to half-duplex radio contention. Always test latency from a wired Ethernet connection to rule out RF issues.
- Ping the Default Gateway: If pinging your local firewall takes 500 ms, the problem is your local switch or a severe broadcast storm on your LAN.
- Check Utilization (Monitoring): Latency that spikes during business hours and drops at night usually indicates Queueing Delay. Your internet pipe is full, and packets are waiting in line.
- VPN Overhead: If pinging a server over a VPN is significantly slower than pinging a public IP in the same city, the firewall's encryption/decryption CPU might be a bottleneck.