On 2/26/2012 12:17 AM, Dave Hart wrote: > On Sun, Feb 26, 2012 at 03:37, Danny Mayer <ma...@ntp.org> 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! Danny _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions