Solve the LinkStation's problematic clock drift

'' This article Based on work by nix, frontalot, and nonName. Originally by frontalot. at Linkstationwiki.org ''

The classic Way

 * 1) Originally the LinkStation comes with a script to adjust the clock. You can run it manually:
 * /etc/cron.d/calib_time.sh
 * 1) However, you must correct your timezone information first:
 * vi /etc/melco/info
 * 1) Replace the "timezone" variable with your GMT offset. For example:
 * timezone=+6
 * 1) Finally set a cron job to run   as needed. To have the script run hourly (this may be overkill), add the following to  :
 * 05 * * * * root /etc/cron.d/calib_time.sh >/dev/null 2>&1
 * 1)   prevents cron from sending you an email each time the clock is adjusted.

The Mipsel-hdhlan Buffalo Way
In later firmware versions, Buffalo came up with a better clock calibration method. The LinkStation can consult an NTP (Network Time Protocol) server in regular intervals and adjust its internal clock according to the data form the time server. There are a number of public time servers on the Internet which can be used for this purpose. This should be done with care since these servers usually are under a heavy load. However, Buffalo made it difficult to use the typical procedures for NTP load-balancing. Buffalo has set up the system in the following way:


 * 1) cron runs a script   in regular intervals:
 * crontab -l
 * 00 1 * * * /etc/cron.d/ntpdate
 * 1) The function of the script is controlled by the file  . The contents of that file usually are changed via the web interface. However, the web interface only allows you to specify an IP address for an NTP server. This works against the desired load-distribution on NTP servers.
 * 2) The DNS for an NTP server is often set up so that DNS responds with different IP addresses for a particular NTP server. This way requests to the server are distributed across multiple servers. The LinkStation only allows you to specify an IP address and as such its NTP requests cannot be directed to different servers. This method of requesting time information is generally frowned upon across the Internet.
 * 3) Another major problem is that the NTP requests are performed upon the hour, a time when NTP servers are traditionally very busy. Therefore it is recommended to not use this mechanism as-is, e.g. via the web interface. Instead it is suggested to change or create the above mentioned crontab entry manually:
 * vi
 * minute 1 * * * /etc/cron.d/ntpdate
 * 1) Also change the   file as follows:
 * ntp=on
 * ntpserver=pool.ntp.org
 * ntpadjtime=1:minute
 * 1) Pick a random value for minute in the above examples! Avoid smooth minutes like 0, 15, 30, or 45, since NTP servers usually are under heavy load at those times. You should also consider if you really need to synchronize once an hour or if a longer interval is suitable.
 * 2) The suggested server   is a public NTP server which directs the request to a pool of NTP servers.   is not the only pool run by ntp.org and ntp.org is not the only organization offering public time servers. There are domain names which point to servers which might be geographically closer than  . More details can be found at http://www.ntp.org.

Fixing the Buffalo Way
If you experience heavy clock drift within your one hour NTP time synchronization interval, you should adjust the LinkStation's internal clock "tick" rate instead of decreasing the synchronization interval.


 * 1) There is a script which adjusts the internal clock "tick" rate. It may be downloaded from here. Unpack the archive and edit the ntpdate startup script:
 * vi /etc/init.d/ntpdate
 * 1) Edit adjtick.sh and uncomment the appropriate lines (commented in the script).
 * 2) Add the following line before ntpdate is executed:
 * /usr/sbin/adjtick.sh
 * 1) You can verify that the computed tick value is optimal by executing adjtick.pl. If you notice a discrepancy, your quartz is not tuned precisely. In such a case (very rarely), modify the tmp_freq_base value in adjtick.sh. Check the tick value and make adjustments if necessary until the values are correct.
 * 2) To display the current tick value (without modification):
 * /usr/bin/tickadj
 * 1) The optimal tick value will change each time the LinkStation is rebooted. This script courtesy of Philippe Deysine and Don North.

The Correct Way - Typical

 * 1) The correct method for dealing with clock drift is to use NTP in the right way. First set your timezone. You can use   (if available) or manually edit   and add your GMT timezone. For example:
 * timezone=+6
 * 1) Next create the file   and enter the following information:
 * server 0.pool.ntp.org
 * server 1.pool.ntp.org
 * server 2.pool.ntp.org
 * 1) ntpdate is set to synchronize the clock on system startup. If you rarely reboot your system you may want to setup a cron job (see above). It’s recommended not to do this to occur at midnight (or on the hour) as the time servers will usually be under a heavy load.

The Correct Way - Large Clock Drifts

 * 1) If your LinkStation has an unusually large clock drift (there was one report of a powerpc-hdhglan LinkStation drifting more than 25 seconds per hour) you should consider using   instead of the simple   mechanism.
 * 2) ntpd is a daemon program which contacts NTP servers at some interval (it calculates this interval itself). It also records hardware clock drift statistics and uses these statistics to adjust the hardware clock once per second (without connecting to an NTP server). ntpd needs a period of time to collect enough clock drift statistics.
 * 3) Remember to turn off the ntpdate time synchronization method when using ntpd.