My 5.x machines are regularly reporting that the kernel is flipping between FLL and PLL mode (as shown by STA_MODE in syslog messages). This isn't occuring on my 4.x machines (they typically report 2040 then 2041 and stay indefinitely in that mode). Any suggestions as to why this is happening? (And how I can stop it regularly flipping) A fairly typical set of syslog entries looks like: Apr 1 00:15:16 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 00:32:22 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 01:23:36 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 01:40:42 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 10:09:10 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 10:26:14 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 12:59:58 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 13:51:14 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 16:07:48 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 16:59:06 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 19:15:42 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 19:49:48 fwall2 ntpd[407]: kernel time sync enabled 2001 -- Peter Jeremy
On Apr 1, 2005, at 05:45, Peter Jeremy wrote:> Any suggestions as to why this is happening? (And how I can stop > it regularly flipping)I don't think this is really an issue. It may be annoying to see it in the logs, but NTPv4 uses each algorithm when it's appropriate to get the most accurate time. Since network conditions change, the way NTP has to deal with them changes since it queries other NTP servers over the network. This was actually freebsd-questions last year and one response pointed to this paper: http://www.eecis.udel.edu/~mills/database/papers/allan.pdf You may want to check-out the the netgroup comp.protocols.time.ntp if you want to ask the experts (and authors) on NTP.
on 01.04.2005 16:24 Bob Bishop said the following:> I think this is an issue: > > - As stated, machines running 4.x don't seem to do it > - In addition to the mode schizophrenia, undex 5.3 I'm also seeing > resets of several seconds which don't happen on identical hardware > running 4.11 in the same rack. Yes I know the clock drifts will be > different, but ntp.drift is very close on the two boxen. > > I believe something's broken. More datapoints: > > - I'm seeing it under 5.3R both on i386 and amd64 but not i386/4.11 on > the same LAN > - I'm not seeing it on 5.1R on a remote system >I can second that. I have never seen anything like this with 5.2.1 as soon as I upgraded to 5.3 I started seeing messages like these: Mar 29 01:19:51 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 06:12:49 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 06:29:53 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 09:03:25 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 09:20:31 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 11:20:04 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 11:37:08 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 14:44:55 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 15:02:01 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 17:52:50 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 18:09:54 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 18:44:03 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 19:54:30 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 22:15:40 oddity ntpd[400]: time reset -0.288522 s Mar 29 22:15:40 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 23:09:19 oddity ntpd[400]: time reset +0.530732 s Mar 29 23:09:19 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 23:35:18 oddity ntpd[400]: time reset -0.165853 s Mar 30 00:41:14 oddity ntpd[400]: time reset -0.199104 s Mar 30 11:21:21 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 11:38:27 oddity ntpd[400]: kernel time sync enabled 2001 Mar 30 17:22:37 oddity ntpd[400]: time reset -0.392425 s Mar 30 17:22:37 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 17:26:06 oddity ntpd[400]: kernel time sync enabled 2001 Mar 30 17:28:15 oddity ntpd[400]: time reset +0.309711 s Mar 30 18:07:02 oddity ntpd[400]: time reset +0.164515 s Mar 30 18:41:43 oddity ntpd[400]: time reset -0.391355 s Mar 30 19:00:17 oddity ntpd[400]: time reset +0.598313 s Mar 30 19:47:45 oddity ntpd[400]: time reset -0.276978 s Mar 30 21:26:24 oddity ntpd[400]: time reset +0.158781 s Mar 30 23:18:01 oddity ntpd[400]: time reset +0.160708 s Mar 30 23:18:01 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 23:19:13 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 08:36:16 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 08:53:20 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 11:44:02 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 12:18:08 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 13:26:30 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 13:43:35 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 17:32:07 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 17:49:11 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 20:22:54 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 20:39:59 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 21:14:08 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 21:31:11 oddity ntpd[400]: kernel time sync enabled 2001 2001<->6001 flips do not trouble me a bit (but annoying), time resets are not a good thing definitely. I suppose that it might be possible that the root cause is in my local network conditions, but I must say that it would feel like ntpd (or something that it relies on) became less robust and it would be nice to get to know how to get that robustness back. -- Andriy Gapon