Compare NTPD and ntpdate

The NTP algorithm includes information to allow you to calculate and fix the drift in your server's clock. NTPD includes the ability to use this to keep your clock in sync and will run more accurately than a clock on a computer not running NTPD. NTPD will also use several servers to improve accuracy.

ntpdate does not keep any state to perform this service for you so will not provide the same kind of accuracy. It will allow you to provide it with a list of servers which it will use to attempt to provide you with a better result but this is no substitute for the sophisticated algorithms provided in NTPD that track your drift from each of the servers over time.

NTPDATE corrects the system time instantaneously, which can cause problems with some software (e.g. destroying a session which now appears old). NTPD intentionally corrects the system time slowly, avoiding that problem. You can add the -g switch when starting NTPD to allow NTPD to make the first time update a big one which is more or less equivalent to running ntpdate once before starting NTPD, which at one time was recommended practice.

As for security concerns, ntp servers do not connect back on uninitiated connections, which means your firewall should be able to tell that you initiated the ntp request and allow return traffic. There should be no need to leave ports open for arbitrary connections in order to get NTPD to work.

From the ntpdate(8) man page:

ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.

ntpd is preferred over ntpdate because you get smooth time correction rather than jumps in your clock. What sense do you make of your logs when there's a backwards time jump in them? ntpdate will also transparently switch between servers as needed.

As for requiring open ports (as mentioned by Kyle), newer versions of ntpd (e.g. 4.2.4 on my Debian server) can be configured to broadcast/multicast to the LAN, with cryptographic authentication.

Edit: see also this question.

I generally recommend that you run NTPD, and sync your servers with a designated time server within your organization. That internal server will typically be syncing with one of the public NTP servers (as you linked to).

I have used the ntpdate method without any problem, but it just seems more hackish than running a true ntpd daemon.

I have heard of issues with clock skew on virtual machines running ntpd. I have also heard of people correcting this issue by running regular cron jobs that call ntpdate against several of the pool servers. I've not had these problems, but I've heard of them several times.

As mentioned elsewhere, NTP provides a smooth time correction. If the applications on your server don't mind have whole seconds go missing, or doing the same seconds over again, then ntpd doesn't gain you much over ntpdate.

If on the other hand you do have time-sensitive applications that are sensitive to seconds, or even worse are sensitive to partial seconds, then ntpd is by far the better choice. Novell eDirectory timestamps updates for update-collision handling, which becomes critical if the updates come very fast (such as during the morning login rush). A syslog server needs to have time accurate to at least the half second in order to keep sane logs.

For my MythTV box at home, I notice when it is even a few seconds off of what my cable provider considers time, so I use NTP on that. For the UPS monitor server at work I use crontabbed ntpdate for the same reasons Kyle Hodgson pointed out, as it is a bastion host I don't want that port open even if I have locked the application down; for that application being a second off of true isn't dire.

As for redundancy, we maintain at least two time-hosts on our network, and point all of our internal hosts to those two. These two then track different internet NTP hosts. What's more, they're configured in a Peer arrangement so they can keep time between themselves in a consensus fashion if our internet link goes down. Robust NTP is definitely possible to engineer.

On a server where access and hardening are critical, I've used the reasoning that xntpd, the version of ntpd I was relying on, required an open UDP port 123. As I preferred to only have tcp 22 and 80 open, I used ntpdate in a crontab instead. I've never heard a good reason for why it needed that, or not one that I recall.

One of the cons of using a crontab'ed ntpdate call is that it can't handle drift correction elegantly. ntpdate, iirc, updates the clock as soon as it can tell that you are out of date - ntp daemons usually correct drift gently. This has the benefit that your logs are kept sane - you can imagine, on a busy web server for instance, that if the RTC had drifted a few minutes, that reading the web logs the next day might infer that people were able to hit secure URL's before they logged in, as web hits would be out of order.

ntpdate is intended for one-off updates, if you want time to be regularly synchronised, then use the service for that purpose, ntpd.

There's no compelling reason not to use ntpd as far as I can tell

You don't need to use crontab, that's what ntpd is for.

Initially when your time is way out, one way is to simply stop ntpd, then run ntpdate ntp.server.com to get it back in sync, then start ntp again.

If you have a large network though, I'd probably set up couple of local ntp server, and get all hosts to use them.

See this discussion for an understanding of why "ntpdate" is still desired and in use.

To sum it up: ntpd is slow in comparison when making a massive time adjustment, even with the -g option.

For Home use, ntpdate is no biggie really.. There is a reason it is "slower". Anyone that uses a cron with ntpdate in a PRODUCTION ENTERPRISE environment is just an idiot.