On 2011-04-18, Chris Albertson <[email protected]> wrote: > On Mon, Apr 18, 2011 at 4:10 PM, Mike S <[email protected]> wrote: > . While it certainly doesn't effect most >> users, it does some. At a minimum, there should be a mechanism to find out >> what (clock divisors?) the kernel has used for calibration, and lock them in >> for use with subsequent boots. Maybe there is, but after searching for a >> while, I couldn't find any way to do that. > > Is that not the purpose of the drift file? It stores the rate that > NTP has using when it stopped. It is checked at startup.
Unfortunately the ntp drift file tells you the difference between what the computer thought was the correct rate before you last switched it off, and the true time. When the computer is switched on again it does not know what the previous rate was so the difference between that and the correct rate is useless. It tries to measure the rate of the tsc (the rate at which instructions are processed) and something that ticks at a regular rate (a sound card?) and does it quickly and inaccurately. So either they delay bootup by a second or two to get a better rate, or get a bad one. I have no idea what changed that it got so bad, and would not mind a 1 sec delay to get it better, but I guess most people would not (or rather the kernel developers assume they would not). > > But the best you can hope for is to be "close". The whole reason we > need ntp is because the basic hardware inside the computer is not > stable. The crystal oscillator runs at a rate that is not constant > and tracks the temperature inside the computer. So knowing what > worked hours ago may or may not apply. If you care about micro > seconds then a crystal that has a few parts per million error will > loose or gain a few uS in short order. > > In short, it does what you ask but it is not as helpful as you might think > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
