NTP has a drift file (usually /var/lib/ntp/ntp.drift or /var/lib/ntp/drift on Linux) where it stores and periodically updates the computers clock drift measured by ntpd in ppm. In your scenario I assume it should contain only one number - 0. If it’s not 0, does it correspond to the drift you are observing? .md
> On 6 Jan 2021, at 08:28, Hal Murray <[email protected]> wrote: > > >> My question is: what i'm missing? > > Two ideas come to mind. > > Most PCs (and servers) smear the CPU clock frequency slightly to dance around > the FCC rules. The chip that does that will have slight temperature > influence > so even if everything else is working right there will be tiny changes if you > look closely enough. > > On Linux, you will see something like this at boot time. (look in dmesg) > [ 0.000000] tsc: Detected 3292.448 MHz processor > > Even if the hardware does the right thing, the software may screwup. If your > system is using the TSC for timekeeping, that number above is used to setup > the conversion from TSC ticks to ns. A year or 6 ago, there was a bug in > that > routine. If you patched the boot code to call that routine a half dozen > times > you would get a half dozen different answers. The kernel guys didn't notice > because they were all close enough that ntpd could compensate. But any geek > looking at ntpd graphs of drift would notice big jumps when the system was > rebooted. > > > -- > These are my opinions. I hate spam. > > > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
