On Wed, 6 Jan 2021 12:06:35 -0800, you wrote:
>14.31818 MHz is 4x the NTSC colorburst frequency (~3.58 MHz). It is also
>3x the original PC CPU clock frequency (~4.77 MHz).
And many years ago, when Never Twice the Same Color was new, a radio
ham in Manhatten wass working 80-meter CW* running a
ry 06, 2021 6:36 PM
> To: Discussion of precise time and frequency
> measurement
> Subject: Re: [time-nuts] x86 CPU Timekeeping and
> clock generation
>
> On Wed, Jan 6, 2021 at 6:26 AM Tom Holmes
> wrote:
>> Am I missing something or maybe I don't
> understand
>&
thol...@woh.rr.com said:
> Thanks to Chris, Magnus, and Trent for clearing things up. Never would have
> expected going to the effort of putting in a cheap clock, only to use it very
> little.
The frequency of your clock determines the granularity of a simple/quick
read-the-clock operation.
On Behalf Of Trent Piepho
Sent: Wednesday, January 06, 2021 6:36 PM
To: Discussion of precise time and frequency
measurement
Subject: Re: [time-nuts] x86 CPU Timekeeping and
clock generation
On Wed, Jan 6, 2021 at 6:26 AM Tom Holmes
wrote:
>
> Am I missing something or maybe I don't
unde
On Wed, Jan 6, 2021 at 6:26 AM Tom Holmes wrote:
>
> 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
> 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
Tom Van Baak writes:
>If you do your kernel timekeeping in integers and modulus arithmetic you
>are essentially doing cycle counting and the kernel will keep perfect
>time relative to the external oscillator. So that should be the goal.
>Not e-6, not e-9, not e-10, but perfect cycle
MHz won't have any effect on the
> timekeeping drift.
>
> Tom Holmes, N8ZM
>
> -Original Message-
> From: time-nuts
> On Behalf Of Trent Piepho
> Sent: Wednesday, January 06, 2021 6:03 AM
> To: Discussion of precise time and frequency
> measurement
> Subject: Re: [time-nuts]
Kasper,
> A short run here using the latest kernel gives an error of < ± 2e-10
> on 14.31818MHz hpet, and 0.5ppm on tsc.
Ah, we know that frequency well
14.31818 MHz is 4x the NTSC colorburst frequency (~3.58 MHz). It is also
3x the original PC CPU clock frequency (~4.77 MHz). And 12x an ISA
Hi,
On 2021-01-06 14:18, Poul-Henning Kamp wrote:
>
> 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,
On 06.01.2021 06.35, Luiz Paulo Damaceno wrote:
> Hi all,
>
> I'm studying computer's timekeeping and i'm on level of remove the base
> crystal that feeds the entire PLL logic of the motherboard (24 MHz on
> motherboard that i'm using) and compare system's time with an NTP server.
>
(After
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)
Message-
From: time-nuts
On Behalf Of Trent Piepho
Sent: Wednesday, January 06, 2021 6:03 AM
To: Discussion of precise time and frequency
measurement
Subject: Re: [time-nuts] x86 CPU Timekeeping and
clock generation
On Tue, Jan 5, 2021 at 9:42 PM Luiz Paulo Damaceno
wrote:
> The 24 MHz co
On Tue, Jan 5, 2021 at 9:42 PM Luiz Paulo Damaceno
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
>
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 -
marek.dor...@gmail.com said:
> 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.
The drift file only gets updated occasionally. (it's trying to avoid wearing
out
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
> 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
Hi all,
I'm studying computer's timekeeping and i'm on level of remove the base
crystal that feeds the entire PLL logic of the motherboard (24 MHz on
motherboard that i'm using) and compare system's time with an NTP server.
The 24 MHz comes from an synthesizer that is locked to an atomic clock,
19 matches
Mail list logo
