OpenWrt Forum Archive

Topic: ntpclient

The content of this topic has been archived on 7 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

hmmm.  i started this discussion in another thread, but I'm restarting it here.   earlier, I wrote...

....ntpclient. first, fix busybox to include adjtimex, by editing sources/openwrt/busybox/busybox.config and adding ...
CONFIG_ADJTIMEX=y
and rebuild your openwrt (make clean in the busybox dir, then make in the top should be sufficient), and download this new openwrt, also `make ntpclient` and ipkg install it.

now, per the readme on ntpclient, run

# ntpclient -i 60 -c 30 -h 192.168.0.1 | tee /tmp/ntp.log

(replace that IP with your friendly neighborhood NTP server)

and then find rate.awk in the ntpclient source directory, and feed that .log file through it like...

$ awk -f rate.awk < ntp.log
delta-t 1500 seconds
delta-o 622716 useconds
slope 415.145 ppm
old frequency 0 ( 0 ppm)
new frequency 27206931 ( 415.145 ppm)

(I did this on my build computer rather than the WRT).

Now, take the last value displayed, like 27206931, and put this in /etc/init.d/S90ntpclient ...

#!/bin/sh
adjtimex -f 27206931                 
/usr/sbin/ntpclient -h 192.168.0.1 -s 
/usr/sbin/ntpclient -h 192.168.0.1 -l &

