[time-nuts] Can Lady Heather Keep Computer Clock On Time?

Brooke Clarke brooke at pacific.net
Thu Jul 29 19:59:08 EDT 2010

Hi Hal:

The key thing is pointing, not tracking (where a guide star is commonly 
A TPoint model is made by pointing to known stars and the quality of the 
model depends on good computer time.

Have Fun,

Brooke Clarke

Hal Murray wrote:
>> The telescope can point to within arc seconds of a star and that implies
>> that the computer clock needs to be within 50 ms.
>> If he does a Windows NTP sync first thing in the evening after a few hours
>> there's too big an error.
> That looks like the classic time vs frequency problem.
> What is the primary goal?  Pointing or tracking?  Pointing requires time.
> Tracking requires frequency.
> If you are otherwise happy with "Windows NTP sync", you may be able to solve
> your problem by doing a sync before pointing at another object if it's been
> more than N hours since the last sync.
> Long song and dance....  [Remember, I don't run Windows so I may screwup
> anything that's Windows specific.]
> The typical PC has 2 crystals.  One runs at 32 KHz.  The other is usually
> 14.xxx (from early PC days) that gets PLLed up to make clocks for the CPU and
> PCI and USB and ...
> The 32KHz crystal runs the battery backed RTC/TOY/CMOS clock.  It's a watch
> crystal so it should be pretty good.  But it's not very convenient for
> keeping time at the microsecond level.
> The 14 MHz crystal is stable, but typically not very accurate.  (Remember low
> cost.)  That's accurate at the PPM level, it will be fine if you just put a
> scope on it.  It may be off by 50  PPM.  Even if the hardware is good, the
> software can screw things up.  (Linux is good at this.  Current kernels don't
> get a consistent answer on the same hardware.  Jumps by 200 PPM from boot to
> boot are not uncommon.)
> [Network and audio and ??? cards typically have a separate crystal.  They are
> usually not convenient for timekeeping but if you do serious audio work you
> can measure it's actual frequency.]
> Let's see if I can do the math right...
> 3 hours is 10,000 seconds.  50 PPM times 10,000 seconds is 500,000
> microseconds.  So if the clock is off by 50 PPM, it will drift 1/2 second in
> 3 hours.  Even 5 PPM will drift 50 ms in 3 hours.
> The main reason for running real ntpd rather than just setting the time
> occasionally is that ntpd will figure out how far off the frequency is and
> correct for it.  ntpd calls that fudge factor "drift" and prints it out in
> PPM with 3 digits to the right of the decimal point.
> If all you need is 50 ms, you should be able to get that most of the time by
> just running ntpd over the net.  It's sure worth a try.  It may not be good
> enough if you have a crappy net connection or change from no-load to
> uploading tons of data from observations earlier in the evening.  (Contact me
> off list if you want help in monitoring a ntp server and/or setting up and
> interpreting its log files.)
> Odds and ends to keep in mind...
> Modern PCs use spread spectrum clocking.  That fudges things by 1 or 1/2 % or
> so which is huge in terms of PPM.  The point is that you have to measure it.
> Just doing the math from the nominal CPU frequency isn't good enough.
> The actual frequency is temperature dependent, so things will change if you
> open the roof and let the cold air in or the CPU changes from idle (or off)
> to working hard.  The ballpark is 1 PPM per 10 F.
> One of the classic ways to screwup timekeeping is to miss interrupts,
> typically because some other interrupt routine is running too long.  This was
> easy to tickle on (very) old Linux systems that used PIO rather than DMA for
> disk transfers.  I only mention it because you might have some strange
> hardware with buggy interrupt routines.
> Normal Windows clocks tick every 10 ms.  Windows has a multimedia mode that
> does much better.  There is a switch in the Registry or something.  It may
> help to use that mode.  I think you want to leave it on.  (The Meinberg
> ntpd-installer package turns it on.)
> ntpd is both a client and server.  A system will act as a client to get time
> from lower stratum servers and act as a server to provide time to higher
> stratum servers.

More information about the time-nuts mailing list