Network latency, delay components and round trips

Network latency describes delay through a stated direction and path, combining serialization, propagation, processing and waiting rather than indicating throughput alone.

A request can use little data and still take time to reach its response. The relevant quantity is delay through the path, not only how many bits the link could carry each second.

A one-way delay has several components

Use this original packet-path model:

{
  "packetBytes": 1500,
  "linkMbitPerSecond": 100,
  "propagationMs": 20,
  "processingMs": 8,
  "queueMs": 12
}

Putting 1500 bytes onto the stated one-hundred-Mbit/s link takes 0.12 ms. Adding the other declared components gives 40.12 ms one-way.

The original latency budget separates serialization, propagation, processing and queue delay.

Increasing that serialization rate alone would change only the 0.12-ms component in this model. It would not remove the twenty-ms propagation or twelve-ms queue.

For another explicitly chosen packet size, 500 bytes on a one-Mbit/s link takes four ms. Byte size and link rate belong in the arithmetic together.

Round-trip time measures both directions

If the modeled forward delay is 40.12 ms and the return delay fifteen ms, their network round trip is 55.12 ms before additional endpoint-response work.

Dividing that round trip by two gives 27.56 ms. It does not recover the actual forty-ms forward delay because the path is asymmetric.

A real one-way measurement also needs an appropriate time reference across endpoints. Unsynchronized clocks can make timestamp subtraction misleading.

The cited IP performance metrics distinguish the measurement definition from the timing data used to estimate it.

Startup can wait for several serial exchanges

For an original eighty-ms round-trip path, four strictly serial request/response waits contribute 320 ms before their other processing.

A page or playback startup can combine name lookup, connection establishment, authentication, metadata and media preparation. Some work can overlap; other steps depend on an earlier result.

The reduced four-exchange exercise does not claim an exact Emby startup sequence. It explains why setup delay can accumulate while each individual message is small.

A playback reserve changes tolerance to delay

Once an app has usable media ahead of its presentation, it can continue through some delivery waiting. That is different from removing the network latency itself.

Interactive controls can remain visibly delayed even while buffered playback is smooth. A seek or new stream can also require data not covered by the earlier reserve.

See Also

References