Fixing the NTP Time Synchronization with Fonz funPlug 0.5 for CH3SNAS, CH3MNAS, DNS-323 and many more

German version of this tutorial

This tutorial is deprecated and should only be used with fonz fun_plug 0.5!
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" >> /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.


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/

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 iburst
server iburst
server iburst
server 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):


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/ start


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

6 thoughts on “Fixing the NTP Time Synchronization with Fonz funPlug 0.5 for CH3SNAS, CH3MNAS, DNS-323 and many more”

  1. 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

    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:


  2. 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?

Comments are closed.