Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jamieburchell]

Thanks for the detailed reply. I have the time server and daylight savings disabled in the web configuration. I use that one line TZ fix in fun_plug.local. There's some cron jobs listed in crontab to do with the time- rtc, daylight, stime - I guess that's the problem.... I'll have a play.

[chriso]

Well you can certainly get rid of the programs causing problems in the crontab from the one script, as shown in my ffp/etc/fun_plug.local script.  The only problems with it is you are now left with no NTP client to compensate for drift, and also with rtc gone I'm not sure what will happen on reboot.  RTC I believe is responsible for writing/reading to the real time clock (maintain time when off), and I saw funny things with the times it set, that is why I killed it and then I set the time using the NTP client.

[jamieburchell]

In your example is it ntp.conf or ntp.drift, I'm a bit confused. Or are they different things?
If you're removing the rtc commands are you saying there are no adverse effects providing the time is set from a time server?
Also, what servers should I use for the UK!
thanks for your help, who'd have thought having the right date and time would be so difficult to achieve!
Would be nice if proper daylight savings were included in the new firmware. I've never had to specify dates for it each year in any other device.

[chriso]

It is ntp.conf.  ntp.drift gets created automatically to calculate what it thinks the drift will be so that it doesn't have to constantly contact the ntp server (instead it applies the drift for some time, and then contacts the ntp server).

You should probably not use the servers I'm using (even though they would work, ntp is based on UTC time it doesn't care where you are from).  Actually best might to be use the ones from this page:
http://www.pool.ntp.org/en/use.html (server 0.pool.ntp.org, ...)  Or better yet could also drill down and only use the ones from your region http://www.pool.ntp.org/zone/@  (Use the pool not the individual servers)

If you're removing the rtc commands are you saying there are no adverse effects providing the time is set from a time server?

Yes that is true provide the system clock gets set.  Here is what is happening.
Your system (DNS-323) has a "Real Time Clock", which is to say it has hardware that keeps the time of the day and will maintain the time even with the system off (battery backed up).  So when your system boots it will read the time and date from the RTC, but after it does it maintains its idea of the date and time separately from this clock.  For one thing its system clock is much more precise.  The RTC is only good to seconds.  And in some systems the system might even write its concept of time back to the RTC before shutting down.  Why?  Because since the time of the first PC these RTC chip have kept terrible time (they drift a lot more then your cheapest watch).  So basically I don't trust any of it.

If look you at the code in ffp/start/ntpd.sh I added this:

Code: [Select]

# Make sure the system clock is correct at start up.
ntpdate -b -u 0.us.pool.ntp.org
if [ $? -ne 0 ] ; then
echo "Sleeping 10 seconds"
sleep 10
ntpdate -b -u 0.us.pool.ntp.org
fi

What this does is try to set the system clock based on the the NTP server, and if it fails it gives another try in 10 seconds, (after that I just give up, after I want to boot more then to worry about the time).

The reason for ntpdate is because it says set the date plain and simple.  If you just say well I have the NTP client checking time won't it get the time to the right time?  Well the problem is that NTP was setup to compensate for small changes in time.  It is in the protocol that it corrects time very slowly (as in minutes off can take hours or even days to correct).  It is done like this so as not to disturb processes that are based on the time, like things in cron.  And it even won't try to sync if the time is too far off.

[jamieburchell]

Excellent. Finally got around to looking at this properly. I've enabled the ntpd.sh and made some edits to include your code to set the time initially. I see that this already handles the cron jobs. I've also added the TZ fix before the initial time update in the same file.
I've copied the example conf file and changed to uk time servers.
All seems to be working well. I notice however, that the "stime" cron job isn't removed by the FFP ntpd.sh script, should I remove that one too?
Thanks again for your help

[dosborne]

Yes, remove stime and rtc from cron.

[jamieburchell]

Just out of interest, why would the "dns323-rtc" command show the old time, but "date" shows the correct one? I'm guessing the correct date isn't being saved to rtc.

[chriso]

Yes like dosbrone said remove stime.  I actually have it removed the line in my ffp\etc\fun_plug.local

Code: [Select]

crontab -l | grep -vi rtc | grep -vi stime | grep -vi daylight | crontab -

