I'm setting up Ubuntu on an embedded machine that runs over a cellular connection, where we pay per byte. The machine also has no RTC battery, so it starts from a random time every boot.
I'd like to ensure that the time gets synced up when the cellular connection comes available so that log messages, etc have real times, but I also don't want to pay an arm and a leg for NTP traffic.
Can I customize the rate at which NTP updates the time? I'm using openntpd currently, but I'm not wedded to it.
The internet is not necessarily up at boot, so ntupdate and related at startup won't work. And scheduling via cron means waiting for the scheduled task to kick in, whereas I want a time daemon to get a time sync ASAP.
My experience is with ntp rather than openntpd.
You should know that the NTP protocol usually starts with sending packets every minute (64 seconds), but usually settles in by sending and receiving one packet every 17 minutes for each server you have in your /etc/ntp.conf file. Network outages or an unstable clock in your device may increase this, however. Each packet has a payload of about 68 bytes, so that's probably a little more than 100 bytes, each way, per poll.
The rdate and ntpdate at network up time are good ideas for setting the time. And if that is all you need should work well for you.
If you need to keep the time in sync over an extended time, however, the ntp protocol was designed to do that. The clock in your device will run a little fast or slow depending on how warm or cool it gets, even though it probably has a crystal controlled clock -- and ongoing timekeeping is meant to adjust for that.
Here are some suggestions if you need ongoing timekeeping and wish to reduce bandwidth used. They refer to items in ntp.conf.
Don't use iburst. (But it will take more time to set the time initially).
Increase minpoll upwards from 6 (2^6 seconds is 64 seconds). This reduces traffic when the protocol starts up after the network comes up.
Increase maxpoll upwards from 10 (2^10 seconds is 1024 seconds or about every 17 minutes. You can go as far as 17 to poll about every 36 hours. I haven't tried this myself.
Use only a minimum number of servers, if you had one that can be reliably reached from your embedded devices, that would have been great. The more servers the more reliable the timekeeping can be, but traffic scales up, so it is a trade off.
Some of these answers could win the obfuscated ntp configuration contest.
Use the ntp reference implementation and use iburst to set the time quickly upon booting. After that the you can use the minpoll directive to limit how often ntpd queries remote time servers. This will allow you to take advantage of ntpd's clock disciplining and keep the bandwidth down.
Chrony is a good alternative to the ntp reference implementation. Openntpd is not.
You could do some hackery involving running ntpdate when the cell interface comes up. But if you can, installing chrony would be a better alternative, as it was created with intermittent network access in mind.
On a default install of Ubuntu, the NTP daemon doesn't run. Instead, the time is set each time a network interface is brought up by the
/etc/network/if-up.d/ntpdate
hook.If you are after one-off time synchronisation rather than constant synchronisation, then this might be enough for you.
You can control which servers are queried to set the time either through the standard
/etc/ntp.conf
file, or through theNTPSERVERS
variable in/etc/default/ntpdate
.You've probably already read the openntpd man page.
http://www.openbsd.org/cgi-bin/man.cgi?query=ntpd.conf
You've probably already noticed the lack of a polling option for time.
I have these possible hacks to propose:
Use cron and/or your cellular connection scripts to toggle iptables rules to drop or allow port 123 traffic when you want to allow it. This could be as simple as
0 12 * * * iptables -D OUTPUT -j DROP -p udp --dport 123 # at noon start allowing ntp
0 13 * * * iptables -A OUTPUT -j DROP -p udp --dport 123 # at 1pm stop allowing ntp
Embed a radio clock receiver in your embedded machine. I know almost nothing about this but products like this:
http://www.galsys.co.uk/time-receivers/ac-500-msf-time-receiver.html and this
http://www.giangrandi.ch/electronics/dcf77/dcf77.shtml and people talking like this
http://www.blu.org/cgi-bin/calendar/2010-oct
make me think that it is not difficult if you can receive the radio signal.
Do you need the exact and precise synchronization that ntp provides? If not, you might be able to get away with using
rdate
orntpdate
at boot and then periodically via cron.If I remember correctly, ntp poll interval can be set to maximum of 1024 seconds. Perhaps the simplest solution would be to run ntpdate at each boot and later every now and then from crontab.
If your clock starts with a random time at each boot, then you probably won't be able to run ntpd anyway and you'll have to use ntpdate first. Ntpd refuses to sync time if the difference is too big between your clock and servers clock.
NTP, like TCP, has some Deep Theory and Practical Experience built into the protocol; if you alter its fundamental parameters, it stops having the synchronization properties that it was designed for.
If your device is sporadically connected, perhaps good old RDATE will serve you best. It doesn't handle clock-slewing, nor peer averaging, nor can it be secured against various subtle hacks that a man-in-the middle could play if it was worth his while. It just gets a reference date from a remote server and smacks the local clock with a hammer. But, it does it when you want it to, and its behavior is deterministic.
The RDATE accuracy is far worse than NTP affords, I wouldn't trust it for better than ±1 second, but if you are only sporadically attached, more accurate timing is not relevant; indeed, according to relativity it might not even be meaningful.
In order to make the
minpoll
/maxpoll
to be taken into account, you have to add then per server in yourntp.conf
.It is not quite recommended to mess with the NTP deamon (it has a built in mathod to optimize the frequency) but you will need to add these option like this :
Here, if set the min frequecy to 2^12 seconds, and the max to 2^17 seconds.
By default, I found out that the NTP would make a request every minute or so. That’s far too much. Here I reduced the frequency from once an hour to once a day (roughtly).