Tom,
Consider that the RTC clock will be operating of a battery when no power
is applied. For the power used, it's actually quite impressively good.
Then, the other clocks is selected for various other properties, but
even with quality brands, we would consider them very cheap and of
dubious qual
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.
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.
Who knows what evil lurks in the minds of
engineers? And I am one!
Tom Holmes, N8ZM
-Original Message-
From: time-nuts
On Be
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 on
> 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 tha
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 co
Tom,
The RTC typically has a wristwatch type 32,768 kHz resonator. This is
independent to the oscillator setting bus and processor speed. They have
common factors in temperature and other environment, but nothing
steering them together.
You can have more independent oscillators, so things can dri
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 b
Spectracom 8195B Option 14 appeared on eBay
GPS Ageless Master Oscillator, uses a 12-channel GPS receiver
https://www.ebay.com/itm/Spectracom-8195B-GPS-Ageless-Master-Oscillator-w-Opt-14-/373419711644
Option 14 (Data Sync outputs)
CTCSS Outputs, replaces the 33-1/3 Hz and 17-2/3 Hz signals with
CT
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 readi
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)
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.
Y
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 Mess
Hello,
As pointed by others, probably the ntpd is applying a correction based
on its last measured drift. If you have synchronized the test computer
to the server via Ethernet, the drift value usually wanders somewhat (it
should be perfectly zero since both test computer and server clocks are
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
> generates
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
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 are
19 matches
Mail list logo