Re: clock drift in -CURRENT
Daniel Rock schrieb: My kernel war relatively recent at the time of last boot - build around March 2nd from -CURRENT sources a few hours before. If someone runs -CURRENT with default HZ of 100 and moans 247 days later, his -CURRENT cannot be called -CURRENT any more... I am now running an up-to-date -CURRENT. I have set HZ=1, so I don't have to wait another 50 days. Hope this high HZ value has no negative impact on the test. I will inform you in 3 days if anything strange happens again. I had run the kernel now for over 2^31 clock ticks and had no drifting problem so far. I will now set HZ back to 500 - let's see what happens in 50 days... Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
clock drift in -CURRENT
Hi, after almost 50 days of uptime I suddenly noticed an extreme clock drift in current. Here is an excerpt from my /var/log/messages (March 8th was my last reboot time): Mar 8 18:38:07 gate syslogd: kernel boot file is /boot/kernel/kernel Mar 8 18:38:07 gate kernel: Copyright (c) 1992-2002 The FreeBSD Project. [...] Apr 27 20:03:10 gate ntpd[157]: time reset -0.250532 s Apr 27 20:18:14 gate ntpd[157]: time reset 0.446208 s Apr 27 20:39:57 gate ntpd[157]: time reset -0.820100 s Apr 27 21:11:19 gate ntpd[157]: time reset 0.887949 s Apr 27 21:25:33 gate ntpd[157]: time reset -0.228488 s Apr 27 21:54:35 gate ntpd[157]: time reset -0.395676 s Apr 28 12:59:15 gate ntpd[157]: time reset -0.381327 s Apr 28 13:19:52 gate ntpd[157]: time reset 0.815323 s Apr 28 13:31:50 gate ntpd[157]: time reset 0.844171 s Apr 28 13:58:52 gate ntpd[157]: time reset 1.447538 s Apr 28 14:14:58 gate ntpd[157]: time reset 0.915263 s Apr 28 14:36:38 gate ntpd[157]: time reset 0.860966 s Apr 28 14:47:29 gate ntpd[157]: time reset 0.984839 s Apr 28 15:06:59 gate ntpd[157]: time reset 1.025584 s Apr 28 15:27:32 gate ntpd[157]: time reset 1.156623 s Apr 28 15:48:59 gate ntpd[157]: time reset 0.896726 s Apr 28 16:00:52 gate ntpd[157]: time reset 0.973291 s Apr 28 16:24:24 gate ntpd[157]: time reset 1.212415 s Apr 28 16:37:19 gate ntpd[157]: time reset 0.859379 s Apr 28 16:56:49 gate ntpd[157]: time reset 0.914863 s Apr 28 17:13:05 gate ntpd[157]: time reset 1.100234 s Apr 28 17:35:59 gate ntpd[157]: time reset 1.231416 s Apr 28 17:59:53 gate ntpd[157]: time reset 1.026558 s Apr 28 18:11:59 gate ntpd[157]: time reset 0.995554 s Apr 28 18:34:45 gate ntpd[157]: time reset 1.140261 s Apr 28 18:54:19 gate ntpd[157]: time reset 0.856611 s Apr 28 19:07:15 gate ntpd[157]: time reset 1.094226 s Apr 28 19:22:30 gate ntpd[157]: time reset 0.879816 s Apr 28 19:47:25 gate ntpd[157]: time reset 1.332108 s Apr 28 20:06:56 gate ntpd[157]: time reset 0.949128 s Apr 28 20:28:27 gate ntpd[157]: time reset 0.906657 s Apr 28 20:41:37 gate ntpd[157]: time reset 0.877976 s Apr 28 20:57:57 gate ntpd[157]: time reset 1.103012 s Apr 28 21:28:19 gate ntpd[157]: time reset 1.607870 s Apr 28 21:59:43 gate ntpd[157]: time reset 1.253603 s Apr 28 22:14:46 gate ntpd[157]: time reset 1.181729 s Apr 28 22:47:13 gate ntpd[157]: time reset 1.573263 s Apr 28 23:07:47 gate ntpd[157]: time reset 0.836291 s Apr 28 23:20:52 gate ntpd[157]: time reset 1.105955 s Apr 28 23:35:59 gate ntpd[157]: time reset 0.839469 s [...] So the machine is losing a second every 20 minutes. After a reboot everything was OK again. The drift began exactly at the moment the counter for clock interrupts got past the 2^31 mark (I have HZ=500 in the kernel): 500 ticks/s * 49.7 days ~ 2^31 ticks After a reboot everything went ok again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg Thanks! Poul-Henning In message [EMAIL PROTECTED], Daniel Rock writes: Hi, after almost 50 days of uptime I suddenly noticed an extreme clock drift in current. Here is an excerpt from my /var/log/messages (March 8th was my last reboot time): Mar 8 18:38:07 gate syslogd: kernel boot file is /boot/kernel/kernel Mar 8 18:38:07 gate kernel: Copyright (c) 1992-2002 The FreeBSD Project. [...] Apr 27 20:03:10 gate ntpd[157]: time reset -0.250532 s Apr 27 20:18:14 gate ntpd[157]: time reset 0.446208 s Apr 27 20:39:57 gate ntpd[157]: time reset -0.820100 s Apr 27 21:11:19 gate ntpd[157]: time reset 0.887949 s Apr 27 21:25:33 gate ntpd[157]: time reset -0.228488 s Apr 27 21:54:35 gate ntpd[157]: time reset -0.395676 s Apr 28 12:59:15 gate ntpd[157]: time reset -0.381327 s Apr 28 13:19:52 gate ntpd[157]: time reset 0.815323 s Apr 28 13:31:50 gate ntpd[157]: time reset 0.844171 s Apr 28 13:58:52 gate ntpd[157]: time reset 1.447538 s Apr 28 14:14:58 gate ntpd[157]: time reset 0.915263 s Apr 28 14:36:38 gate ntpd[157]: time reset 0.860966 s Apr 28 14:47:29 gate ntpd[157]: time reset 0.984839 s Apr 28 15:06:59 gate ntpd[157]: time reset 1.025584 s Apr 28 15:27:32 gate ntpd[157]: time reset 1.156623 s Apr 28 15:48:59 gate ntpd[157]: time reset 0.896726 s Apr 28 16:00:52 gate ntpd[157]: time reset 0.973291 s Apr 28 16:24:24 gate ntpd[157]: time reset 1.212415 s Apr 28 16:37:19 gate ntpd[157]: time reset 0.859379 s Apr 28 16:56:49 gate ntpd[157]: time reset 0.914863 s Apr 28 17:13:05 gate ntpd[157]: time reset 1.100234 s Apr 28 17:35:59 gate ntpd[157]: time reset 1.231416 s Apr 28 17:59:53 gate ntpd[157]: time reset 1.026558 s Apr 28 18:11:59 gate ntpd[157]: time reset 0.995554 s Apr 28 18:34:45 gate ntpd[157]: time reset 1.140261 s Apr 28 18:54:19 gate ntpd[157]: time reset 0.856611 s Apr 28 19:07:15 gate ntpd[157]: time reset 1.094226 s Apr 28 19:22:30 gate ntpd[157]: time reset 0.879816 s Apr 28 19:47:25 gate ntpd[157]: time reset 1.332108 s Apr 28 20:06:56 gate ntpd[157]: time reset 0.949128 s Apr 28 20:28:27 gate ntpd[157]: time reset 0.906657 s Apr 28 20:41:37 gate ntpd[157]: time reset 0.877976 s Apr 28 20:57:57 gate ntpd[157]: time reset 1.103012 s Apr 28 21:28:19 gate ntpd[157]: time reset 1.607870 s Apr 28 21:59:43 gate ntpd[157]: time reset 1.253603 s Apr 28 22:14:46 gate ntpd[157]: time reset 1.181729 s Apr 28 22:47:13 gate ntpd[157]: time reset 1.573263 s Apr 28 23:07:47 gate ntpd[157]: time reset 0.836291 s Apr 28 23:20:52 gate ntpd[157]: time reset 1.105955 s Apr 28 23:35:59 gate ntpd[157]: time reset 0.839469 s [...] So the machine is losing a second every 20 minutes. After a reboot everything was OK again. The drift began exactly at the moment the counter for clock interrupts got past the 2^31 mark (I have HZ=500 in the kernel): 500 ticks/s * 49.7 days ~ 2^31 ticks After a reboot everything went ok again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
On Wed, 1 May 2002, Poul-Henning Kamp wrote: When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) From kern_clock.c: %%% int ticks; %%% but this is treated as an cyclic counter so its overflow shouldn't matter on machines where overflow doesn't trap. [context lost to top posting] Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
I had the same symptoms (drifting about 2 minutes an hour) on sources before April 17 or so. Since then, ntpd has only logged 5 time updates, as opposed to 3 per hour. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
Poul-Henning Kamp schrieb: When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg [...] My kernel war relatively recent at the time of last boot - build around March 2nd from -CURRENT sources a few hours before. If someone runs -CURRENT with default HZ of 100 and moans 247 days later, his -CURRENT cannot be called -CURRENT any more... I am now running an up-to-date -CURRENT. I have set HZ=1, so I don't have to wait another 50 days. Hope this high HZ value has no negative impact on the test. I will inform you in 3 days if anything strange happens again. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
In message [EMAIL PROTECTED], Daniel Rock writes: Poul-Henning Kamp schrieb: When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg [...] My kernel war relatively recent at the time of last boot - build around March 2nd from -CURRENT sources a few hours before. Right, but look at a cvs log src/sys/kern/kern_tc.c... I've fixed at least one bug in the NTP steering since then. If someone runs -CURRENT with default HZ of 100 and moans 247 days later, his -CURRENT cannot be called -CURRENT any more... :-) I am now running an up-to-date -CURRENT. I have set HZ=1, so I don't have to wait another 50 days. Hope this high HZ value has no negative impact on the test. I will inform you in 3 days if anything strange happens again. Cool. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: clock drift in -CURRENT
Bill Fenner schrieb: I had the same symptoms (drifting about 2 minutes an hour) on sources before April 17 or so. Since then, ntpd has only logged 5 time updates, as opposed to 3 per hour. The drift wasn't visible immediately, but only after the magical 49.7 days or 2^31 clock ticks. Before that I had the usual corrections if you run ntp over a dialup line with large variations in round trip times (around one correction every few days). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock Drift
On Tuesday 30 October 2001 06:17 pm, Dreamtime.net Inc. wrote: A while back I read a thread regarding clock drift. We are now having the same problem. Does anyone know what the remedy is for this? Thanks. Sincerely, Stephen H. Kapit I had the same problem a couple of months ago. Try adding the follwing to your kernel config: options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION worked for me. Beech -- Micro$oft: Where can we make you go today? --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Clock Drift
A while back I read a thread regarding clock drift. We are now having the same problem. Does anyone know what the remedy is for this? Thanks. Sincerely, Stephen H. Kapit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
