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

[Hal Murray]

> 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.



-- 
These are my opinions, not necessarily my employer's.  I hate spam.