[ntp:questions] Fudge time offset on client/peer?
David Mills
mills at udel.edu
Fri Oct 16 18:17:59 UTC 2009
Dave,
Interleaved mode doesn't help with asymmetric delays; however, you may
notice an ntpq billboard variable "xleave", in any mode. The choice of
name is probably misleading and might be changed. What this measures is
the time from completing all packet fields other than the MAC to the
time of the output device interrupt, properly called the transmit
drivestamp. In interleaved symmetric and broadcast modes, the transmit
drivestamp this is used as the transmit timestamp sent in the following
packet so the delays due to output queuing, buffering and crypto
operations can be compensated. For noninterleaved modes the variable
could be used to "back time" the transmit timestamp in the next packet.
This could produce more jitter, but in the average better time.
Dave
Dave Hart wrote:
>Hi Rich,
>
>As you've noticed, fudging the offset it's available except for
>refclocks. However, you might experiment with the new interleaved
>mode to see how it handles the asymmetry. You could peer your home
>and work refclock ntpds using something like:
>
>peer <other> maxpoll 8 xleave
>
>The big downside to xleave is it is only available for symmetric
>("peer") associations which are configured explicitly on both sides.
>
>Cheers,
>Dave Hart
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>
More information about the questions
mailing list