On Tue, Sep 20, 2005 at 11:05:00PM +0200, Benoît Dejean wrote: > > [22:05:26][pts/3][/tmp][#33][&1] > [EMAIL PROTECTED] >>> sudo date 09202200 > mar sep 20 22:00:00 CEST 2005 > > /var/log/daemon.log > Sep 20 22:29:10 ibook ntpd[7820]: adjusting local clock by 169.046988s > Sep 20 22:37:46 ibook ntpd[7820]: adjusting local clock by 337.824555s > Sep 20 22:42:05 ibook ntpd[7820]: adjusting local clock by 337.644373s > Sep 20 22:44:45 ibook ntpd[7820]: adjusting local clock by 337.522502s > Sep 20 22:47:56 ibook ntpd[7820]: adjusting local clock by 337.343444s > Sep 20 22:51:13 ibook ntpd[7820]: adjusting local clock by 337.190990s > Sep 20 22:53:52 ibook ntpd[7820]: adjusting local clock by 337.060332s
I'm not sure I follow what you're tryign to say. ntpd only does a settimeofday() once to set the clock and that is at startup and when the -s option is used (which is off by default.) Either you enable the option (and maybe I should make it the default) or you use something else to synchronise your clock at startup like ntpdate. The rest of the time it only uses adjtime() to keep the clock at the correct time, and expects that it can keep the clock at the correct time with it. If you go and manually change the clock, it's going to take a very long time to get it back at the right time. The kernel has a maximum adjust rate of 0.5 ms/s. So an offset of 300 seconds is going to take about 7 days to get fixed. > ntpdate -u -q localhost > 20 Sep 22:55:52 ntpdate[17740]: adjust time server 127.0.0.1 offset 0.000050 > sec And what exactly did you expect this to return? That the offset is 337 seconds? I would expect that too, but the ntp protocol doesn't seem to work that way. You're now comparing 2 local clocks, once asking the ntpd once asking the system itself, and they both returned the same time. Kurt
