From Electron Cloud
Jump to: navigation, search

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

(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
*    5   64  377 0.08722 -0.056842 0.14363   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
*    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. Remotehost-ntp1.png 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
listen on

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 prefer
driftfile       /var/lib/ntp/ntp.drift
# To deny other machines from changing the
# configuration but allow localhost:
restrict default nomodify nopeer

For using a dedicated server only:

server the-ip-address iburst
driftfile       /var/lib/ntp/ntp.drift
restrict default nomodify nopeer

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

ntpd -s

for openntpd.