(again, replacing the IP's with the correct ones, and the adjtimex value with the one from rate.awk above)

*NOW* your clock should be right on the money, and ntpclient should run a phased lock loop to KEEP it that way. Check it in a few days with `date` against that of your NTP reference server.

-------

yeah, I wrote that, and I left it running...  my clock has drifted several seconds, and still appears unlocked.  ;-/    FYI, I'm using these instructions...
http://doolittle.faludi.com/ntpclient/HOWTO

so, has anyone actually gotten this working?   yes, I know how to pseudo-CRON a periodic rdate, I dislike that approach for various reasons.    If ntpclient can't be made to work properly, it probably should be dropped from the distro.

I emailed the author of ntpclient, and asked him for hints why it might not be converging... his answer...

John -

On Thu, Oct 14, 2004 at 01:53:44PM -0700, John R Pierce wrote:

>> I'm using ntpclient built for MIPSEL (MIPS32 Little Endian, embedded on a
>> WRT54GS router, using the sources distributed with openwrt,
>> http://www.openwrt.org), which is Linux 2.4.20 based.


Cool.


>> I've gone through your HOWTO and README, and have run ntpclient logging the
>> errors for 30 minutes, fed that into a graphing program (clean lines, no
>> anomalies), and into your awk script,
>>
>>     $ awk -f rate.awk < t.log
>>     delta-t 1740.44 seconds
>>     delta-o 281067 useconds
>>     slope 161.492 ppm
>>     old frequency 16384000 ( 250 ppm)
>>     new frequency 26967534 ( 411.492 ppm)
>>
>> then fed the awk 'new frequency' value to adjtimex, initially set the clock to
>> my ntp server (ntp v4 on a linux box on the same LAN), then I launched
>> `ntpclient -l`...


Perfect.


>> its not converging... after running several hours, here's
>> the log output from ntpclient...
>>
>> 38272 64297.350    1057.0     44.0    1173.5 119827.3  26967534
>> [chop]
>> 38272 72700.809    1849.0     48.0   49975.5 126678.5  26967534
>> # box [( -21.266 , -70221.2 )  ( 32.412 , 172930.2 )]  delta_f -0.111
>> computed_freq 26974776
>> 38272 73301.056    1877.0     50.0   51354.5 120498.7  26967534
>> # box [( 140.121 , 19059.7 )  ( 193.884 , 280198.3 )]  delta_f -20.000
>> computed_freq 17694719
>> 38272 73901.226    1868.0     48.0  149629.0 129501.3  16384000
>> # box [( 135.329 , 108646.5 )  ( 192.924 , 387750.5 )]  delta_f -20.000
>> computed_freq 17694719
>> 38272 74501.396    1848.0     47.0  248198.5 138504.0  16384000


Your problems seem to center around the fact that each time ntpclient
computes a new frequency (26974776, 17694719), and therefore calls
set_freq(new_freq), 6000 seconds later when it reads the current
OS frequency, it gets 16384000.  Makes me think that the adjtimex(2)
set of frequency (that is skipped if ntpclient doesn't want to change
anything) isn't working.

Maybe your /usr/include/timex.h struct timex doesn't match that of
the running kernel?


>> Any idea whats whacked here?    I'd like to sort this out so I can do a
>> ntpclient FAQ for the OpenWRT community....


Something is indeed whacked.  I don't think the problem is in the
ntpclient source code.  More likely your build system is not quite
right.

I don't have time to look into this this AM (gotta get kids to school, and going camping this afternoon), but its possible there's an issue with the busybox compilation of adjtimex.   to enable this, I had just added "CONFIG_ADJTIMEX=y" to sources/openwrt/busybox/busybox.config

The problem has nothing to do with adjtimex, neither the system call, nor the busybox utility.  The problem has to do with the default maximum adjustment that ntpclient, by default, will allow.

From the ntpclient HOWTO:

If the frequency offset (absolute value) is greater than about
140 ppm (9175040), you have a problem: you may be able to fix it with
the -t option to adjtimex, or you need to hack phaselock.c, that has a
maximum adjustment extent of +/- 150 ppm built into phaselock.c (change
the #define MAX_CORRECT and rebuild nptclient).  I'd like to suggest that
you replace the defective crystal instead, but I understand that is rarely
practical.

Well, the WRT54G(s) doesn't have a crystal, and the 1638400 figure you see in your logs is significant, because MAX_CORRECT is set to 250 (not 150 as the documentation says), and 250 * 65536 = 1638400.  So, ntpclient is trying to correct for drift, by setting the frequency to the max that it will allow, which simply isn't enough to compensate. In short, the frequency counter in the WRT54G(S) drifts far more than ntpclient can correct for in its default configuration.  I've set my MAX_CORRECT to 1000, and after running for about two days, my wrt54gs currently is off by 55ms.  Reviewing my ntp logs, I see that it has drifted back and forth several times from being slightly too slow to being slightly too fast, which is a sign that ntpclient is doing its job.

I have not looked into the kernel sources at all, and it may be possible that this   amplified drift may be modulated within the kernel sources.

I have a different problem..  The rcscript never seems to run at startup..because the clock never gets set...
yet, when i manually run the script it gets set...
I have a WR850G.. But I'm assuming at this level, it doesnt matter.

Does anyone have the same problem?

pierce wrote:

Now, take the last value displayed, like 27206931, and put this in /etc/init.d/S90ntpclient ...

#!/bin/sh
adjtimex -f 27206931                 
/usr/sbin/ntpclient -h 192.168.0.1 -s 
/usr/sbin/ntpclient -h 192.168.0.1 -l &

I installed ntpclient on 0.9 WhiteRussian and was disappointed to find that it only attempts to set
the clock using a hotplug.d callback. I found a reference at http://martybugs.net/wireless/openwrt/timesync.cgi
which suggests using crontab to periodically yank the clock back into line.

The approach suggested here is preferred because it keeps the clock synchronised by making small
adjustments in frequency. I chose to put the startup in /etc/init.d/S49ntpclient to be scheduled
just after the network is initialised.

This startup script looks for the frequency adjustment in the NVRAM variable ntp_adjtime, and
the name of the NTP server in the variable ntp_server.

#!/bin/sh

ADJTIME=$(nvram get ntp_adjtime)
SERVER=$(nvram get ntp_server)

# Prefer a local host if there is one, otherwise use the default
# host pool from ntp.org.

: ${SERVER:=pool.ntp.org}

# The presence of ntp_adjtime implies that clock frequency
# analysis has been performed on this host.

[ -n "$ADJTIME" ] && /usr/sbin/adjtimex -f "$ADJTIME"

# Spin off a subshell to perform the synchronisation.
# It might take some time to complete the initial
# step because the network route to the server might
# not be available, or worse still the server might
# be down. In all these cases we do not want to stall
# the startup process.

(
    # The WRT54G router does not have a battery backed RTC so
    # the clock always resets on reboot. Obtain an initial
    # reading to set the clock, retrying indefinitely every
    # 1 second, and ensuring that the estimate is better than 10ms.
    #
    # Note that the -s option must precede -c 0 because -s
    # implies -c 1.
    #
    # Close stderr to avoid being inundated with periodic
    # errors as the client attempts to contact the server.

    /usr/sbin/ntpclient -s -c 0 -i 1 -g 10000 -h $SERVER 2>&-

    # Once the clock has an initial setting, continue running
    # the client to keep the clock synchronised. This will use
    # a 3600 second (1 hour) update.

    exec /usr/sbin/ntpclient -l -i 3600 -h $SERVER

) | /usr/bin/logger -p daemon.info -t ntpclient &

The discussion might have continued from here.