Tasmanian Devil wrote:
I also had a similar problem after upgrading to 4.2-release, an
upgrade to the snapshot from Nov. 17 didn't help:
http://marc.info/?l=openbsd-misc&m=119602370303500&w=2
In that link, your clock was off by much, but it keep getting closer to
the real clock, so over time it would have sync. Or you could have
started it with -s, witch would have sync it at the start. You can see
that in your logs where the difference keep getting smaller. In my case,
the difference was getting bigger, so the limit couldn't correct as much
as it needed to to get in sync in the first place. Different problem.
Even though I didn't fix the hardware yet, now with the snapshot from
Dec. 4 installed, ntpd synced the clock fine, at least so far (for a
few days), and I didn't dare to reboot the system yet as I fear that
the clock might not sync again after that. ;-)
I wouldn't be afraid to do it. Then start with -s if need be, or do it
manually one time with rdate and then let ntp keep it in sync.
If the clock of my system makes problems again, I'll try Otto's diff.
Thank you for that, Otto! :-)
Otto's diff address situation where the clock was/is drifting more then
what the kernel allow it to correct. As put in the archive, you can
always create a somewhat close ntpd.drift in the worst case to get the
adjfreq to keep it in sync. The situation happen when you do not have a
ntpd.drift file to start with and your clock is way off and drift more
then what the correction can do at each try.
So, if you have a very bad clock, let say that drift at a rate of 10,000
ppm, then even Otto diff will not allow it to sync to start with, with a
new fresh install, but if you put a file ntpd.drift with that correction
in it, then start ntpd, it may be able to keep it in sync as the
correction would be already apply then and the ntpd will adjust the time
delta from that point on.
As you can see below, it needed to have a correction allow > then the
limit of 500 ppm. So, the 5000 now allow for quick catch up and then
keep it in sync as well.
My log from the last few days:
Definitely in the range allow to be corrected and kept in sync.
$ cat /var/db/ntpd.drift
-6.015046e-05
If the limit of what ntpd can correct is +/- 500 ppm, then my clock
isn't as bad as I thought, but it made problems anyway, see the link
above.
The default is that and Otto's diff increase it to +/-5000. I guess
there is more bad clock in computers then I thought for sure.
I think the clocks in some computers are really cheap, but are still
in use, so if Otto's diff has no negative side effects, a bit less
strict limits could be useful for us all.
Best,
Daniel
