On 2012-02-26, Danny Mayer <[email protected]> wrote: > On 2/26/2012 12:17 AM, Dave Hart wrote: >> On Sun, Feb 26, 2012 at 03:37, Danny Mayer <[email protected]> wrote: >>> It could well be that rackety is sending KOD packets and this server is >>> not recognizing them as such. rackety has a heavy load under normal >>> circumstances so it may well do so. When it does so the ntp timestamps >>> are going to be totally wrong, deliberately, so they should have been >>> discarded immediately. I don't remember whether or not KOD had been >>> introduced back when 4.2.2 was shipped so it may not be ignoring it when >>> it should. >>> >>> I suggest you pick a different server with a more modern version of ntpd >>> and see if that stabilizes the situation. >> >> While I'm all in favor of running modern ntpd, it's not going to >> affect KoD handling in terms of timekeeping. KoD responses only occur >> when a source IP exceeds relatively generous rate limits, and they >> carry timestamps that are totally useless, deliberately, which is a >> different beast than totally wrong. KoD timestamps are set to match >> the sender's originate timestamps, so if they attempt to use them for >> time, they learn nothing their local oscillator wasn't already telling >> them. > > It's worse than that. I analyzed the KOD code at the time and in fact > what the reference code does it copy the originator starting timestamp > to the receiving and sending server timestamp and sends it back. Now if > you calculate the resulting offset you will get a nasty surprise. After > a short discussion with Dave Mills he agreed with me that it results in > the result shifting and increasing the resulting offset. Check the > results for yourself!
It sets the offset to half the round trip time. > > Danny _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
