On Feb 12, 2015, at 12:49 AM, William Unruh <un...@invalid.ca> wrote: > On 2015-02-11, Charles Swiger <cswi...@mac.com <mailto:cswi...@mac.com>> > wrote: >> On Feb 11, 2015, at 7:23 AM, Rob <nom...@example.com >> <mailto:nom...@example.com>> wrote: >>> But I see it has also been explained elsewhere in the thread: ntpd has >>> a maximum on the momentary drift of 500ppm, no matter if it is static >>> or dynamic or the sum of two. I think that is not warranted. >> >> Do you believe that a clock which loses or gains over a minute per day >> should be assumed to be trustworthy? [ ... ] > A few kernels ago, Linux kernel had problems in calibrating the system > clock. It would be off by up to a few 100 PPM, and change from one boot > to the next. Ie, this was a consistant drift error.
Yes-- I had that specific kernel bug in mind. > It could be zeroed out using adjtimex, but ntpd is supposed to handle the > clock, > not demand people fixing things by hand. chrony had no problem. chrony has a problem if it trusts an obviously broken clock! > It uses both the > frequency and the tick rate adjustments of admtimex. ntpd could have a > problem if the linux clock was off by say 400PPM in which case it would > leave little headroom for normal operation. For what it's worth, real physical hardware on a non-broken OS seems to do fine with only +/- 100 ppm tolerance almost all of the time. I've looked for counterexamples in a large fleet, but the only things I saw with an ntp.drift value beyond 100ppm were VMs. > Of course the "right" procedure would be to fix the kernel, and that was > eventually done, but that eventually was on the order of a year or two. That's exactly right. From that situation, I drew the conclusion that precise timekeeping wasn't a priority for the Linux project. > Were all Linux people to give up disciplining their clocks while waiting > for the kernel people to get their act together? That hardly seems > sensible advice. I recall advising anyone who cared about precise timekeeping to run FreeBSD, NetBSD, or even maybe OpenSolaris instead of Linux. And yes, I fully understand that some folks have a homogenous environment and lack the flexibility to select the best platform for a particular purpose. Been there, had thousands of java processes on Linux VMs get wonky with the June 2012 leap second due to adjtimex() kernel hang. Regards, -- -Chuck _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
