This is an old revision of the document!
HowTo Reduce System Clock Drift
The DNS-323 (like most computer devices) has two clocks - the “hardware clock” that runs all the time, and the “system clock” that runs only while the computer is on. To measure and reduce the system clock drift you will need:
- telnet access to your DNS-323
- internet access to a NTP time server (or a time server on your local network)
Note: The release notes for firmware v1.04 claim to have “Fixed clock drift issue”.
Measure the clock drift
To measure the default clock drift, you can set up a cron job to run the following script log_time.sh to record the NTP calendar time at one hour intervals. This script uses pool.ntp.org to get accurate calendar time.
#!/bin/sh # FILE: log_time.sh LOG=/mnt/HD_a2/log_time.log NTPSERVER=pool.ntp.org # look for zombie sntp processes PID=$(/bin/pidof sntp) # kill zombie sntp process if [ -n "$PID" ] ; then /bin/kill -9 $PID fi # log NTP time /usr/sbin/sntp $NTPSERVER >> $LOG
Create this script and place it on the DNS-323 hard drive, i.e. /mnt/HD_a2. Telnet to the DNS-323 and create a new cron job with the command
# /bin/crontab -e
and add the following line to the crontab (using vi commands)
0 * * * * /mnt/HD_a2/log_time.sh
Let the cron job run for several hours, then examine the log. Find the difference in time between two successive entries. Each entry in the log is recorded when the DNS-323 system clock determines that 60 minutes of system time has passed.
From the following log: 22:59:43.663 (line 2) - 21:59:58.687 (line 1) = 00:59:44.976, this means 59 minutes and 44.976 seconds of NTP calendar time has passed but the DNS-323 computed 60 minutes has passed… the DNS-323 system clock is drifting just over 15 seconds fast, each hour.
/mnt/HD_a2/log_time.log... 2007 Feb 22 21:59:58.687 + 13.589 +/- 0.240 secs 2007 Feb 22 22:59:43.663 + 27.586 +/- 0.133 secs 2007 Feb 22 23:59:31.404 + 41.601 +/- 0.272 secs
Fix the clock drift
To fix the clock drift you need a busybox binary with the adjtimex function defined. In this example the busybox3 binary is located in the /mnt/HD_a2/lnx_bin directory. The adjtimex function, with the -t ticks option, allows the root user to set the number of clock ”ticks” in a day. To fix the clock drift you need to compute the number of clock ”ticks” that your DNS-323 will need for 24 hours of calendar time.
The Linux kernel, used by the DNS-323, is supposed to have 10000 clock ”ticks” per day (someone else may be better able to explain this?), so each clock ”tick” is equal to 8.64 seconds of calendar time per day.
In my example, the DNS-323 will run 360 seconds (15 seconds per hour ∗ 24 hours) fast each day. 360 seconds is equal to 41.667 ”ticks” (360 seconds ÷ 8.64 seconds per ”tick”) Subtracting 41 clock ”ticks” from the standard number (10000) of ”ticks” in a day, ( 10000 - 41 = 9959) give the number of clock ”ticks” in a day for this DNS-323. I can telnet to the DNS-323 and issue the following command to fix the clock drift…
# /mnt/HD_a2/lnx_bin/busybox3 adjtimex -t 9959
After setting the new ”tick” value, let the cron job run for several more hours and review the log file. You may have to adjust the ”tick” value further. I settled on 9960, which keeps my DNS_323 system clock accurate within one tick (8.64 seconds) per day (<1 second drift per hour).
There is an additional option -f frequency for the adjtimex function, (see man page here), which allows you to further tune the clock drift in finer increments than one ”tick” (8.64 seconds per day).
When you find the correct ”tick” value for you system, place the adjtimex command in your fun_plug script so the correct clock ”ticks” are set each time you restart your system. Then remove the cron job with the crontab -e command.
