Re: Kernel NTP flipping between FLL and PLL modes
on 05.04.2005 22:32 Peter Jeremy said the following:
Note that this code doesn't exist in 5.3. It was introduced sometime
between 5.3 and 5.4. In any case, looking at the associated comments,
this only affects the FLL/PLL loop gain.
Yes, I see that I looked in a wrong place.
The FLL/PLL switch is set is in sys/kern/kern_ntptime.c:hardupdate()
using:
time_status = ~STA_MODE;
if (mtemp = MINSEC (time_status STA_FLL || mtemp MAXSEC)) {
L_LINT(ftemp, (time_monitor 4) / mtemp);
L_RSHIFT(ftemp, SHIFT_FLL + 4);
L_ADD(time_freq, ftemp);
time_status |= STA_MODE;
}
and this code hasn't changed. MINSEC is 256 (which matches the comments)
MAXSEC is either 1200 or 2048 (depending on which header file is active),
though the comments imply it is 1024. mtime is the time since the last
adjustment (call to hardupdate()).
MAXSEC==2048 is used, the contrib header file could not be included
because its directory is not included with -I. Besides I've verified it
by sneaking in -E
STA_FLL is set in ntpd/ntp_loopfilter.c:
if (sys_poll NTP_MAXDPOLL)
ntv.status |= STA_FLL;
though the associated comment states for legacy only. (And I'm
never seeing STA_FLL transitions in syslog). This sets STA_FLL if the
polling interval is 2^10 (1024). By default, sys_poll is limited to
NTP_MAXDPOLL so this should never occur. (You can over-ride it with
maxpoll N on peer/server config lines).
I am using the default value of maxpoll, no overrides.
So, IMO this leaves one possibility: mtemp 2048, i.e. hardupdate() was
not called for longer than this time i.e. either ntp_adjtime() was not
called or it was called without MOD_OFFSET.
It looks like it is not trivial to find the cause of this.
BTW, what is the best way to get out of ntpd everything it can tell
about its operations ?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
on 06.04.2005 11:13 Andriy Gapon said the following: I am using the default value of maxpoll, no overrides. So, IMO this leaves one possibility: mtemp 2048, i.e. hardupdate() was not called for longer than this time i.e. either ntp_adjtime() was not called or it was called without MOD_OFFSET. It looks like it is not trivial to find the cause of this. I can not explain it, but I've suddenly got a gut feeling that the subject discussed might be a result of revision 1.53 of sys/kern/kern_ntptime.c Deal with MOD_FREQUENCY before MOD_OFFSET because the latter is the one which runs the actual update. This fixes a bug where there were a delay in applying the frequency adjustment. In extreme cases this could result in marginal stability of the kernel-pll. I can test this hypothesis as soon as I get a chance to reboot the machine in question (might not be soon). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 11:45 06/04/2005, Andriy Gapon wrote: I can not explain it, but I've suddenly got a gut feeling that the subject discussed might be a result of revision 1.53 of sys/kern/kern_ntptime.c Nope. Tried that (backed it out to 1.52), no improvement. I'm currently runnning a 5.3 with the ntpd from 5.2.1 (ie version 4.1.1 not 4.2.0); looks good so far, I'll report back after a sensible interval. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On Apr 6, 2005, at 07:04, Bob Bishop wrote: I'm currently runnning a 5.3 with the ntpd from 5.2.1 (ie version 4.1.1 not 4.2.0); looks good so far, I'll report back after a sensible interval. You may also want to poke your head into comp.protocols.time.ntp with this issue. Some of the designers and programmers hang out there (there's also a mailing list that's gatewayed to the newsgroup). www.ntp.org has more info on all of this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On 04/01/05 14:51, Vivek Khera wrote: On Apr 1, 2005, at 12:56 PM, Bob Bishop wrote: At 18:42 01/04/2005, Roland Smith wrote: On my amd64 box I also get the mode flipping, but I don't get resets. Hmm. I am getting resets on my amd64. On my dual opteron, I get flipping perhaps a handful of times per day (5.4-PRE/amd64 from march 22). On my Xeon EMT64 with hyperthreading (5.3-STABLE/amd64 from Jan 7), it happens every 2-6 hours. My 5.3-REL/i386 Xeon with hyperthreading does it about two or four times per day, no resetting. Neither one shows time step resets. On my little LAN here I have one machine syncing with the Internet that acts as a time server for 3 others. The time server machine (733MHz P3 w/ 4BSD scheduler), named 'www', logs the following: Apr 5 12:35:59 www ntpd[439]: ntpd 4.2.0-a Tue Apr 5 10:59:44 CDT 2005 (1) Apr 5 12:44:33 www ntpd[439]: kernel time sync disabled 2041 Apr 5 12:53:07 www ntpd[439]: kernel time sync enabled 2001 Apr 5 17:36:27 www ntpd[439]: kernel time sync enabled 6001 Apr 5 17:53:31 www ntpd[439]: kernel time sync enabled 2001 Apr 5 18:44:43 www ntpd[439]: kernel time sync enabled 6001 Apr 5 19:01:46 www ntpd[439]: kernel time sync enabled 2001 Apr 5 20:44:12 www ntpd[439]: kernel time sync enabled 6001 Apr 5 21:01:16 www ntpd[439]: kernel time sync enabled 2001 Apr 6 00:26:11 www ntpd[439]: kernel time sync enabled 6001 Apr 6 00:43:16 www ntpd[439]: kernel time sync enabled 2001 Apr 6 02:25:43 www ntpd[439]: kernel time sync enabled 6001 Apr 6 02:42:46 www ntpd[439]: kernel time sync enabled 2001 Apr 6 05:33:31 www ntpd[439]: kernel time sync enabled 6001 Apr 6 05:50:37 www ntpd[439]: kernel time sync enabled 2001 Apr 6 07:50:09 www ntpd[439]: kernel time sync enabled 6001 Apr 6 08:07:14 www ntpd[439]: kernel time sync enabled 2001 Apr 6 09:15:31 www ntpd[439]: kernel time sync enabled 6001 Apr 6 09:32:37 www ntpd[439]: kernel time sync enabled 2001 Apr 6 11:32:07 www ntpd[439]: kernel time sync enabled 6001 2 of the clients (800MHz P3 and Althon XP 1800+, both w/ 4BSD scheduler) don't have any weird issues at all. The third (4x 550MHz P3 Xeon w/ ULE scheduler), aptly named 'quad', hasn't flipped much but has a lot of resets: Apr 5 12:45:28 quad ntpd[708]: ntpd 4.2.0-a Tue Apr 5 10:34:52 CDT 2005 (1) Apr 5 12:54:03 quad ntpd[708]: kernel time sync disabled 2041 Apr 5 13:05:48 quad ntpd[708]: kernel time sync enabled 2001 Apr 5 16:19:52 quad ntpd[708]: time reset -0.702001 s Apr 5 17:05:57 quad ntpd[708]: time reset +1.232861 s Apr 5 17:49:57 quad ntpd[708]: time reset -0.678139 s Apr 5 19:01:45 quad ntpd[708]: time reset +0.183283 s Apr 6 03:04:23 quad ntpd[708]: time reset -0.680651 s Apr 6 03:27:53 quad ntpd[708]: time reset +0.158949 s Apr 6 03:47:04 quad ntpd[708]: time reset +0.983025 s Apr 6 04:24:39 quad ntpd[708]: time reset -1.101975 s Apr 6 04:46:09 quad ntpd[708]: time reset +0.637136 s Apr 6 11:51:31 quad ntpd[708]: kernel time sync enabled 6001 Apr 6 12:08:34 quad ntpd[708]: kernel time sync enabled 2001 Note that all machines are connected to the same 100Mbit switch and were rebooted at the same time. I only got resets on the SMP/ULE machine. Perhaps SMP or ULE make the issue worse? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 18:21 06/04/2005, Jon Noack wrote: [...] I only got resets on the SMP/ULE machine. Perhaps SMP or ULE make the issue worse? I'm seeing it on both SMP and UP boxes on the same LAN, not running ULE. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
on 01.04.2005 20:40 Bob Bishop said the following:
Unlikely I think. As I said, I've got several machines on the same LAN:
the 5.3's misbehave; the others don't.
#define CLOCK_ALLAN 1500.
...
doubleallan_xpt = CLOCK_ALLAN;
...
if (ULOGTOD(sys_poll) allan_xpt / 2) {
...
if I understand the above random lines of code in
contrib/ntp/ntpd/ntp_loopfilter.c correctly, then PLL-FLL switch
occurs when polling interval goes 512-1024, which is perfectly
possible under certain conditions with default ntp settings: minpoll=64,
maxpoll=1024 if ntp.conf(5) can be trusted.
BTW, tinker allan part of the man page seems to not be correct - it
has 1024 for default value when the code has 1500 as you can see.
As I understand between 5.2.1 and 5.3 ntpd version changed from 4.1.1b
to 4.2.0 and changes in this PLL/FLL area were significant, so I am not
sure what is right and what is wrong here but I am going to experiment
with tinker-ing allan to 2048 as Christian Hiris has suggested:
http://lists.freebsd.org/pipermail/freebsd-questions/2004-November/065529.html
P.S. BTW, what rules polling interval value increase/decrease ?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On Tue, 2005-Apr-05 15:01:07 +0300, Andriy Gapon wrote:
on 01.04.2005 20:40 Bob Bishop said the following:
Unlikely I think. As I said, I've got several machines on the same LAN:
the 5.3's misbehave; the others don't.
#define CLOCK_ALLAN 1500.
...
doubleallan_xpt = CLOCK_ALLAN;
...
if (ULOGTOD(sys_poll) allan_xpt / 2) {
...
if I understand the above random lines of code in
contrib/ntp/ntpd/ntp_loopfilter.c correctly, then PLL-FLL switch
occurs when polling interval goes 512-1024, which is perfectly
possible under certain conditions with default ntp settings: minpoll=64,
maxpoll=1024 if ntp.conf(5) can be trusted.
Note that this code doesn't exist in 5.3. It was introduced sometime
between 5.3 and 5.4. In any case, looking at the associated comments,
this only affects the FLL/PLL loop gain.
The FLL/PLL switch is set is in sys/kern/kern_ntptime.c:hardupdate()
using:
time_status = ~STA_MODE;
if (mtemp = MINSEC (time_status STA_FLL || mtemp MAXSEC)) {
L_LINT(ftemp, (time_monitor 4) / mtemp);
L_RSHIFT(ftemp, SHIFT_FLL + 4);
L_ADD(time_freq, ftemp);
time_status |= STA_MODE;
}
and this code hasn't changed. MINSEC is 256 (which matches the comments)
MAXSEC is either 1200 or 2048 (depending on which header file is active),
though the comments imply it is 1024. mtime is the time since the last
adjustment (call to hardupdate()).
STA_FLL is set in ntpd/ntp_loopfilter.c:
if (sys_poll NTP_MAXDPOLL)
ntv.status |= STA_FLL;
though the associated comment states for legacy only. (And I'm
never seeing STA_FLL transitions in syslog). This sets STA_FLL if the
polling interval is 2^10 (1024). By default, sys_poll is limited to
NTP_MAXDPOLL so this should never occur. (You can over-ride it with
maxpoll N on peer/server config lines).
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel NTP flipping between FLL and PLL modes
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 14:04 01/04/2005, David Magda wrote: 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. [etc] 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 -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 17:38 01/04/2005, Andriy Gapon wrote: [...] I suppose that it might be possible that the root cause is in my local network conditions, [etc] Unlikely I think. As I said, I've got several machines on the same LAN: the 5.3's misbehave; the others don't. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On Fri, Apr 01, 2005 at 02:24:50PM +0100, Bob Bishop 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. [etc] 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. On my amd64 box I also get the mode flipping, but I don't get resets. Roland -- R.F. Smith /\ASCII Ribbon Campaign r s m i t h @ x s 4 a l l . n l \ /No HTML/RTF in e-mail http://www.xs4all.nl/~rsmith/ X No Word docs in e-mail public key: http://www.keyserver.net / \Respect for open standards pgptsRdgdtWzR.pgp Description: PGP signature
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 18:42 01/04/2005, Roland Smith wrote: On my amd64 box I also get the mode flipping, but I don't get resets. Hmm. I am getting resets on my amd64. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On Fri, 2005-Apr-01 19:38:41 +0300, Andriy Gapon wrote: 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 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 ... 2001-6001 flips do not trouble me a bit (but annoying), time resets are not a good thing definitely. I've seen similar reset behaviour in the past. The investigating I did suggested that the PLL could become unstable under some conditions (though I never managed to work out exactly what triggered the mis-behaviour). It would either lock up around +/- 500ppm and regularly jump in one direction to compensate or it would start swinging wildly and regularly jump back and forth with the net time jumped close to zero (in the latter case, looking at the loopstats showed that the frequency offset would start oscillating with the swings getting larger over time). Manually setting ntp.drift to a realistic value and restarting ntpd seemed to cure the problem (at least temporarily). I haven't seen that problem recently - I think it was in the early 4.x period. I suppose that it might be possible that the root cause is in my local network conditions, If it is network conditions, enabling huff-puff might help. If possible, work out what the real drift on that system is and re-initialise ntp.drift as well. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On Apr 1, 2005, at 12:56 PM, Bob Bishop wrote: At 18:42 01/04/2005, Roland Smith wrote: On my amd64 box I also get the mode flipping, but I don't get resets. Hmm. I am getting resets on my amd64. On my dual opteron, I get flipping perhaps a handful of times per day (5.4-PRE/amd64 from march 22). On my Xeon EMT64 with hyperthreading (5.3-STABLE/amd64 from Jan 7), it happens every 2-6 hours. My 5.3-REL/i386 Xeon with hyperthreading does it about two or four times per day, no resetting. Neither one shows time step resets. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
