Please check the tutorial page for updated tutorials on this topic!
The CH3SNAS has two internal clocks:
- a real-time hardware clock, which is similar to the chip in a wristwatch. It is powered by a battery inside the CH3SNAS and thus never stops.
- a software clock, which runs only when the NAS is turned on.
Unfortunately, the software clock drifts from the hardware clock and after a few hours the drift get noticeable (e.g., 16s/hour = 4444 parts per million) and the NAS will show incorrect times for e.g. file modifications. But thanks to NTP (the Network Time Protocol) the clock can be synchronized to one of the atomic clocks on the Internet. The resulting absolute error will be only a fraction of a second (e.g. 10 ms; because of packet delays across the Internet) and the drift will essentially become zero.
Note that this tutorial requires an installed Fonz fun_plug!
Background Information
The time in the Linux Kernel is a standardized value. One day equals 10000 “ticks”, so one tick = 8.64 s. Most of the CH3SNAS drift about 16s/hour, wich equals a drift of 384 seconds or 44.444 ticks/day. This value has to be subtracted from the 10000 Ticks of the Kernel and has to be set as the new number of ticks per day. In our case this 10000-44.444 = ~ 9956 Ticks. As you can see, this value is only an estimation because the drift is an estimation. As it will take a lot of time to get the exact value for the ticks, you can simply estimate them and synchronize periodically with a timeserver to reduce the clock drift.
As you can see below, there are two choices for the synchronization. Regular synchronization via Cron should be chosen over using the NTP-Daemon as the latter seems to cause the following two lines in dmesg
reappearing over and over again until the device gets restarted:
kernel: TWSI: mvTwsiStartBitSet ERROR - Start Clear bit TimeOut . kernel: TWSI: mvTwsiStopBitSet ERROR - Stop bit TimeOut .
The Procedure
Time-Synchronization via Cron
Simply add the following lines to /ffp/etc/fun_plug.local
, e.g. with nano:
# This removes firmware cronjobs that interfere with ntpd. crontab -l | grep -vw '/usr/sbin/daylight' | grep -vw '/usr/sbin/rtc' | crontab - #Now start the ntp every hour echo "1 * * * * /usr/sbin/sntp -r -P no de.pool.ntp.org" >> /var/spool/cron/crontabs/root # force a cronjob update echo "root" >> /var/spool/cron/crontabs/cron.update
Reboot the device.
Sidemark: If the NTP-Service has been deactivated before the restart.
NTP-Daemon
As described above, this method seems to cause the TWSI-problems and is here only for historical reasons. Probably due to the concurrent access to this Two-Wire-Serial-Interface by the ntp-daemon and the fancontrol.
Activating the Service
Mark the service ntpd as excutable:
chmod +x /ffp/start/ntpd.sh
Configuration of the Service
Copy the Example-Configuration from /ffp/etc/examples
to /ffp/etc/
:
cp /ffp/etc/examples/fun_plug.local /ffp/etc/fun_plug.local cp /ffp/etc/examples/ntp.conf /ffp/etc/ntp.conf
Edit the /ffp/etc/ntp.conf
to change the time servers to servers which are geographically close. You can search for them here.
Quick possibility: Change them to general ones:
server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst server 3.pool.ntp.org iburst
With this configuration both clocks get adjusted to the German timezone. If you want to change the timezone, you have to edit the /ffp/etc/fun_plug.local
.
The string for Germany is (also change the timeserver, as this one is for Germany):
timezone="CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00" timeserv=de.pool.ntp.org
Change it according to your Timezone. You can find possible ones in the appendix
Start the Service
You can now start the service manually or you can perform a reboot (it will be started during the bootup):
/ffp/start/ntpd.sh start
Finetuning
After a few hours you can find a file called /ffp/etc/npd.drift on you CH3SNAS. If the Value is +500 or -500, you have to adjust the number of ticks in the file /ffp/etc/fun_plug.local. fonz has set this to ”tick=9965”, which may be right for your device. If not, try reducing or incrementing this value to reduce the drift.
Appendix: Example Timezone Strings
Country | City | String |
---|---|---|
Australia | Melbourne,Canberra,Sydney | EST-10EDT-11,M10.5.0/02:00:00,M3.5.0/03:00:00 |
Australia | Perth | WST-8 |
Australia | Brisbane | EST-10 |
Australia | Adelaide | CST-9:30CDT-10:30,M10.5.0/02:00:00,M3.5.0/03:00:00 |
Australia | Darwin | CST-9:30 |
Australia | Hobart | EST-10EDT-11,M10.1.0/02:00:00,M3.5.0/03:00:00 |
Europe | Amsterdam,Netherlands | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Athens,Greece | EET-2EEST-3,M3.5.0/03:00:00,M10.5.0/04:00:00 |
Europe | Barcelona,Spain | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Berlin,Germany | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Brussels,Belgium | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Budapest,Hungary | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Copenhagen,Denmark | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Dublin,Ireland | GMT+0IST-1,M3.5.0/01:00:00,M10.5.0/02:00:00 |
Europe | Geneva,Switzerland | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Helsinki,Finland | EET-2EEST-3,M3.5.0/03:00:00,M10.5.0/04:00:00 |
Europe | Kyiv,Ukraine | EET-2EEST,M3.5.0/3,M10.5.0/4 |
Europe | Lisbon,Portugal | WET-0WEST-1,M3.5.0/01:00:00,M10.5.0/02:00:00 |
Europe | London,GreatBritain | GMT+0BST-1,M3.5.0/01:00:00,M10.5.0/02:00:00 |
Europe | Madrid,Spain | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Oslo,Norway | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Paris,France | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Prague,CzechRepublic | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Roma,Italy | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
Europe | Moscow,Russia | MSK-3MSD,M3.5.0/2,M10.5.0/3 |
Europe | St.Petersburg,Russia | MST-3MDT,M3.5.0/2,M10.5.0/3 |
Europe | Stockholm,Sweden | CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00 |
New Zealand | Auckland, Wellington | NZST-12NZDT-13,M10.1.0/02:00:00,M3.3.0/03:00:00 |
USA & Canada | Hawaii Time | HAW10 |
USA & Canada | Alaska Time | AKST9AKDT |
USA & Canada | Pacific Time | PST8PDT |
USA & Canada | Mountain Time | MST7MDT |
USA & Canada | Mountain Time (Arizona, no DST) | MST7 |
USA & Canada | Central Time | CST6CDT |
USA & Canada | Eastern Time | EST5EDT |
Atlantic | Atlantic Time | AST4ADT |
Asia | Jakarta | WIB-7 |
Asia | Jerusalem | GMT+2 |
Asia | Singapore | SGT-8 |
Asia | Ulaanbaatar, Mongolia | ULAT-8ULAST,M3.5.0/2,M9.5.0/2 |
Central and South America | Brazil,Sao Paulo | BRST+3BRDT+2,M10.3.0,M2.3.0 |
Central and South America | Argentina | UTC+3 |
Central and South America | Central America | CST+6 |
Normally my DNS-323 (firmware version 1.09) has 5 jobs in the crontab:
59 1 * * * /usr/sbin/daylight&
30 2 * * * /usr/sbin/stime&
*/10 * * * * /usr/sbin/offl_chk two&
32 2 * * * /usr/sbin/rtc -s
30 2 2 * * /usr/sbin/rtc -c
However, when I added the 6 lines exactly as shown in the “Time-Synchronization via Cron” section above to /ffp/etc/fun_plug.local, which were the only lines in the file, and rebooted, the only job that appeared in the crontab was the one added:
1 * * * * /usr/sbin/sntp -r -P no de.pool.ntp.org
I noticed in the ffp.log file that the grep “w” option was not recognized and realized that it was accessing /bin/busybox rather than /ffp/bin/busybox which has this option available. I then realized that the revised PATH=/ffp/sbin:/ffp/bin:/usr/sbin:/sbin:/usr/bin:/bin was not exported and set until /ffp/etc/rc ran, which is after /ffp/etc/fun_plug.local runs.
So, it is important that the following line is added to the top of /ffp/etc/fun_plug.local in order for “Time Synchronization via Cron” to work:
PATH=/ffp/sbin:/ffp/bin:/usr/sbin:/sbin:/usr/bin:/bin
Is this hack still necessary for the later firmware? I had a look at what stime does and it appears to be calling sntp to update the system time using the dlink’s own ntp servers. also, is it right to be removing the firmware cron jobs? don’t you need the daylight job to correct for DST and rtc job(s) to sync the hardware clock?