Network Latency: How to Calculate Total Packet Delay

Packet delay, or latency, is the time data takes to travel from source to destination on a network. The total delay is the sum of four components — processing, queuing, transmission, and propagation — and is expressed in milliseconds (ms). This calculation is the basis for diagnosing performance bottlenecks.

• What is network latency?
• What are the types of delay in networks?
• How to measure network latency?
• How to calculate the total packet sending delay?
• Impact of latency on applications
• Strategies to reduce network latency

What is network latency?

Network latency is the measure of the time a data packet takes to travel from a source to a destination on a communication network, usually expressed in milliseconds (ms) or microseconds (µs). It directly determines the quality of the user experience in video conferencing, online gaming, streaming, and financial transactions.

Latency is not a single number: it is composed of several delays that accumulate at each device and link the packet traverses. A router needs to inspect and forward the packet, the packet may wait in a queue when there is congestion, the bits need to be placed onto the physical medium, and finally the signal needs to travel the distance to the next node.

This accumulation explains why two connections with the same bandwidth can perform very differently. Bandwidth defines how many bits per second the link carries; latency defines how long each packet takes on its way. To understand how packets flow between layers and protocols, it is worth reading the article on protocols and service models in network communication.

As the demand for real-time communications and fast data transfers grows, measuring and managing latency has ceased to be the exclusive concern of network engineers and now affects any team operating applications in the cloud.

What are the types of delay in networks?

The total delay of a packet is made up of four types of delay: processing, queuing, transmission, and propagation. Each has a distinct cause and its own mitigation strategy, as the table below summarizes.

Processing delay occurs when network devices analyze the packet header, run security checks, address translations, and decide on the output interface. On modern hardware, this delay is usually measured in microseconds, but it grows with deep packet inspection.

Queuing delay appears when the packet waits in a buffer before being transmitted. Under heavy traffic, full queues are the main cause of latency variation (jitter) and packet drops.

Transmission delay is the time to push all the bits of the packet onto the link, and depends on the packet size and bandwidth: a 12,000-bit packet on a 1 Mbps link takes 12 ms to be transmitted.

Propagation delay is the travel time of the signal through the physical medium. The Cisco documentation on delay in packet voice networks uses the planning estimate of 6 µs/km in fiber optic cable, derived from ITU-T G.114 — on a 1,000 km link, that means about 6 ms of propagation alone.

How to measure network latency?

Latency is measured mainly by RTT (Round-Trip Time), the round-trip time of a packet between your device and a destination. The most accessible tools are ping and traceroute, present on any operating system.

ping google.com
traceroute google.com

1. Run ping <destination> to get the minimum, average, and maximum RTT in milliseconds.
2. Run traceroute <destination> (or tracert on Windows) to identify the latency at each intermediate hop along the path.
3. Compare the hops: a sudden RTT spike at a specific node points to the bottleneck.
4. Record measurements at different times to separate momentary congestion from a structural problem.

For continuous monitoring, monitoring tools like Wireshark, Nagios, and PRTG Network Monitor record latency over time — a practice that connects to the broader concept of observability in distributed systems. Online speed tests also report latency alongside bandwidth.

In the web context, network latency shows up embedded in TTFB (Time to First Byte): the Google web.dev Time to First Byte guide considers a TTFB of up to 800 ms at the 75th percentile of accesses good, and above 1.8 seconds poor. It is worth remembering that even name resolution contributes to this time, as the article on the distributed structure of DNS shows.

How to calculate the total packet sending delay?

The total delay is calculated by summing the four latency components the packet faces while traveling from source to destination. Mathematically:

$AT = AtrasoProcessamento + AtrasoFila + AtrasoTransmissao + AtrasoPropagacao$

This calculation holds for each link in the path: on a route with several routers, the end-to-end delay is the sum of the total delays of all the links traversed.

Practical example of total delay calculation

Suppose a data packet traversing a link with the following characteristics:

• Processing delay: $2 ms$
• Queuing delay: $4 ms$
• Transmission delay: $3 ms$
• Propagation delay: $5 ms$

The total delay is calculated as follows:

$AT = 2ms + 4ms + 3ms + 5ms = 14ms$

Therefore, the total sending delay for this packet is 14 milliseconds. The example shows how each component contributes to the final result: calculations of this kind are essential for sizing infrastructure, defining service level agreements, and predicting the behavior of delay-sensitive applications.

Impact of latency on applications

Latency affects each application category differently, and knowing the limits tolerated by each guides the network design:

• Voice and video conferencing: the ITU-T G.114 recommendation (2003) indicates up to 150 ms one-way delay as the preferred range for voice; between 150 and 400 ms degradation increases, and above 400 ms the conversation becomes unacceptable.
• Online gaming: delay, perceived as "lag," shifts players' actions. In competitive games, tens of milliseconds separate a recorded play from a missed one.
• Financial transactions: in electronic markets, latency delays order execution, and execution speed has a direct financial impact.
• Video and audio streaming: high and unstable latency causes rebuffers and playback delays.
• Real-time web applications: chats, dashboards, and in-browser games depend on persistent, low-latency connections, like those described in the article on WebSockets and bidirectional real-time communication.

Understanding these limits turns latency from an abstract number into a design requirement: each use case defines how much delay the network can tolerate.

Strategies to reduce network latency

Latency optimization is a continuous process that combines sizing, traffic prioritization, and monitoring. The highest-impact actions:

1. Size the bandwidth for the expected workload, considering future growth, to avoid transmission delays.
2. Configure QoS (Quality of Service) to prioritize delay-sensitive traffic, such as VoIP (voice over IP) and video conferencing.
3. Reduce the number of intermediate hops with a well-planned topology and high-performance equipment.
4. Use efficient routing algorithms and load balancing to distribute traffic and avoid congestion.
5. Apply caching and data compression to reduce the volume transmitted over the network.
6. Monitor the network in real time and adjust the configuration based on the data collected.
7. Keep hardware and software up to date and plan for redundancy and failover for operational continuity.
8. Protect the network: attacks and malware generate spurious traffic, congest links, and raise latency.

None of these measures eliminates propagation delay — physics imposes the limit — but together they attack the controllable components: processing, queuing, and transmission.

Conclusion

Calculating the total packet delay is more than an academic exercise: it is the tool that separates guesswork from diagnosis when the network is "slow." In our CodeCrush practice, the recommendation is direct — measure RTT with ping and traceroute before any change, decompose the delay into its four components, and invest first where there is real control: queues and bandwidth. Propagation, physics solves (or doesn't); the rest is engineering.