[time-nuts] x86 CPU Timekeeping and clock generation

[Hal Murray]

> I have the same thought of you, but when I tried in an ARM Single Board
> Computer (Asus Tinkerboard) with the same scenario (external clock and no
> syncing in NTP) the same results were achieved. Not the same drift rate, but
> the same behavior. This SBC dont uses TSC for timekeeping, but that you said
> makes sense. Concerning this line of thought, when CPU clock varies (by
> changing it because of power management) the drift should changes too, dont?
> Direction and rate. 

I think ARM boards typically don't fuzz the CPU clock.  They don't have a TSC, 
but there is a register that is locked to the CPU clock.
[    0.003076] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
I'd expect you could work out the integer arithmetic to translate from 
whatever you put into the chip to something very close to that number.  If you 
find the right place in the kernel sources, you can see how they translate 
that into ns-per-tick.  There will probably be some loss of precision in that 
area.  Bottom line is that with enough work, I think you should be able to 
predict what will happen as accurately as you want.

PCs have the clock fuzzing that will, well, fuzz any attempts at accurate 
clock analysis.  I think typical numbers are 1/2 % round down on CPU 
frequency.  There is also the clock measurement step.  The kernel measures the 
TSC speed relative to some other clock rather than doing simple arithmetic to 
calculate it.  That is another source for small errors.

-- 
These are my opinions.  I hate spam.