[ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?

Martin Burnicki martin.burnicki at meinberg.de
Fri Sep 12 08:03:24 UTC 2014


Rob wrote:
> An offset between two GPS synced servers by definition means path asymmetry.

+1

However, path asymmetry includes

- systematic asymmetry (e.g. ADSL) on one ore more (!) parts of the path 
between 2 nodes

- errors due to different link speeds, e.g 100 MBit from 1 switch port 
to one node, and GBit from another switch port to the other node

- different processing speeds for incoming and outgoing packets at the 
client ans server side

The time from when a packet comes in from the wire until it arrives at 
the application depends on the protocol stack, CPU power, and system load

Similarly, the time from when a packet is sent by ntpd until it actually 
goes out on depends on the protocol stack, CPU power, and system load.

However, the mean processing time (without noticeable system load) is 
usually different for sending and receiving, so this also a kind of 
asymmetry.

As long as the ratio between these processing times is similar on the 
client and server the resulting time error is low. However, if there's 
only an asymmetry at one end the resulting time error is higher.

We have made some tests with hardware time stamping of NTP packets:

- if hardware time stamping is used at both ends then all processing 
times are eliminate, and thus the time error is obviously small

- if hardware time stamping is only used at one end (client *or* server) 
then the resulting error is usually *larger* than the mean error you see 
if no hardware time stamping is used at all, which is due to the 
difference/asymmetry in processing times for incoming and outgoing packets.

(I know there are additional conditons like IRQ coalescense which make 
things even worse)


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list