Re: time drift
Bruce Cran wrote: Volker Jahns wrote: On Thu, May 15, 2008 at 09:53:02PM +0200, Volker Jahns wrote: On Thu, May 15, 2008 at 12:18:57PM -0700, Chuck Swiger wrote: On May 15, 2008, at 11:57 AM, Volker Jahns wrote: FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec You should also take a look at the output of sysctl kern.timecounter, and possibly switch to a different mechanism, if the existing choice doesn't work out well for your machine... Thanks for the hint. A few years ago a time drift problem had been observed by a German freebsd user (http://www.freebsd.de/rachive/de-bsd-questions.200304/0643.html). Time drift 15 sec every half hour, ntpd dies away running on his machine. Setting kern.timecounter.hardware to TSC had been recommended as a solution. There's also a FreeBSD PR open about this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/123462 sysctl -w kern.timecounter.hardware=TSC and then this: 16 May 08:37:01 ntpdate[28819]: adjust time server 192.53.103.108 offset -0.347027 sec 16 May 09:07:00 ntpdate[29258]: adjust time server 192.53.103.108 offset -0.313608 sec 16 May 09:37:00 ntpdate[29492]: adjust time server 192.53.103.108 offset -0.314357 sec 16 May 10:07:00 ntpdate[29826]: adjust time server 192.53.103.108 offset -0.313694 sec 16 May 10:37:00 ntpdate[30203]: adjust time server 192.53.103.108 offset -0.313976 sec 16 May 11:07:00 ntpdate[30886]: adjust time server 192.53.103.108 offset -0.314679 sec (Please note the use of ntpdate is for debugging purposes only, this is _not_ an ntp issue) -- Volker Jahns, [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
Volker Jahns wrote: Bruce Cran wrote: Volker Jahns wrote: On Thu, May 15, 2008 at 09:53:02PM +0200, Volker Jahns wrote: On Thu, May 15, 2008 at 12:18:57PM -0700, Chuck Swiger wrote: On May 15, 2008, at 11:57 AM, Volker Jahns wrote: FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec You should also take a look at the output of sysctl kern.timecounter, and possibly switch to a different mechanism, if the existing choice doesn't work out well for your machine... Thanks for the hint. A few years ago a time drift problem had been observed by a German freebsd user (http://www.freebsd.de/rachive/de-bsd-questions.200304/0643.html). Time drift 15 sec every half hour, ntpd dies away running on his machine. Setting kern.timecounter.hardware to TSC had been recommended as a solution. There's also a FreeBSD PR open about this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/123462 sysctl -w kern.timecounter.hardware=TSC and then this: 16 May 08:37:01 ntpdate[28819]: adjust time server 192.53.103.108 offset -0.347027 sec 16 May 09:07:00 ntpdate[29258]: adjust time server 192.53.103.108 offset -0.313608 sec 16 May 09:37:00 ntpdate[29492]: adjust time server 192.53.103.108 offset -0.314357 sec 16 May 10:07:00 ntpdate[29826]: adjust time server 192.53.103.108 offset -0.313694 sec (Please note the use of ntpdate is for debugging purposes only, this is _not_ an ntp issue) Finally I want to come back to the time drift issue and howto improve it. Setting kern.timecounter.hardware: i8254 machdep.i8254_freq: 1193182 16 May 12:07:01 ntpdate[31752]: adjust time server 192.53.103.108 offset -0.404453 sec 16 May 12:37:00 ntpdate[32425]: adjust time server 192.53.103.108 offset -0.396156 sec 16 May 13:07:01 ntpdate[32787]: adjust time server 192.53.103.108 offset -0.383712 sec 16 May 13:37:01 ntpdate[33126]: adjust time server 192.53.103.108 offset -0.387233 sec Clock is too slow, frequency must be increased. Corrected machdep.i8254_freq from 1193182 to 1193448 16 May 17:37:00 ntpdate[36310]: adjust time server 192.53.103.108 offset -0.033320 sec 16 May 18:07:01 ntpdate[36632]: adjust time server 192.53.103.108 offset -0.053532 sec 16 May 18:37:00 ntpdate[37011]: adjust time server 192.53.103.108 offset -0.043264 sec 16 May 19:07:01 ntpdate[37361]: adjust time server 192.53.103.108 offset -0.055725 sec Time drift is now only about 50 millisecs per half an hour. -- Volker Jahns, [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On May 15, 2008, at 11:57 AM, Volker Jahns wrote: FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec While you should run ntpdate -b at system boot, running ntpdate periodically via cron is not the right thing to do-- you should run ntpd instead, and that will figure out the intrinsic correction your chosen system clock needs to keep better time via the ntp.drift file. You should also take a look at the output of sysctl kern.timecounter, and possibly switch to a different mechanism, if the existing choice doesn't work out well for your machine... Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: time drift
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Volker Jahns Sent: Thursday, May 15, 2008 2:58 PM To: freebsd-questions@freebsd.org Cc: [EMAIL PROTECTED] Subject: time drift FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec FreeBSD 7.0 on an otherwise almost identical system has a time drift of a few millisecs every half hour. 15 May 10:35:00 ntpdate[7999]: adjust time server 192.53.103.108 offset 0.009963 sec 15 May 10:35:51 ntpdate[8007]: adjust time server 192.53.103.108 offset -0.004890 sec 15 May 10:50:00 ntpdate[8042]: adjust time server 192.53.103.108 offset 0.010734 sec 15 May 11:05:00 ntpdate[8088]: adjust time server 192.53.103.108 offset 0.004523 sec 15 May 11:20:01 ntpdate[8114]: adjust time server 192.53.103.108 offset 0.005800 sec The 6.2 system is a production system, has a uptime of almost 300 days and I don't want to experiment a lot with acpi, battery or so. What would be your suspicion on the large time drift of the FreeBSD 6.2 system? -- Volker Jahns, [EMAIL PROTECTED] -- It loses 28 seconds per hour 28/3600 = 0.007, or less than 1 percent slow. That is well within normal parts tolerances for a new computer, and the drift usually gets worse as the hardware ages. I believe you are also looking at the software clock, not the hardware clock. The latter may be a little more accurate, since the former may be slowed down by interrupts and software that disables them. Install ntpd and let it adjust the clock for you. Bob McConnell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On Thu, May 15, 2008 at 12:18:57PM -0700, Chuck Swiger wrote: On May 15, 2008, at 11:57 AM, Volker Jahns wrote: FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec While you should run ntpdate -b at system boot, running ntpdate periodically via cron is not the right thing to do-- you should run ntpd instead, and that will figure out the intrinsic correction your chosen system clock needs to keep better time via the ntp.drift file. Running ntpd on this system results in time drift of approx. 1-2 hrs a day. That is not an acceptable option. You should also take a look at the output of sysctl kern.timecounter, and possibly switch to a different mechanism, if the existing choice doesn't work out well for your machine... Thanks for the hint. -- Volker Jahns, [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On Thu, May 15, 2008 at 09:53:02PM +0200, Volker Jahns wrote: On Thu, May 15, 2008 at 12:18:57PM -0700, Chuck Swiger wrote: On May 15, 2008, at 11:57 AM, Volker Jahns wrote: FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec You should also take a look at the output of sysctl kern.timecounter, and possibly switch to a different mechanism, if the existing choice doesn't work out well for your machine... Thanks for the hint. A few years ago a time drift problem had been observed by a German freebsd user (http://www.freebsd.de/rachive/de-bsd-questions.200304/0643.html). Time drift 15 sec every half hour, ntpd dies away running on his machine. Setting kern.timecounter.hardware to TSC had been recommended as a solution. -- Volker Jahns, [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On Thu, May 15, 2008 at 08:57:59PM +0200, Volker Jahns wrote: FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec [...] What would be your suspicion on the large time drift of the FreeBSD 6.2 system? Its PC commodity-grade. Not all that unusual even for stuff sold claiming to be a server. This is in no small part why ntpd exists. nptd calculates a correction coefficient and (under FreeBSD) stores it in /var/db/ntpd.drift for use on next start so as to more quickly establish a lock. So in short ntpd calibrates your clock in order to minimize the corrections required. Is The Right Thing To Do. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
David Kelly wrote: Its PC commodity-grade. Not all that unusual even for stuff sold claiming to be a server. This is in no small part why ntpd exists. nptd calculates a correction coefficient and (under FreeBSD) stores it in /var/db/ntpd.drift for use on next start so as to more quickly establish a lock. So in short ntpd calibrates your clock in order to minimize the corrections required. Is The Right Thing To Do. We run a large number of FreeBSD servers under vmware. We've seen ntpd silently die, because the drift becomes insane. What do others do in this situation? (We've resorted to croning ntpdate for VMs.) -- Chris Cowart Network Technical Lead Network Infrastructure Services, RSSP-IT UC Berkeley pgpU238ai1J1l.pgp Description: PGP signature
Re: time drift
Volker Jahns wrote: On Thu, May 15, 2008 at 09:53:02PM +0200, Volker Jahns wrote: On Thu, May 15, 2008 at 12:18:57PM -0700, Chuck Swiger wrote: On May 15, 2008, at 11:57 AM, Volker Jahns wrote: FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time server 192.53.103.108 offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time server 192.53.103.108 offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time server 192.53.103.108 offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time server 192.53.103.108 offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time server 192.53.103.108 offset -11.836499 sec You should also take a look at the output of sysctl kern.timecounter, and possibly switch to a different mechanism, if the existing choice doesn't work out well for your machine... Thanks for the hint. A few years ago a time drift problem had been observed by a German freebsd user (http://www.freebsd.de/rachive/de-bsd-questions.200304/0643.html). Time drift 15 sec every half hour, ntpd dies away running on his machine. Setting kern.timecounter.hardware to TSC had been recommended as a solution. There's also a FreeBSD PR open about this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/123462 -- Bruce ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On May 15, 2008, at 2:16 PM, Christopher Cowart wrote: We run a large number of FreeBSD servers under vmware. We've seen ntpd silently die, because the drift becomes insane. What do others do in this situation? (We've resorted to croning ntpdate for VMs.) You run ntpd in the parent OS, rather than in the emulated machines. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On Thu, 15 May 2008 at 14:16 -0700, [EMAIL PROTECTED] confabulated: David Kelly wrote: Its PC commodity-grade. Not all that unusual even for stuff sold claiming to be a server. This is in no small part why ntpd exists. nptd calculates a correction coefficient and (under FreeBSD) stores it in /var/db/ntpd.drift for use on next start so as to more quickly establish a lock. So in short ntpd calibrates your clock in order to minimize the corrections required. Is The Right Thing To Do. We run a large number of FreeBSD servers under vmware. We've seen ntpd silently die, because the drift becomes insane. What do others do in this situation? (We've resorted to croning ntpdate for VMs.) I've also found running FreeBSD 6.2, 6.1 and 6.0 in VMWare, I've had to reduce kern.hz in /boot/loader.conf. I had to reduce it to 50. Otherwise the clock really lost time. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On May 15, 2008, at 12:53 PM, Volker Jahns wrote: While you should run ntpdate -b at system boot, running ntpdate periodically via cron is not the right thing to do-- you should run ntpd instead, and that will figure out the intrinsic correction your chosen system clock needs to keep better time via the ntp.drift file. Running ntpd on this system results in time drift of approx. 1-2 hrs a day. That is not an acceptable option. Something's probably wrong with your hardware clock or there is something else going on, if it is really drifting at ~ 5% from real time. Sometimes replacing the battery on the motherboard fixes this. Does vmstat -i show exceptional interrupt load or anything like that? You should also take a look at the output of sysctl kern.timecounter, and possibly switch to a different mechanism, if the existing choice doesn't work out well for your machine... Thanks for the hint. Indeed, try using one of the other timesources and see whether that corrects the huge offsets you are reporting. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
On Thu, 15 May 2008, Christopher Cowart wrote: David Kelly wrote: Its PC commodity-grade. Not all that unusual even for stuff sold claiming to be a server. This is in no small part why ntpd exists. nptd calculates a correction coefficient and (under FreeBSD) stores it in /var/db/ntpd.drift for use on next start so as to more quickly establish a lock. So in short ntpd calibrates your clock in order to minimize the corrections required. Is The Right Thing To Do. We run a large number of FreeBSD servers under vmware. We've seen ntpd silently die, because the drift becomes insane. What do others do in this situation? (We've resorted to croning ntpdate for VMs.) kern.hz=100 in /boot/loader.conf solved this problem for me. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: time drift
FreeBSD 6.2 running on X86 hardware (FSC) shows a remarkable time drift running ntpdate every half hour shows that the system looses about 10-14 sec each time. 15 May 10:06:48 ntpdate[7200]: step time ... offset -13.799602 sec 15 May 10:36:48 ntpdate[7515]: step time ... offset -12.813941 sec 15 May 11:06:48 ntpdate[7879]: step time ... offset -13.651921 sec 15 May 11:36:50 ntpdate[8079]: step time ... offset -11.109298 sec 15 May 12:06:50 ntpdate[8289]: step time ... offset -11.836499 sec ... The 6.2 system is a production system, has a uptime of almost 300 days and I don't want to experiment a lot with acpi, battery or so. What would be your suspicion on the large time drift of the FreeBSD 6.2 system? With an uptime of nearly a year -- commendation to the power company -- and (I take it) a recently-developed problem, I'd be asking what might have changed shortly before the problem appeared. Is the system clock source by any chance the CMOS RTC? If so, I'd suspect that its battery may be dying. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
