[time-nuts] x86 CPU Timekeeping and clock generation

[Tom Holmes]

Am I missing something or maybe I don't understand
the situation , but I am under the impression that
the RTC has it's own battery and crystal unrelated
to the processor clock. Seems like in that case,
the 24 MHz won't have any effect on the
timekeeping drift. 

Tom Holmes, N8ZM

-----Original Message-----
From: time-nuts <time-nuts-bounces at lists.febo.com>
On Behalf Of Trent Piepho
Sent: Wednesday, January 06, 2021 6:03 AM
To: Discussion of precise time and frequency
measurement <time-nuts at lists.febo.com>
Subject: Re: [time-nuts] x86 CPU Timekeeping and
clock generation

On Tue, Jan 5, 2021 at 9:42 PM Luiz Paulo Damaceno
<luizpauloeletrico42 at gmail.com> wrote:
> The 24 MHz comes from an synthesizer that is
locked to an atomic clock, the
> clock of NTP server (also 24 MHz, but an
embedded board (Tinkerboard)) also
> comes from the same Atomic clock that is feeding
other synthesizer for
> generates 24 MHz to this board.

The RK3288 has some PWM generators.  These are of
course also fed from
PLLs derived from the same 24 MHz input.

So, why not produce a signal on the PWM that can
be compared to your
reference?  This would tell you if the error is in
the clock
generation on the SoC or something in software
that happens afterward.
Or at least as far as the PWM clock tree overlaps
the kernel
timesource clock tree, which could be the CPU
clock but it can be
other things too.

> The experiment is the following: 1- synchronize
the computer's clock to NTP
> server then leave it running free (no periodic
synchronization), 2 -

NTP will set the frequency skew too, so even if it
is not doing
periodic synchronization, there may still be a
programmed frequency
skew.

_______________________________________________
time-nuts mailing list -- time-nuts at lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_l
ists.febo.com
and follow the instructions there.