The time on my MBL isn’t accurate, despite enabling NTP, with the default servers:
It’s not even an integer number of hours out, it’s 28 minutes slow.
Is there anything I can do to correct this? Add a different server?
The time on my MBL isn’t accurate, despite enabling NTP, with the default servers:
It’s not even an integer number of hours out, it’s 28 minutes slow.
Is there anything I can do to correct this? Add a different server?
The clock on the MBL does seem to drift quite a bit; it doesn’t appear that NTP is run periodically to update the time.
Have you rebooted the MBL in the past few weeks?
Mine has been up for two months and was “slow” by about 2 minutes.
You can manually update the clock by either rebooting the MBL, or by logging in via SSH and executing the command
ntpdate pool.ntp.org
Ah OK that would begin make sense; it was probably down for around half an hour last week when we had some electrical works done. But then again, when it was restarted it should have set the time again? It’s only been up continually for about a week, certainly not enough time to lose 28 minutes. It’s odd that it doesn’t keep itself updated. Isn’t that one of the major advantages of using a remote timekeeper?
When you were having the electrical work done and the MBL rebooted, was there a chance your network was also rebooting at the same itme? If the network wasn’t fully functional by the time the MBL did its reboot, it might not have been able to do the NTP sync. So it’s worth trying to manually reboot it to see if it corrects it, then observe it later to see what it’s doing.
Yeah, I think it’s kind of odd that it doesn’t re-sync itself periodically…
Good point. Next time it drifts, I’ll try a reboot on its own and see if it fixes itself. Thanks for the suggestion.
MBL only tries to get the time once, on startup. If your network infrastructure isn’t up yet, you lose and never recover.
This is also why it drifts after a while.
[Following is for experts… if you don’t already know how to get to a shell prompt and edit files, you probably shouldn’t try this.]
Here’s what I did. First, make startup keep trying until it gets a good time. Edit /etc/init.d/ntpdate. Find the invocation of /usr/sbin/ntpdate-debian and replace it with:
while ! /usr/sbin/ntpdate-debian -s $OPTS; do
sleep 60
done
Next, let’s do something about *staying* in sync:
Create a file /etc/cron.daily/ntp-resync:
#! /bin/sh
/usr/sbin/ntpdate-debian -s
You could put it in /etc/cron.hourly if you wanted to, but I thought I’d be nice to the NTP servers.
Finally, if your time is already off and you want to fix it, you could do
/usr/sbin/ntpdate-debian
to set it.
CAVEAT: I’ve only just set this up, and while it *looks* like it’s working, it hasn’t been tested extensively. Once you set it up, you might want to look for “ntpdate” lines in /var/log/daemon.log every once in a while to see how it’s doing.
CAVEAT: I have a feeling that WD looks a bit dimly on tweaking the system software like this; it might well void your warranty. (But it’ll probably keep better time.)