On 2/12/2012 4:55 PM, A C wrote: > I'm not exactly sure what happened but I may have caught the system in > the act of trying to run away. Below is the last two lines from the > peers log for one of the peers and below that is the output of ntpq > showing what happened to that peer immediately after. Note the offset. > This somewhat matches what I had been seeing previously where my system > would be reporting sane numbers and then very suddenly go haywire. > > 55969 77832.471 67.23.181.241 9324 0.006359155 0.081262776 0.001634487 > 0.008837966 > 55969 77897.557 67.23.181.241 9324 399326.864663492 0.000122070 > 0.001346708 399326.861631493 > > > remote refid st t when poll reach delay offset jitter > > ============================================================================== >67.23.181.241 128.4.1.1 2 u 53 64 377 0.122 3993268 3993268
This shows that this server is contacting rackety. Out of curiosity I looked at 67.23.181.241 and it turns out that it's running ntpd 4.2.2p1 which is rather ancient: > version="ntpd [email protected] Fri Nov 18 13:21:21 UTC 2011 (1)"?, > processor="x86_64", system="Linux/2.6.18-274.17.1.el5.centos.plus", 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. Danny _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
