Packet Network Latency and Jitter Formula Sheet

This formula sheet collects first-pass calculations for packet-network latency and jitter budgets. It is intended for telecommunications engineers who need to estimate, review, test, or troubleshoot a service before relying on field measurements alone.

The equations are screening tools, not a replacement for measured traffic, device data, QoS configuration review, and acceptance testing. State the service boundary, direction, packet size, packet rate, traffic class, load condition, clock reference, route, and percentile before comparing numbers.

Notation

Symbol	Meaning	Typical unit
d	path length	m, km
v	propagation speed in medium	m/s
L	packet length including relevant headers	bit
R	line rate, shaped rate, or class service rate	bit/s
\lambda	packet arrival rate	packet/s
\mu	packet service rate	packet/s
\rho	utilization	dimensionless
t_{prop}	propagation delay	s
t_{ser}	serialization delay	s
t_{proc}	processing delay	s
t_{queue}	queueing delay	s
t_{sched}	scheduler or radio access delay	s
t_{retx}	retransmission or recovery delay	s
J	jitter or packet-delay variation	s
PLR	packet loss ratio	dimensionless
RTT	round-trip time	s

Use one consistent packet boundary. A payload-only packet size is not the same as an Ethernet frame size, a tunneled packet size, a radio transport block, or a measured packet on a provider handoff.

End-to-End Delay Decomposition

One-way packet latency can be written as:

where t_{app} represents endpoint, gateway, firewall, encryption, or application processing when the service boundary includes those functions.

For a multi-hop path:

Round-trip time is:

If the path is symmetric, a rough estimate is:

Do not infer one-way latency from half the RTT unless routes, queues, service classes, and clocks support that assumption.

Propagation Delay

Propagation delay through a medium is:

For optical fiber, a common screening value is:

or approximately:

For free-space radio:

or approximately:

Route length may be much longer than map distance because of ducts, rights of way, rings, provider routing, diversity constraints, patch panels, and restoration paths.

Serialization Delay

Serialization delay is the time required to put all packet bits onto a link:

For L in bytes:

If a packet traverses several egress links:

Use the rate that actually controls the queue. That may be the physical interface rate, a shaped provider rate, a radio scheduler allocation, a committed information rate, or a QoS class rate.

Packet Overhead and Goodput

If payload size is L_p and overhead is L_h:

Protocol efficiency is:

Payload goodput from line-rate throughput is:

If packet loss and retransmission are material, a simple first-pass goodput screen is:

This expression is optimistic for protocols whose congestion control or retransmission behavior reduces rate after loss.

Utilization

For an offered bit rate A and service rate R:

For packets of length L:

and:

A stable single-server queue requires:

The engineering warning is stronger: delay tails often become unacceptable well before \rho reaches 1. For real-time classes, design review should examine utilization during normal, burst, maintenance, and degraded states.

M/M/1 Queueing Screen

For a simplified M/M/1 screening queue, average time in system is:

Average queueing time, excluding service time, is:

Average number of packets in the system is:

Average queue length is:

These equations assume Poisson arrivals, exponential service time, one server, infinite buffer, and a simple discipline. Packet networks often violate those assumptions. The value of the model is diagnostic: it shows how rapidly delay grows as utilization approaches capacity.

M/M/1 Tail Delay Screen

For an M/M/1 queue, a useful tail screen for time in system is:

where p is the percentile as a fraction, such as 0.95 for p95.

For queueing time only, the unconditional waiting-time distribution has a probability mass at zero. If p>1-\rho, the queueing-time percentile can be screened as:

If p\le 1-\rho, then:

This distinction matters at low utilization. Many packets see no queue, but the tail can still matter during bursts.

G/G/1 Queueing Screen

When traffic is bursty or packet service time is not exponential, Kingman’s approximation gives a useful mean queueing screen:

where c_a is the coefficient of variation of inter-arrival time and c_s is the coefficient of variation of service time.

Higher burstiness increases delay even when average utilization is unchanged. This is why a network can pass a smooth throughput test and fail under realistic application traffic.

Packet Delay Variation and Jitter

For a sequence of measured one-way delays D_i, mean delay is:

Root-mean-square delay variation is:

Consecutive packet-delay variation can be screened as:

Peak-to-peak delay variation over a measurement window is:

A percentile spread can be more robust than a single maximum:

Always state which jitter definition is used. Clock jitter, serial-link jitter, and packet-delay variation are related timing concepts but not interchangeable measurements.

Bandwidth-Delay Product

The bandwidth-delay product estimates the amount of data in flight:

For bytes:

BDP is useful for transport-window sizing, buffer review, and understanding why long-distance high-rate services may need large in-flight data windows even when packet loss is low.

Buffer Drain Time

If a buffer contains B bits and drains at service rate R:

If the buffer is specified in bytes:

This delay is not free capacity. A large buffer may reduce loss while creating excessive latency. Real-time services usually need bounded buffers, class separation, active queue management, traffic shaping, or admission control.

Burst Absorption

For a burst arriving at rate R_b into a class served at rate R_s, the excess rate is:

If R_b>R_s for duration T_b, the required temporary buffer is:

If R_b\le R_s, the burst does not grow the queue under this simple model.

After the burst ends and arrivals drop below the service rate, drain time depends on the difference between service rate and post-burst arrival rate.

Packet Loss Ratio

Packet loss ratio is:

If packets are counted in a class:

Loss should be tied to class, interface, queue, direction, measurement interval, load condition, and counter meaning. Drops before classification, policing drops, tail drops, active queue management drops, radio block errors, and application timeouts may have different engineering causes.

Delay Margin

For a latency requirement t_{req} and calculated percentile latency t_p:

For a jitter requirement J_{req} and calculated jitter J_p:

Positive margin is not enough if the assumptions are weak. Reserve allowance for measurement uncertainty, clock error, route changes, load growth, maintenance states, firmware changes, security inspection, encryption overhead, and degraded routing.

Measurement Resolution

If timestamp resolution is \Delta t, a simple uncertainty bound for one measured interval using two timestamps is:

This is only a resolution screen. Real measurement uncertainty can also include clock synchronization error, timestamp placement, software scheduling, packet capture loss, probe bias, asymmetric paths, and sample-size effects.

For a sample of N measured delays, sample mean is:

Sample standard deviation is:

Percentile latency should be reported directly from the measured distribution, not inferred from the average unless the distribution model has been justified.

Worked Example: One-Way p95 Latency and Jitter Screen

A remote monitoring service crosses two 100\ \text{Mbit/s} access links and three 1\ \text{Gbit/s} aggregation/core links. The route contains 60\ \text{km} of fiber-equivalent path length and four packet-forwarding devices. The critical telemetry packet is 1200\ \text{bytes} including relevant headers.

Assume:

Parameter	Value
telemetry packet size	1200\ \text{bytes}
access link rate	100\ \text{Mbit/s}
core link rate	1\ \text{Gbit/s}
fiber-equivalent route length	60\ \text{km}
forwarding delay per device	50\ \mu\text{s}
p95 queueing delay, access classes	1.2\ \text{ms} total
p95 queueing delay, core classes	0.5\ \text{ms} total
p50 queueing delay, all classes	0.4\ \text{ms} total
one-way latency requirement	5\ \text{ms} at p95
packet-delay variation target	2\ \text{ms} using p95-p50

Packet length in bits:

Serialization delay on one access link:

For two access links:

Serialization delay on one 1\ \text{Gbit/s} link:

For three core links:

Fiber propagation delay:

Device processing delay:

p95 queueing delay:

p95 one-way latency:

Latency margin:

Using the stated p95-p50 jitter definition:

Jitter margin:

Engineering Comment

The latency budget passes with useful margin, but the jitter margin is smaller. The technical response should not be “the network is fast enough.” It should be: validate queue behavior with burst traffic, confirm class markings on every boundary, set alarms before J_{p95-p50} reaches 2\ \text{ms}, and repeat the calculation for degraded routing.

Worked Example: Queueing Screen for a Reserved Class

A protected class reserves R=8\ \text{Mbit/s} for telemetry packets of 600\ \text{bytes}. The offered load is A=3.5\ \text{Mbit/s}.

Packet length:

Service rate:

Arrival rate:

Utilization:

Average queueing time using the M/M/1 screen:

p95 queueing-time screen:

Engineering Comment

The average queueing delay is below half a millisecond, but the p95 screen is about five times larger. That gap is the main lesson. A service can look healthy in averages while p95 or p99 delay threatens voice, control, timing, or telemetry requirements.

Common Mistakes

1. Comparing a latency requirement with average ping results instead of percentile one-way delay under load.
2. Using physical interface rate when the effective service rate is a shaped, scheduled, policed, or reserved class rate.
3. Ignoring packet overhead, tunneling, encryption, or smaller degraded-mode rates.
4. Treating jitter as one universal quantity without stating whether it is RMS jitter, peak-to-peak variation, consecutive delay variation, or percentile spread.
5. Assuming redundancy improves latency when the backup path may be longer, lower-rate, or more congested.
6. Sizing buffers to avoid loss without checking the delay created by draining those buffers.
7. Declaring a QoS policy valid without verifying classification, marking, scheduling, policing, and drops at every boundary.
8. Measuring only idle networks instead of normal peak, burst, failover, and maintenance conditions.

Validation Checklist

A defensible latency and jitter calculation should be accompanied by evidence for:

• service boundary and direction;
• packet size and overhead model;
• physical route length and restoration route length;
• line rates, shaped rates, and reserved class rates;
• traffic class mapping at each device;
• device forwarding delay or measured processing delay;
• queueing assumptions and burst model;
• percentile definitions and measurement duration;
• clock synchronization and timestamp method;
• normal, peak, burst, degraded, and failover test conditions;
• packet loss counters by class and interface;
• monitoring thresholds tied to remaining margin.

The calculation is acceptable only when its assumptions are visible enough for another engineer to challenge, repeat, and test.