Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was reading through the Wikipedia entry on NTP, and noticed this:

The NTP synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times.

Does anyone know how often this actually comes up, where the incoming and outgoing routes don't have approximately the same latency?

share|improve this question
up vote 3 down vote accepted

Strictly speaking, it is extremely rare for latency on a non-trivial path to NOT be asynchronous.

The only way for latency in both directions to be both equal and stable is if the bit rate of all links in the path are identical, the IP routing in both directions is identical, the traffic flow in both directions is identical, the routing policies at every device in the path in both directions is identical, and the host systems at both ends are behaving identically.

In practice, some paths will be "more" synchronous than others. Latency in two directions on a path may be approximately equal some of time if the various factors happen to balance at that moment. But that is not a stable condition as it depends on a lot more than just path itself.

Not only can latency vary by the path and traffic, but also on how you measure it. ICMP, UDP, and TCP packets may be routed differently, receive different queuing priorities, or be subject to different firewall rules. Latency is also effected by what goes on in the sending and receiving nodes.

I have written an article on the vagaries of network statistics which may be helpful: Loss, Latency, and Speed

share|improve this answer
What does the inability of measuring one-way latency affect? What can or can't do if we can or cannot measure one-way latency? – CMCDragonkai Mar 20 '15 at 9:34
Anything where the flow of data is time sensitive and essentially one-way. In live video, for example, the delay between the live event and when the viewer sees it needs to be minimized. But without clock synchronicity, you can only measure the total round-trip time. Congestion control in data transfer also cares about which direction of the path has rising latency: if its the side you are sending on then you are experiencing congestion, but if its the other side then you are not. The only way to measure one-way latency is to have synchronized and trusted clocks on both ends. – Seth Noble Mar 23 '15 at 13:49
I see, however in your live video example, broadcasters probably don't have a trusted clock on the consumer's TV right? – CMCDragonkai Mar 24 '15 at 1:06
Yes, without a trusted clock, you can only estimate the one-way latency from the round-trip-latency. If someone is uploading a file at the same time as streaming a video, that estimate may be too high. If they are downloading a file while streaming a video, it may be too low. (BTW, a true Broadcast Television situation is a different scenario: no round-trip network exists.) – Seth Noble Mar 24 '15 at 14:35

Well, any system with different upstream and downstream bitrates will necessarily have different latency, because it takes a different amount of time to send a packet of the same size. So normal ADSL counts for this, although the difference will be small.

Many systems which don't use wires will have asymmetric latency, such as 3G networks or satellite internet.

share|improve this answer
Good point on the satellite networks. I suppose those older residential satellite systems that use a modem for upload would have a tremendous asymmetry. – Curtis May 15 '12 at 13:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.