> 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. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
