Versions of ntpd
- the reference implementation is rather full-featured (discussed more below)
- OpenNTPD is the one for OpenBSD, also smaller, more secure and suitable for embedded systems
- chrony claims to be better for systems that are intermittently connected (e.g. dialup) but my experience is that it doesn't behave as well when your system clock has pathological amounts of drift
- OmniSync is for getting around asinine firewalls that block access to regular NTP (I haven't tried that one yet)
NTP is the modern replacement for the more antiquated rdate, which isn't to say that rdate isn't occasionally useful. For one thing, BusyBox includes rdate but not ntpd or ntpdate (yet) so you are more likely to find rdate available on embedded devices.
Graphing convergence of the system clock
ntpd behaves differently depending on the difference between the system time and the reference clock time(s), various settings etc. You can watch the convergence of the system clock to the references using a cron job to log the data, and gnuplot to graph it.
By default ntpd has a socket interface (or UDP maybe?) which permits querying its status (and maybe even changing some settings) remotely. You can disable that in /etc/ntp.conf:
restrict default nomodify nopeer noquery restrict 127.0.0.1
(The first line disables some features by default, the second re-enables everything for clients connecting from localhost.) But if "noquery" is omitted, you can use ntpdc to log the offset of a remote host's clock.
[localhost][02:02:12 PM] ntpdc -sn remote local st poll reach delay offset disp ======================================================================= *220.127.116.11 192.168.2.114 5 64 377 0.08722 -0.056842 0.14363 10.90.1.35 192.168.2.114 16 1024 0 0.00000 0.000000 3.99217 ~ [localhost][02:02:14 PM] ntpdc -sn remotehost.local remote local st poll reach delay offset disp ======================================================================= *18.104.22.168 192.168.2.115 5 128 367 0.08578 -0.072788 0.14655
So just create a cron job which does this once per minute:
echo `date +%s | cut -c5-12` " " `ntpdc -s remotehost.local | tail -n1 | cut -c54-64` >> /path/to/remotehost-ntp.log
The system clock has its first 4 digits cut off so the numbers are 6 digits, and the log looks like this:
791061 954.35962 791121 954.35130 791181 954.37580 ...
Then to graph the data, create a file with all the gnuplot commands:
set style line 1 lt rgb "blue" lw 1 pt 0 set xlabel "time,min" set ylabel "offset,s" set title "Convergence of clock via ntpd after startup" #~ set terminal x11 set terminal png size 1024,400 set output "remotehost-ntp.png" plot "remotehost-ntp.log" using (($1-791000) / 60):($2) with linespoints ls 1 title 'hostname'
and run it like this
gnuplot -persist ntp-gnuplot
The -persist is for the set terminal x11 case, to make the window stay up until you close it. (If set terminal png ... doesn't work, maybe you need to rebuild gnuplot using gd to get PNG support. X11 previewing is a nice way to just look at the graphs, anyway.) I had gnuplot subtract the initial number from the X values so that the X axis starts at time zero. Well it's not a very interesting graph... when I first installed ntpd on that system I was seeing a very slow convergence over a day or two, but after I started graphing, it started just jumping back to the correct time whenever I perturbed it. Whatever...
Good settings for the conf file
openntpd /etc/ntpd.conf for using the NTP pool (taken from an OpenWRT router):
# use a random selection of 8 public stratum 2 servers # see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers servers pool.ntp.org listen on 10.0.0.1
For the reference ntpd, on other systems which use that router for setting their own time, but can also deal with cases when the router is just wrong:
server 10.0.0.1 prefer server pool.ntp.org driftfile /var/lib/ntp/ntp.drift # To deny other machines from changing the # configuration but allow localhost: restrict default nomodify nopeer restrict 127.0.0.1
For using a dedicated server only:
server the-ip-address iburst driftfile /var/lib/ntp/ntp.drift restrict default nomodify nopeer restrict 127.0.0.1
iburst basically makes it sync up faster: apparently each time ntpd tries to query the time of the remote server, if it doesn't succeed, it does more queries, so there is a better chance of getting a reply rather than waiting until the next query interval... something like that.
ntpd command options
It's generally OK to use the option that allows it to make a large initial correction, if necessary (especially if you are not using a single time server, or if you trust your server(s) to be always right). That would be
ntpd -p /path/to/pid -g -N
for the reference impl, or