Spoon wrote: > Spoon wrote: > >> Hans Jørgen Jakobsen wrote: >> >>> Dmitry Ivanov wrote: >>> >>>> Spoon wrote: >>>> >>>>> I've noticed something I find very strange on the systems I have to >>>>> work with. Every time I reboot the computer, the clock skew of the >>>>> local clock changes, sometimes by what seems to be a huge amount. >>>>> >>>>> For example, I boot the computer, let ntpd run for 12 hours, and the >>>>> value recorded in the drift file is 35 ppm. I reboot the computer, let >>>>> ntpd run for 12 hours, and I get 5 ppm... >>>> >>>> I see the same behaviour on many systems. Looks like common problem. >>> >>> Could it be that some systems at reboot try to calibrate the clock >>> (whatever that might be) relative to the TOD chip? >>> On some systems the TOD chip has the lowest frequency offset >>> and this would on systems not runing NTP lead to a system drifting less. >>> But it's poison for the value in the driftfile. >> >> # dmesg | grep -i calib >> Calibrating delay using timer specific routine.. >> 2535.15 BogoMIPS (lpj=12675781) >> >> Are you referring to this calibration? >> >> I'll check the source code to find where this message comes from. > > It's coming from init/calibrate.c > > /* This routine uses the read_current_timer() routine and gets the > * loops per jiffy directly, instead of guessing it using delay(). > * Also, this code tries to handle non-maskable asynchronous events > * (like SMIs) > */ > > http://lxr.linux.no/source/init/calibrate.c > > I see it's possible to skip the calibration code by providing a boot > time parameter. I'll test this and report back here.
Skipping the calibration did not fix the problem. However, it seems to have an impact. Sigh... I've run out of ideas. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
