Red Hat

No problem. Using ntpdate to slam a clock at intervals with cron seems like hammering screws with the screwdriver is right there in your tool kit. The right tool for the job should be to use the daemon.

ntp just seems so complicated for what it does... set the time. It's also rather undeterministic. "update clock on boot if possible" seems preferable to "set clock whenever ntp feels like it", particularly when it's changing not just seconds, but days, months, and years.

But I suppose I don't need the clock accurate down to milliseconds, I usually just want things to stop flashing 12

corona -

for test & dev boxes here anything close to the real time is fine. For production - no.
The legal department would have a cow if we were not spot on with time. We are a publically regulated utility. This is true in finance, utilities, etc. - any place where customers like to sue for their own negligence. (or the company's)

Corona,

Properly configured NTP will not be as convoluted as you seem to make it out to be. I worked at an exchange, and when we needed precise time, we got it down to 300us. If and when we needed more, PTP was being looked into

Precision Time Protocol - Wikipedia, the free encyclopedia

It is not un-deterministic because you do NOT want to alter the clock regularly. There is a reason that it is preferable to slew the clock. Each crystal oscillates differently, and the factors that influence this can be electrical or thermal among others. The way that NTP can correct this is to have a proper drift file as well as a stepping file. Then, the daemon can check values based on the past, even through a reboot.

Normally, on a reboot, a clock would have too much indeterminism to function properly for an exchange system without such tools. The clock would vary wildly for the first few minutes of operation. After the configuration was updated, the machine was usable significantly faster.

This may not be a concern to you, but as modern clusters need to sync'd regularly to function properly, it is hitting more people than it used to.

Thank you for that explanation. That there's real applications where timing is important enough for thermal drift to cause software errors in realtime is bit of an eye opener.

No problem. You have your specialties. This one is just one that has been hammered home to me on repeated occasion. Essentially, using things like minpoll and maxpoll you can set how often the lower stratum clock needs to/should be checked.

At my last company, I actually updated/rewrote the default init script for ntpd because we wanted to slam clocks that were outside of the acceptable tolerances, since they would otherwise not be usable. It also on start/status would check the offset from the 2 upstream stratum 1 clocks in their regions to show how far off they were from their lower stratums.

GPS is widely used as a medium for a stratum 1 clock because of the high level of accuracy and precision.