Uwe Dippel wrote: > [Background: we now received the second batch of Proliant ML-350G4p with > dual core Xeon. I had pointed out earlier that bsd.mp performs a > miscalculation of the time-stamp by 2:1 on ML350G4. This is unresolved > despite all efforts and input; but goes into another thread.] > On the ML350G4p the time with bsd is 99.99% correct; with bsd.mp it is off > by around 5% (one hour per day). > I started openNTPD when the difference was around 1 hour, three days ago. > From then on, it has given regular messages (/var/log/daemon) about its > adjustments. But instead of gradually closing the gap, the gap has > continuously widened and now I am off by around 3 hours and the adjustment > message is at 9300 seconds. When it started, this was around 4000 seconds. > > Conclusion: openntpd is not able to 'pull in' the wrong time; it rather > only notes it and tries to adjust to an ever wider gap. > Probably it regulation parameters are fixed, and it cannot adjust a larger > disparity. > > Any hint welcome, > > Uwe
1) set time properly, using rdate or ntpd -s. 2) now how does it do? There is a problem in 3.8-release, probably before, though I didn't notice it myself, where huge time errors would never correct themselves, but rather, it would settle happily on a very wrong time. This has been fixed in -current (though it still may take days to close a large gap, but at least, it closes.). HOWEVER, you may be dealing with a drift that is much bigger than ntpd is designed to handle. Don't expect ntpd to make sense of a wildly drifting clock, it is only designed to provide little nudges in the right direction, not rework the entire clock hardware and software to compensate for a problem. Nick.
