Versions of ntpd

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.

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):

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