On 5/1/19 7:03 PM, Harald Koch wrote:
Properly deployed NTP should calibrate the local hardware clocks to prevent drift even during connectivity outages. (I'm talking both the low resolution hardware clocks used for timing across power cycles and reboots, and the oscillators used while the OS is running). While most computer hardware is temperature sensitive, if your datacenter is suddenly changing temperature enough to cause clock drift, well, you have bigger problems.:)
For sure, sudden loss of time "shouldn't" happen, but having a local refclock is comparatively cheap insurance against it in many deployments.
I've seen things like this when there's a sudden power loss across a small site e.g. a remote PoP. Think a loss of utility power and UPS fails to transfer for some unanticipated reason. Everything will come back up when either the utility power comes back or generator spins up, but it will all be hard reset. Depending on your NTP implementation, the local hardware clock may not be particularly accurate. Even good implementations often lack the necessary hardware capabilities to trim the low-resolution hardware reference and have to resort to simply flushing the time to hardware every so often.
Relative inaccuracies of a few seconds are pretty normal in that kind of situation in my experience. Putting everything together from logs where there's an unknown time offset of a few seconds after the fact can be tough. Then again, maybe you don't care in this example case since the cause of the problem is proximate - the frigging UPS didn't do its job. More complex scenarios might be easily envisioned, though.
Now, obviously you've still got an issue of the fact that the GPS refclk will take a while to lock and start serving time, but at least you've potentially got known-good time info before you start bringing higher-level network protocols up (and can purposely delay until you do, if desired) which is potentially impossible if your only source of time is the network itself.
-- Brandon Martin
