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@lists.ntp.org >https://lists.ntp.org/mailman/listinfo/questions > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions