I was running RC4 and noticed that my time was drifting.  This is a WRT54GS version 2.1.  I reinstalled and had the same problem.  Just now, I got the latest snapshot of RC5 and seem to be having the same problem.  Here are some ntpd messages that demonstrate what I talking about:

ntp engine ready
reply from 202.173.190.30: offset -0.149107 delay 0.264184, next query 5s
reply from 202.173.190.30: offset -0.081669 delay 0.407680, next query 5s
reply from 202.173.190.30: offset -0.162649 delay 0.260134, next query 5s
peer 202.173.190.30 now valid
reply from 202.173.190.30: offset -0.169952 delay 0.266047, next query 5s
reply from 202.173.190.30: offset -0.171825 delay 0.256831, next query 5s
reply from 202.173.190.30: offset -0.172606 delay 0.266266, next query 5s
reply from 202.173.190.30: offset -0.180708 delay 0.254188, next query 83s
reply from 202.173.190.30: offset -0.261974 delay 0.270893, next query 57s
adjusting local clock by -0.180708s
reply from 202.173.190.30: offset -0.292880 delay 0.256159, next query 51s
reply from 202.173.190.30: offset -0.310264 delay 0.270391, next query 48s
reply from 202.173.190.30: offset -0.343430 delay 0.255689, next query 43s
reply from 202.173.190.30: offset -0.368003 delay 0.265315, next query 40s
reply from 202.173.190.30: offset -0.376725 delay 0.268369, next query 39s
reply from 202.173.190.30: offset -0.400322 delay 0.259992, next query 37s
reply from 202.173.190.30: offset -0.422815 delay 0.253269, next query 35s
adjusting local clock by -0.422815s
reply from 202.173.190.30: offset -0.440518 delay 0.254082, next query 34s
reply from 202.173.190.30: offset -0.457762 delay 0.255851, next query 32s
reply from 202.173.190.30: offset -0.473482 delay 0.252992, next query 31s
reply from 202.173.190.30: offset -0.489123 delay 0.257798, next query 30s
reply from 202.173.190.30: offset -0.504052 delay 0.257961, next query 30s
reply from 202.173.190.30: offset -0.520328 delay 0.257732, next query 30s
reply from 202.173.190.30: offset -0.533866 delay 0.254549, next query 30s
reply from 202.173.190.30: offset -0.549388 delay 0.254005, next query 30s
adjusting local clock by -0.473482s
reply from 202.173.190.30: offset -0.564953 delay 0.255268, next query 30s
reply from 202.173.190.30: offset -0.580751 delay 0.255172, next query 30s
reply from 202.173.190.30: offset -0.594351 delay 0.261779, next query 30s
adjusting local clock by -0.549388s
reply from 202.173.190.30: offset -0.610277 delay 0.256282, next query 30s
reply from 202.173.190.30: offset -0.624437 delay 0.259881, next query 30s

As you can see, the clock isn't actually getting set, but the time did seem to get set on boot.  Has anyone seen this before?

Steve

I am runnning RC4 with openntpd with the default config.

I get the same messages and my clock is always up-to-date.
I even tried to fool the system by setting the clock to -30 seconds manually.
After the next sync the clock was reset to the correct time.

All I did was installing openntpd by using ipkg.
I altered the ntp.conf in /etc, setting the "listen on" parameter to provide ntp service to the locally connected machines.

Of course I set the local Timezone in /etc/TZ so that my local time would be correct (GMT +1).

I get "peer ... now valid" and some time after that the "adjusting clock" message.

So no problem at all.

This is a hardware issue -- there is no actual clock; it does not make any sense to run a time server on a system that is incapable of keeping time.

What you see when you run 'date' is the system clock; a software emulation which is based on counting clock cycles, which isn't very accurate.

I understand that there is no real clock hardware on these machines.  I don't really expect much out of it.  I'm just confused by the fact that ntpd can't seem to adjust the software clock when it tries to do it, at least on my machine.

use rdate instead, it works fine.

Since I noticed this problem, I've been using ntpclient which seems to work as well.

Edit:  Actually, I should have mentioned that I'm using ntpclient in a cron job to periodically set the time once each time.  Ntpclient has the same problem trying to keep the time syncronized that ntpd does, again at least on my machine.

(Last edited by StephenR0 on 15 Feb 2006, 17:30)

I've solved this problem.  Referencing this thread:

http://forum.openwrt.org/viewtopic.php?id=534

I tried the ntpclient frequency tuning procedure and ended up with such a large frequency that adjtimex couldn't set it.  From this howto (also referenced in the above thread):

http://doolittle.icarus.com/ntpclient/HOWTO

there's a paragraph that touches on using adjtimex -t to make course adjustments to the system clock.  I found that I could get the tuning procedure to test various values of adjtimex -t (default 10000).  My hardware took a value of 9990 (a relatively large change) to get a reasonably accurate clock.  With that value, I ran the tuning procedure again and arrived at a much smaller frequency value that adjtimex could set.  Now I set both the -t and -f values in the openntpd startup script and everything runs just fine.  It would be nice if you didn't have to rebuild busybox with adjtimex selected to get the adjtimex utility, though.  Hopefully, this will help someone else with the same problem some day.