[time-nuts] x86 CPU Timekeeping and clock generation

Magnus Danielson magnus at rubidium.se
Wed Jan 6 10:15:11 UTC 2021


Marek,

On 2021-01-06 09:06, Marek Dorsic wrote:
> 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?

If the actual clock is more than 15 ppm off from the value in the drift
file, it will never track in the frequency error. This is due to
algorithm error in the NTPD. I have pointed out this problem, but there
have been very little interest in fixing it.

The tell-tale of this being the problem will be a continuous reset of
the clock phase.

While this may not be the issue for this particlar test, one should be
careful. The existence of a drift file bypasses the frequency learning
phase, and there is no recovery mechanism if the phase learning phase fails.

Cheers,
Magnus

>  
>    .md
>
>> On 6 Jan 2021, at 08:28, Hal Murray <hmurray at megapathdsl.net> 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 -- time-nuts at lists.febo.com
>> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.




More information about the Time-nuts_lists.febo.com mailing list