does it.  As I said I had redundant code, and I just missed stime in the ntpd.sh script.  You will notice they do the same thing, they are just written a bit differently.

Just out of interest, why would the "dns323-rtc" command show the old time, but "date" shows the correct one? I'm guessing the correct date isn't being saved to rtc.

The ntpdate command sets the system time (date command shows this), it doesn't change the RTC.  You could run the RTC command to set it if you liked, but like I said I don't use it anyway with the ntpdate in place.

[chriso]

Actually I just looked at it more and dns323-rtc doesn't use the TZ variables, it just reports what time it has.
So if you sync the RTC with the system clock (which is stored internally as UTC):
/usr/sbin/rtc -w

You will find that the time the RTC shows is GMT/UTC time, and if you use "date" you will get the time adjusted for local and daylight time.

I decided to go ahead and add the setting of the RTC in the ntpd.sh just because if it ever fails to set time with ntpdate, then what will be the system time is what was retrieved from the RTC at boot so I might as well set it in the ntpd.sh when I know it is right (a drifting clock is better then one that is say an hour off):

Code: [Select]

     # Fix time zone information.
      # remove rtc, stime and daylight cron jobs
   crontab -l | grep -vi rtc | grep -vi stime | grep -vi daylight | crontab -

      # Make sure the system clock is correct at start up.
   ntpdate -b -u 0.us.pool.ntp.org
   if [ $? -ne 0 ] ; then
      echo "Sleeping 10 seconds"
      sleep 10
      ntpdate -b -u 0.us.pool.ntp.org
      if [ $? -eq 0 ] ; then
         /usr/sbin/rtc -w
      fi
   else
      /usr/sbin/rtc -w
   fi


[jamieburchell]

My dmesg is showing a lot of errors since doing this.

kernel: TWSI: mvTwsiStartBitSet ERROR

[chriso]

I don't have the problem, but it is talked about in this thread:
http://forum.dsmg600.info/viewtopic.php?pid=9812

The last post seems to be the right one for this problem and he says all you need to do is stick the -x flag in the ntpd_flags line.

[jamieburchell]

I'll give that a try- I assume it's related to the time changes, since I've not seen those errors before. I was having trouble with a USB enclosure dropping out at the time, I don't know if that error could have related to that. I googled the error and got the post regarding the time stuff, so that swayed my judgment.

Interestingly, after a reboot last night, there isn't any more of those errors shown in dmesg.

[chriso]

From what I gather about from the thread is that if the time is too far off for ntpd to adjust properly (or drifts to fast) it will do that.  But I suspect once you are properly synced you shouldn't have the problem any more.

[jamieburchell]

Here's something strange- dmesg has filled up with these errors and I hadn't yet tried your suggestion. I noticed that the NAS was showing a temperature of 0 C 32 F and a fan speed (the fan wasn't running). I tried a restart from the web interface and the NAS got stuck in a startup cycle with the front LED flashing, the network light going on and off- as were the drive lights.

I've never seen that before, had to pull the plug.

For now I've disabled the ntpd stuff. Looks like a known issue:

http://forum.dsmg600.info/viewtopic.php?pid=28017

[chriso]

Nothing is every easy!

Well if I get the gist of this right, the idea is that if ntpd is constantly changing the time to slew (actually stepping it, which causes the problem) it to the time it should be, that interferes with other processes that depend on looking at the time to do whatever they need to do.  The -x will force it to slew not step, which should prevent it from interfering with other time sensitive processes.

The big question I see to that is why does ntpd have to keep changing the time on those machines, must be a lot of drift (either in the DNS-323 or in the time servers).

I killed ntpd on my machine at then after 30 minutes to see what it said for time slew:
root@DLink-NAS:~# /ffp/bin/ntpd -q
ntpd: time slew +0.000644s

As you can see on my DNS-323 there isn't any reason it would be changing the time very often.

Anyway I suppose you could not run ntpd as a demon and just run the following command from cron once an hour or even less.
/ffp/bin/ntpd -q

It just sets the time and quits, it is like ntpdate I read they are going to obsolete, but it will use your ntpd.conf to find the time servers and such.

Also when I look at it I think that when you get out to the .00XX seconds, just which time server gets pulled up from the pool matters.  These machines are not atomic clocks so they do vary.