[time-nuts] x86 CPU Timekeeping and clock generation

[Luiz Paulo Damaceno]

Wow! Thank you for all the answers! I'm really happy...

D. Rasor,
Thank you for the file, i will take a look closer on it.

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.

Marek Dorsic,
I've not looked for this file because what i'm doeing is: stop ntp daemon
syincing and then start only computing the offset.

Trent Piepho,
If I generate clock with PWM outputs I can confirm that drift is zero and
we have just some noises when compare it to the reference frequency. The
error is not in the clock generation on the SoC. This takes us a step more
closer to kernel related things...

Tom Holmes,
In this case, the timestamp comparisons are not made by using RTC data. But
the timestamps generated by kernel using the machine clock frequency or
something near this. As mentioned before, some hardwares has TSC (Time
Stamp Counter).

Guys... I'm attaching a picture of the drift of this x86 computer. First
case is without an external clock (running with the motherboard's ordinary
crystal oscillator), running free and then synchronized by chrony. The
second case is that the computer gets synchronized and them running free,
but with external clock replacing the ordinary crystal oscillator.

Case 1:

[image: image.png]

Case 2:

[image: image.png]

Best regards, and again: thank you for all answers!

Luiz


Em qua., 6 de jan. de 2021 às 11:26, Poul-Henning Kamp <phk at phk.freebsd.dk>
escreveu:

> --------
> Magnus Danielson writes:
>
> > 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.
>
> You're thinking of the integrator-windup issue ?
>
> Yeah, that's very old news.  I think I first documented it to Dave
> Mills in 1994, but I never managed to convince him to take my fix
> (Clamp I-term until D-term has the correct sign for the resiudal).
>
> That's when I started writing my own PLLs.
>
> In general, the driftfile should never be used if NTP has a network
> connection, it's raison-d'être was primarily the machines syncing
> time via telephone twice per day.
>
>
> PS: The drift file also soak up rounding/truncation errors in the
>     kernels timekeeping code.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
> _______________________________________________
> 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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 50192 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20210106/2dc08257/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 50192 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20210106/2dc08257/attachment-0001.png>