Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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.

share|improve this question

8 Answers 8

up vote 3 down vote accepted

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.

minpoll minpoll
maxpoll maxpoll
    These options specify the minimum and maximum poll intervals for NTP 
    messages, in seconds as a power of two. The maximum poll interval 
    defaults to 10 (1024 s), but can be increased by the maxpoll option to 
    an upper limit of 17 (36 h). The minimum poll interval defaults to 6 (64 s), 
    but can be decreased by the minpoll option to a lower limit of 3 (8 s).

Chrony is a good alternative to the ntp reerence implementation. Openntpd is not.

share|improve this answer

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.

share|improve this answer
    
+1 for the info about ntp refusing to sync if the drift is too big –  David Pfeffer May 16 '12 at 0:50
    
ntpdate is deprecated in favor of options to ntpd which will handle this use-case better than cron can eecis.udel.edu/~mills/ntp/html/ntpdate.html –  msw May 16 '12 at 11:36

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:

  1. Don't use any ntpd just call ntpdate via cron.
  2. 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

  3. Embed a radio clock receiver in your embedded machine. I know almost nothing about this but products like this:

make me think that it is not difficult if you can receive the radio signal.

share|improve this answer
1  
If you are going to add hardware why recommend a radio clock and not adding a GPS with PPS? –  dfc Jan 18 at 0:04
    
@dfc good point. OP, Consider GPS hardware to get time. –  Jay _silly_evarlast_ Wren Jan 19 at 17:06
1  
For $50 (Sure GPS it is a great deal) and some soldering I have a stratum 1 time server in the spare bedroom. I have the Sure GPS antenna sitting in a window blocked by a giant maple and another house and it works well. –  dfc Jan 19 at 17:09
    
@dfc can you link to hardware and which software you use with the hardware? –  Jay _silly_evarlast_ Wren Jan 20 at 21:28
1  
@Jay_silly_everlast_Wren Software: ntp reference implementation www.ntp.org Board: sureelectronics.net/goods.php?id=99 Couple of discussions: satsignal.eu/ntp/Sure-GPS.htm and lists.ntp.org/pipermail/questions/2011-March/028854.html There are a lot more. Don't be scared off by the soldering. It was my first time soldering and it was easy. The ntp questions mailing list is full of people who have used the sure board and very happy with it. –  dfc Jan 21 at 0:11

Do you need the exact and precise synchronization that ntp provides? If not, you might be able to get away with using rdate or ntpdate at boot and then periodically via cron.

share|improve this answer

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.

share|improve this answer

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 the NTPSERVERS variable in /etc/default/ntpdate.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.