Re: Variations on XTAL clock AND time synchronization

From: Dave Platt (dplatt_at_radagast.org)
Date: 02/19/05 

Date: Sat, 19 Feb 2005 18:38:17 -0000

>Jerry G.,
>
>Thank you for your valuable answer.
>In a project I need to have time synchronization between a set of computers
>where some of them are networked together on a LAN (no internet) and some
>others are running stand alone. I am planning to use the
>one-pulse-per-second (1PPS) signal from the GPS receivers. The networked
>computers will have one GPS receiver and all the other stand alone computers
>will have their own GPS receivers. GPS receivers will generate 1PPS signals
>to interrupt the computers to set their internal time clocks. Applications
>will use the computer timer (get the time of the day). I want to model (some
>how, but I do not know how) the probable variation that a computer clock may
>have between 1PPS signals.

For those computers which are LAN'ed together, you should certainly
consider running NTP. The commonly-used "ntpd" daemon for Unix and
Linux and etc. will handle the inter-system coordination, and also has
drivers for most GPS and similar external clock systems (including the
PPS input).

The PPS pulses are infrequent enough, and subject to enough jitter,
that the drivers will need to do a fairly significant amount of
low-pass filtering before using the pulse information to calibrate the
internal clock.

>Would anyone comment/argue/recommend/suggest/propose how one can model the
>variation on a PC clock frequency ?

As I understand it, you're going to be dealing with at least two
separate "clocks" per PC.

One is the on-board date/time-of-day clock chip, which is typically
driven by (or drives) a 32.768 kHz quartz low-power "watch crystal".
These usually seem to have accuracies in the 10-15 seconds per month
range, like a cheap wristwatch. This part of the hardware is designed
to provide a coarse setting of the date and time when the system is
booted, and as I understand it the interface to the chip usually does
not provide a way to read or set the time to any precision greater
than +/- 1 second.

The other is the system's main CPU or bus oscillator, which is divided
down and generates interrupts at a predictable rate (many per second)
and/or is used to run a high-speed counter within the CPU itself.
This is also a quartz-crystal oscillator. It has a higher readout
precision than the clock chip, but you have to be careful about using
it... if you try to track the time-of-day by counting clock interrupts
(as I believe Linux does) you can "lose time" if another device
driver, or the BIOS itself, locks out interrupt processing for more
than a few milliseconds.

These two clocks/oscillators are not correlated with one another as
they're driven by separate quartz crystals. Both are subject to error
and drift due to temperature changes, but there's no guarantee that
the two crystals have identical or even similar temperature
coefficients of change.

The Unix "ntp" daemon software is able to estimate a given system's
amount of clock error and keep a record of the amount of drift (in
parts per million), and will load this value and use it to tweak the
clocking when the system is booted.

As to modelling the error you see on a PC's clock: you're going to
have to deal with several sources of error. To a first approximation,
you can consider the PPS data to be "short-term jittery, but
long-term stable". The 60 Hz powerline frequency is similar...
jittery in the short term due to noise, somewhat drifty over the
course of a day, but quite stable in the average over the long term.

The PC's quartz crystal oscillators are probably at about the opposite
end of the spectrum - quite stable in the short term, with a fairly
constant amount of error (in PPM) in the long term, and some amount of
temperature-related drifting around in the middle.

You might find it useful to review the information on Brooks Shera's
page at http://www.rt66.com/~shera/index_fs.htm - he discusses the
construction of a system which uses a GPS receiver's PPS signal to
discipline a high-stability quartz crystal oscillator. 

-- 
Dave Platt <dplatt@radagast.org>                                   AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
  I do _not_ wish to receive unsolicited commercial email, and I will
     boycott any company which has the gall to send me such ads!

Relevant Pages

  • Re: Variations on XTAL clock AND time synchronization
    ... >computers will have one GPS receiver and all the other stand alone computers ... but I do not know how) the probable variation that a computer clock may ... they're driven by separate quartz crystals. ... amount of clock error and keep a record of the amount of drift (in ...
    (sci.electronics.components)
  • Re: Variations on XTAL clock AND time synchronization
    ... >computers will have one GPS receiver and all the other stand alone computers ... but I do not know how) the probable variation that a computer clock may ... they're driven by separate quartz crystals. ... amount of clock error and keep a record of the amount of drift (in ...
    (sci.electronics.misc)
  • Re: XP tantrums... Memory ?
    ... I tried it on 2 identical computers. ... The 2nd I was never able to over clock and finally decided to run at the bios defaults. ... ...So I suppose my question is, "If (higher spec.) memory degrades in some way, such that after a few months it will no longer run reliably at ...
    (microsoft.public.windowsxp.general)
  • Re: Announcement: New PL/I kit for Alpha
    ... where OS designers didn't expect computers to be that fast. ... One is in VM/370 where a tight loops is expected to take some number of clock ticks. ... On actual S/370 hardware, by definition, every instruction takes at least one clock tick. ... If the instructions go too fast, either the clock has to have a higher resolution or the instruction processor has to slow down. ...
    (comp.lang.pl1)
  • Re: Summer hols
    ... And with that strange English accent as well? ... verbal acknowlegement or saying the amount. ... computers not acknowledging or doing what ...
    (uk.local.cumbria)