[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.
cswiger at mac.com
Tue Mar 13 22:42:05 UTC 2012
On Mar 13, 2012, at 3:19 PM, Ron Frazier (NTP) wrote:
> At that time, I had the GPS as the only selectable clock, for testing. I'm monitoring the internet servers for comparison. I've since selected 1 NIST server as the preferred and only selectable clock, and am monitoring the GPS and other internet clocks for comparison.
ntpd is probably better able to judge which timeserver to use then forcing the choice via prefer, as it continues to evaluate the servers available to it and will use another one if the chosen peer happens to become unreachable.
> My thinking was simply that if all the available clocks vanished (internet down), or the GPS went insane, I just want the system to coast on its internal clock until a viable clock source returns. I figure it may gain or lose up to 10 ms / minute this way, but at least it shouldn't do anything radical like jumping 50 seconds.
If you let ntpd run long enough to estimate the intrinsic drift, it will continue to adjust the clock even without external timesources. However, if your system clock really is off by a rate of 1:600 or worse, it's broken and ntpd probably wouldn't be able to fix it, at least without tinkering the max allowable slew rate-- running ntpdate via cron might do.
> I looked at the docs page for the "orphan" command for a few minutes and my eyes just glazed over. I decided to try the local clock option instead for now.
Why would you want to use the local clock option? It's rarely the right solution, barring unusual circumstances...
More information about the questions