[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