[ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
martin.burnicki at meinberg.de
Fri Sep 12 08:03:24 UTC 2014
> An offset between two GPS synced servers by definition means path asymmetry.
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
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)
More information about the questions