Rich Wales wrote: > Kevin Oberman wrote: > >> I don't know what the path is from your location to Stanford's NTP >> server . . . . > > I'm in a Stanford-built housing complex immediately adjacent to the > campus. The extra (and likely asymmetric) delay in my case is most > likely happening because my residence is connected via a cable modem > infrastructure run by the Stanford campus's IT services people. > >> NTP assumes the same delay for the return packet that it had for >> the request packet. If that is not the case, you will see a fixed >> offset. The only fix is a 'fudge' of the time for that server. If >> the path is unstable, even that will not work. > > I thought the "xleave" feature in ntp-dev was supposed to compensate > for asymmetric paths. All my systems are running ntp-dev and peering > with one another with "xleave" specified.
You misunderstand the usage of the xleave option which is still experimental. It requires (currently) IEEE-1588 hardware to work and it needs to be set up to send additional time-delay information down the same path as the ntp packet. fudge is the right option if you know the amount of the asymmetry, which is hard to measure in the first place. For some reason I am having difficulty finding the fudge option in the html documentation but it should describe this. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
