Re: ntpd not adjusting system clock
* Christian Weisgerber na...@mips.inka.de [2012-05-28 23:54]: Zi Loff zel...@zeloff.org wrote: Is the clock drift just to large for ntpd/adjtime/adjfreq to handle properly? I forgot what the maximum is that ntpd can handle, but yes, it looks like the drift is just too large. nitpick: ntpd doesn't have a limit. adjtime() has limits. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: ntpd not adjusting system clock
Thanks for all the replies. I'm giving clockspeed a try. So far so good, but I'll only have definite results in a day or two. I'll post my findings. Anyway, I'll start looking for newer hardware and arrange a proper burial for this crappy and brave machine... --
Re: ntpd not adjusting system clock
On Tue, May 29, 2012 at 01:07:57PM +0100, Zi Loff wrote: I'm giving clockspeed a try. So far so good, but I'll only have definite results in a day or two. I'll post my findings. Strike that. Clockspeed didn't work (terminates immediately without giving feedback) and honestly I didn't bother to find out what was going wrong. I'm running rdate every minute via cron as a temporary fix, until the new HP N40L I got for under 200 euros (no HD nor DVD) arrives. :) Once again, many thanks for all the input. Zi --
Re: ntpd not adjusting system clock
Zi Loff zel...@zeloff.org wrote: I'm running rdate every minute via cron as a temporary fix, until the new HP N40L I got for under 200 euros (no HD nor DVD) arrives. :) So you jump the clock every minute? For the archives: That's about the worst possible thing to do. -- Christian naddy Weisgerber na...@mips.inka.de
Re: ntpd not adjusting system clock
For the archives: That's about the worst possible thing to do. It's actually worse than it sounds. It jumps *backwards* every minute... I really don't know what else to do, actually... Let it drift? (not a rethorical question)... As for now the only visible problem seems to be future dates on mail envelopes, and I can live with that for a couple of days, but this isn't a viable solution for more than that... Plus I'm not sure if my ISP's SMTP relay will like to play along. I'll just hope the new machine gets delivered quickly...
Re: ntpd not adjusting system clock
On Mon, May 28, 2012 at 12:46:45PM +0100, Zi Loff wrote: I have a mail server which syncs its clock to a local ntp server. This time server in turn syncs itself with a number of public servers and is working correctly, as far as I can tell (ntpd -dv shows offsets under 1ms). However, the mail server (an _old_ Pentium III @ 500Mhz) started drifting furiously, and the ntpd (client) doesn't appear to be actually adjusting the local clock, although it sets it correctly (if ntpd -s). The time server is a Soekris net4801, the mail server is an _old_ x86 box (Pentium III 500Mhz). Both boxes run 5.0. $ sudo ntpd -svd ntp engine ready reply from 10.17.16.2: offset -5.781745 delay 0.001901, next query 8s set local clock to Mon May 28 12:22:39 WEST 2012 (offset -5.781745s) reply from 10.17.16.2: offset -0.249842 delay 0.001821, next query 7s reply from 10.17.16.2: offset -0.471290 delay 0.001870, next query 8s peer 10.17.16.2 now valid reply from 10.17.16.2: offset -0.724371 delay 0.001822, next query 8s reply from 10.17.16.2: offset -0.977404 delay 0.001875, next query 9s reply from 10.17.16.2: offset -1.262066 delay 0.001814, next query 5s reply from 10.17.16.2: offset -1.420363 delay 0.001776, next query 31s reply from 10.17.16.2: offset -2.400023 delay 0.001832, next query 33s adjusting local clock by -1.420363s reply from 10.17.16.2: offset -2.057283 delay 0.001924, next query 34s reply from 10.17.16.2: offset -3.131575 delay 0.001821, next query 34s reply from 10.17.16.2: offset -4.201259 delay 0.001737, next query 34s reply from 10.17.16.2: offset -5.275638 delay 0.001835, next query 31s reply from 10.17.16.2: offset -6.255265 delay 0.001849, next query 31s reply from 10.17.16.2: offset -7.234918 delay 0.001811, next query 31s reply from 10.17.16.2: offset -8.214601 delay 0.001750, next query 31s adjusting local clock by -4.481622s reply from 10.17.16.2: offset -5.024796 delay 0.001837, next query 31s reply from 10.17.16.2: offset -6.004269 delay 0.001842, next query 30s reply from 10.17.16.2: offset -6.947157 delay 0.002090, next query 32s reply from 10.17.16.2: offset -7.958516 delay 0.001831, next query 32s ... As you can notice, the drift is of about 2s/min which is huge and quicky amounts to a few hours and the next thing I know I'm getting mails which were sent tomorrow... Is this drift too large to be adjusted smoothly by ntpd? And if so, any idea as to what might be causing this? Many thanks Zi Loff -- Correction: I realize it is adjusting the lock (offset diminishes after adjustment). The output above does not show the behaviour I referred to. I'm looking further into this, and I'll post some more info later. Sorry about the noise. (that is a big drift, though...) --
Re: ntpd not adjusting system clock
OK, let me try this again: Old x86 desktop box (Pentium III @ 500MHz) running 5.0. Machine has been on 24/7 for the past few years (minus the occasional PSU replacement), serving mail and http under very light loads. Its local clock is drifting. A lot. Without ntpd running: # date; rdate -nv ntp.phistat.com; sleep 1200; date; rdate -nv \ ntp.phistat.com Mon May 28 17:12:07 WEST 2012 Mon May 28 17:11:36 WEST 2012 rdate: adjust local clock by -30.124462 seconds Mon May 28 17:31:37 WEST 2012 Mon May 28 17:30:59 WEST 2012 rdate: adjust local clock by -37.912744 seconds So that's about a 38s offset in 20 minutes. When running ntpd: # ntpd -sdv ntp engine ready reply from 10.17.16.2: offset -293.664414 delay 0.001944, next query 8s set local clock to Mon May 28 20:01:01 WEST 2012 (offset -293.664414s) reply from 10.17.16.2: offset -0.253115 delay 0.001728, next query 6s reply from 10.17.16.2: offset -0.442993 delay 0.001704, next query 5s peer 10.17.16.2 now valid reply from 10.17.16.2: offset -0.601451 delay 0.001323, next query 5s reply from 10.17.16.2: offset -0.759521 delay 0.001758, next query 7s reply from 10.17.16.2: offset -0.980987 delay 0.001775, next query 6s reply from 10.17.16.2: offset -1.170839 delay 0.001795, next query 33s reply from 10.17.16.2: offset -2.213734 delay 0.001826, next query 32s adjusting local clock by -0.601451s reply from 10.17.16.2: offset -2.626567 delay 0.002090, next query 34s reply from 10.17.16.2: offset -3.732722 delay 0.001811, next query 34s reply from 10.17.16.2: offset -4.802128 delay 0.001883, next query 32s reply from 10.17.16.2: offset -5.812614 delay 0.001804, next query 32s adjusting local clock by -0.158070s clock is now synced reply from 10.17.16.2: offset -6.666142 delay 0.001363, next query 30s adjusting local clock by -6.666142s reply from 10.17.16.2: offset -0.948669 delay 0.001233, next query 30s reply from 10.17.16.2: offset -1.896441 delay 0.001815, next query 31s reply from 10.17.16.2: offset -2.876058 delay 0.001887, next query 31s reply from 10.17.16.2: offset -3.887582 delay 0.001791, next query 34s reply from 10.17.16.2: offset -4.956985 delay 0.001778, next query 30s reply from 10.17.16.2: offset -5.904974 delay 0.001913, next query 31s reply from 10.17.16.2: offset -6.884482 delay 0.002125, next query 34s reply from 10.17.16.2: offset -7.959015 delay 0.001858, next query 34s adjusting local clock by -6.359810s clock is now unsynced reply from 10.17.16.2: offset -8.084752 delay 0.001801, next query 31s adjusting local clock by -10.198126s reply from 10.17.16.2: offset -5.056171 delay 0.001622, next query 34s reply from 10.17.16.2: offset -6.162315 delay 0.001810, next query 30s reply from 10.17.16.2: offset -7.105366 delay 0.001770, next query 32s reply from 10.17.16.2: offset -8.116619 delay 0.001682, next query 30s adjusting local clock by -14.619296s ... While the ntpd client was running, $ while true; do date; sleep 1; done showed a steady sequence of seconds, albeit the 'adjustments' claimed by the ntpd client, although I'm not sure if this is normal or not. Nevertheless, the offset seems to shrink after each 'ajusting local clock', judging from the ntpd output, but it just keeps growing in a kind of a sawtooth pattern. Is the clock drift just to large for ntpd/adjtime/adjfreq to handle properly? If so, is there any 'cure' on the software side? And for extra points: Any clues on why this is happening? Ageing harware? Faulty PSU? Many thanks Ze' Loff
Re: ntpd not adjusting system clock
2012/5/28 Zi Loff zel...@zeloff.org: Is the clock drift just to large for ntpd/adjtime/adjfreq to handle properly? If so, is there any 'cure' on the software side? Yes. Not with ntpd; you could run ntpdate from cron, but then your clock would jump. And for extra points: Any clues on why this is happening? Ageing harware? Faulty PSU? Ageing hardware. Get a new one. :-) Best Martin
Re: ntpd not adjusting system clock
Zi Loff zel...@zeloff.org wrote:
Is the clock drift just to large for ntpd/adjtime/adjfreq to handle
properly?
I forgot what the maximum is that ntpd can handle, but yes, it looks
like the drift is just too large.
If so, is there any 'cure' on the software side?
You could try a different kern.timecounter.hardware setting, but
on such an old machine there is probably little choice.
$ sysctl kern.timecounter.{hardware,choice}
Another idea that comes to mind--I've never tried this--is to preload
an adjfreq(2) value into /var/db/ntpd.drift.
--
Christian naddy Weisgerber na...@mips.inka.de
Re: ntpd not adjusting system clock
On 05/28/12 15:25, Zi Loff wrote: OK, let me try this again: Old x86 desktop box (Pentium III @ 500MHz) running 5.0. Machine has been on 24/7 for the past few years (minus the occasional PSU replacement), serving mail and http under very light loads. Its local clock is drifting. A lot. Without ntpd running: # date; rdate -nv ntp.phistat.com; sleep 1200; date; rdate -nv \ ntp.phistat.com Mon May 28 17:12:07 WEST 2012 Mon May 28 17:11:36 WEST 2012 rdate: adjust local clock by -30.124462 seconds Mon May 28 17:31:37 WEST 2012 Mon May 28 17:30:59 WEST 2012 rdate: adjust local clock by -37.912744 seconds So that's about a 38s offset in 20 minutes. When running ntpd: # ntpd -sdv ntp engine ready reply from 10.17.16.2: offset -293.664414 delay 0.001944, next query 8s set local clock to Mon May 28 20:01:01 WEST 2012 (offset -293.664414s) reply from 10.17.16.2: offset -0.253115 delay 0.001728, next query 6s reply from 10.17.16.2: offset -0.442993 delay 0.001704, next query 5s peer 10.17.16.2 now valid reply from 10.17.16.2: offset -0.601451 delay 0.001323, next query 5s reply from 10.17.16.2: offset -0.759521 delay 0.001758, next query 7s reply from 10.17.16.2: offset -0.980987 delay 0.001775, next query 6s reply from 10.17.16.2: offset -1.170839 delay 0.001795, next query 33s reply from 10.17.16.2: offset -2.213734 delay 0.001826, next query 32s adjusting local clock by -0.601451s reply from 10.17.16.2: offset -2.626567 delay 0.002090, next query 34s reply from 10.17.16.2: offset -3.732722 delay 0.001811, next query 34s reply from 10.17.16.2: offset -4.802128 delay 0.001883, next query 32s reply from 10.17.16.2: offset -5.812614 delay 0.001804, next query 32s adjusting local clock by -0.158070s clock is now synced reply from 10.17.16.2: offset -6.666142 delay 0.001363, next query 30s adjusting local clock by -6.666142s reply from 10.17.16.2: offset -0.948669 delay 0.001233, next query 30s reply from 10.17.16.2: offset -1.896441 delay 0.001815, next query 31s reply from 10.17.16.2: offset -2.876058 delay 0.001887, next query 31s reply from 10.17.16.2: offset -3.887582 delay 0.001791, next query 34s reply from 10.17.16.2: offset -4.956985 delay 0.001778, next query 30s reply from 10.17.16.2: offset -5.904974 delay 0.001913, next query 31s reply from 10.17.16.2: offset -6.884482 delay 0.002125, next query 34s reply from 10.17.16.2: offset -7.959015 delay 0.001858, next query 34s adjusting local clock by -6.359810s clock is now unsynced reply from 10.17.16.2: offset -8.084752 delay 0.001801, next query 31s adjusting local clock by -10.198126s reply from 10.17.16.2: offset -5.056171 delay 0.001622, next query 34s reply from 10.17.16.2: offset -6.162315 delay 0.001810, next query 30s reply from 10.17.16.2: offset -7.105366 delay 0.001770, next query 32s reply from 10.17.16.2: offset -8.116619 delay 0.001682, next query 30s adjusting local clock by -14.619296s ... While the ntpd client was running, $ while true; do date; sleep 1; done showed a steady sequence of seconds, albeit the 'adjustments' claimed by the ntpd client, although I'm not sure if this is normal or not. Nevertheless, the offset seems to shrink after each 'ajusting local clock', judging from the ntpd output, but it just keeps growing in a kind of a sawtooth pattern. Is the clock drift just to large for ntpd/adjtime/adjfreq to handle properly? If so, is there any 'cure' on the software side? And for extra points: Any clues on why this is happening? Ageing harware? Faulty PSU? Many thanks Ze' Loff Going way back to my i386 and i486 days, clock drift was sometimes the result of the battery that backed up the bios losing its charge. Some early clocks were like old pre quartz electrical watches. If the battery ran down, the watch ran slowly. You seem to mention that your problem is that the clock is running too fast. I would suspect that this is a hardware issue that you do not want to spend any money on. If you can fix it via a software setting change such as an incredibly frequent cron job, wonderful. If the machine is at all critical, you may want to spend a minimal amount of money to replace it with a new machine. Ralph Ellis
