> > 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.
I saw the difference getting bigger, too, in some cases, even after setting the clock correctly via BIOS menu before restarting, like here for example, from an old log: Nov 21 23:30:31 darkone ntpd[2328]: ntp engine ready Nov 21 23:30:51 darkone ntpd[2328]: peer 192.168.0.21 now valid Nov 21 23:30:53 darkone ntpd[2328]: peer 192.168.0.22 now valid Nov 21 23:31:46 darkone ntpd[31771]: adjusting local clock by 0.919561s Nov 21 23:32:51 darkone ntpd[31771]: adjusting local clock by 0.931284s Nov 21 23:36:03 darkone ntpd[31771]: adjusting local clock by 1.074941s Nov 21 23:37:06 darkone ntpd[31771]: adjusting local clock by 1.057853s Nov 21 23:39:11 darkone ntpd[31771]: adjusting local clock by 1.081091s Nov 21 23:42:53 darkone ntpd[31771]: adjusting local clock by 1.200674s Nov 21 23:45:32 darkone ntpd[31771]: adjusting local clock by 1.219525s Nov 21 23:49:57 darkone ntpd[31771]: adjusting local clock by 1.013382s and so on. It stayed at ~1 sec. correction every 3 minutes then, and the clock never synced. IIRC, without ntpd my clock is roughly 1.5 hours off per day, that's why I thought about fixing the hardware, even though it worked fine before with OpenBSD 4.1. > 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. I tried that, but it didn't help in most cases, even not via BIOS menu. > 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. Yes, but even with a good ntpd.drift file (e.g. after the upgrade from 4.1), the clock made problems. But I'll keep that in mind, too. :-) And maybe the upgrade to the Dec. 4 snapshot helped in my case, too. I didn't follow the changes on ntpd though. Tas.
