Rich Wales wrote: >> you might experiment with the new interleaved mode to see how it >> handles the asymmetry. You could peer your home and work refclock >> ntpds . . . . > > Actually, I tried that some time back, but it didn't help a bit. > > I eventually came to understand that "xleave" mode is designed to > reduce the effect of processing delays inside a server's network > stack. Sadly, it doesn't do a thing to alleviate asymmetries. > > Indeed, my current impression (someone please correct me if I'm > wrong!) is that NTP is *inherently incapable* of measuring (or even > detecting) network latency asymmetries -- the NTP protocol assumes > that traffic "comes" and "goes" with equal speed, and it has no way > to detect situations in which this is not true.
That is correct, unfortunately. Noone has been able to come up with a scheme that will allow NTP, or any other program for that matter, to be able to measure any asymmetry. All it can tell is when it sent out a packet and when it got it back. There is nothing that either end can do to give it any indication of the nature of the asymmetry. Neither photons nor electrons can tell you how fast they were moving even in a single segment never mind over multiple segments. I have no idea why anyone would think the xleave would make any difference since it cannot tell you anything about asymmetry. The fudge command is really meant for refclocks and not servers or peers. I don't think that it can be used to express asymmetry for a server or peer. 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