Re: [time-nuts] PC clock comparison software?
For test purposes I've occassionally set the time server polling
routine to once a day and seen 20 minute errors on delinquent PCs.
Other PCs might stay within a minute.
1 min per day is 694 ppm
20 min per day is 13880 ppm
ntpd calls the crystal inaccuracy drift. ntpd can't handle a clock drift of
more than 500 ppm. 100 ppm is reasonable. That's 8.64 seconds per day.
(This PC is 115.755 ppm)
Long before serious time keeping software, we used to set the equivalent of
the drift correction by hand. That got us to a second per week or so on
machines that were in a server room with reasonable air conditioning.
My guess on your systems that are off by 20 min would be interrupts
disabled/busy for long enough so that clock interrupts get lost. It's easy
to tickle that if you do a lot of disk activity on a Linux box with DMA
disabled on the disks. (Or was a few years ago. I haven't tried it
recently.) Were all those way-off clocks running slow?
If you can get ntp running on all/most of your systems, it's pretty easy to
setup one system to monitor all the others. Turn on logging (peerstats) and
add each system you want to monitor as a server (in your config file) with
the noselect option. Tweak minpoll/maxpoll if you want to adjust the amount
of data you collect.
Our network is about 30 PCs on fiber OC12 ( 622Mbps) ATM with 100mbps
ethernet network branches. In the near future some video conferencing
and remote telescope users will add to the chunkiness of the network
variable load.
I wouldn't expect network troubles unless parts of your network are seriously
overloaded.
It's pretty easy to see busy DSL links.
The ntp log files will tell you the round trip time as well as the offset of
the other system. ntpd assumes network delays are symmetric. If you know
the clocks on both ends are good (say both have GPS) you can measure the
network delays in each direction. That is the observed offset is really an
asymmetric delay.
--
These are my opinions, not necessarily my employer's. I hate spam.
I could be talking a lot of hot air, so please forgive me, but I've
had a thought: if PCs still use a Real Time Clock chip, could a hardware
modification be done to give them an accurate clock frequency, rather
than relying on whatever cheap crystal is installed on the mother board?
Maybe one of the aforementioned TAPR Clock-Blocks configured for, I
guess, a 32768 Hz output?
I am worried by Hals comment though, that NMIs could upset the clock
-
that suggests the PC clock is not just a simple RTC, which would render
the above suggestion invalid. Oh well, just a thought thrown into the
arena.Peter
Peter Vince said the following on 12/20/2006 10:11 AM:
I could be talking a lot of hot air, so please forgive me, but I've
had a thought: if PCs still use a Real Time Clock chip, could a hardware
modification be done to give them an accurate clock frequency, rather
than relying on whatever cheap crystal is installed on the mother board?
Maybe one of the aforementioned TAPR Clock-Blocks configured for, I
guess, a 32768 Hz output?
One sad thing is that the Clock-Block can't generate a precise 32768 Hz
given a common (1, 5, or 10 MHz) input frequency. The available divider
ratios just don't work out.
(By the way, though, the Clock-Block might be useful for some
low-frequency clocking tasks. The main synthesizer chip is spec'd for
output down to 2MHz, though it can go quite a bit lower than that, but
there is an additional divider chip on the board that can be used to
divide the synthesizer output by factors from 16 to 16384.)
John
The Timer/Clock interrupt is IRQ 0 no other interrupt has a higher priority,
therefore this interrupt is rarely missed. If it were missed then interrupts
would have to be turned off longer the 110ms (2 times the clock rate) which is
an enormous amount of time and due no doubt to an improperly written device
driver or faulty motherboard/card.
Having said this; a device driver writer would not have interrupts turned off
for long anyway, this is a bit heavy handed on a system. That's what IRQL are
for.
99.9% of ISR routines are microsecond range. So this is not a source of lost
timer interrupts.
Time is extremely important on a telescope (which why I'm going to try the TAPR
Clock Block when I get time) and I've studied this issue of lost timer
interrupts. I can tell you that they just don't occur even when the system is
loaded to the max. We have a watchdog card in our system to detect just such an
event, it has never triggered (except when you push the test button).
Jack
Lots of good info as always from this list.
I probably should mention what some of these PCs are doing.
Someone asked about the telescope control PCs. The 26m dishes have their own
dedicated GPS receivers for their local time standards. Those do the
celestial navigation and tracking via their control PCs.
Our optical telescope control PCs are almost all on XP or Win2000. So NTP
should have them covered reasonably well. Test software would confirm how
well.
The PCs that tend to misbehave the most are Win98se Pentium 100 ~ 400 MHz.
They are doing a variety of menial tasks like: seismic data, solar flare
monitoring, meteor burst recording, VLF signal recording for Sudden
Ionospheric Disturbances, and cosmic ray montoring. They churn along at 4 ~
40 samples per second typically of constant data flow to the hard drive.
Every minute or so they may push a screen capture to our website.
Others with a somewhat higher workload are doing webcam or weather station
image pushes to our website once a minute.
For time/frequency we have two Z3816As and a Ball Efratom MRT free running
Rubidium frequency standard. I tweak it using an HP53131time interval
counter compared to the Z3816A. GPSCon V1.038 is the software running on a
Win98se box. I have a newer XP box I've been trying to move to for better
serving reasons. But it keeps turning itself off every night even though
we've tried to turn off power saving and automatic updates. Its on a UPS
with four 100AH batteries, plus four 7AH gel cells on float on the Z3816A
48vdc power side. The slightest power glitch still takes the XP computer
down even though its on the UPS. But the Win98se P166 plugged into the same
outlet strip on the same UPS weathers it all for months at a time without
rebooting.
The main network servers are Linux of one variety or another. Not sure what
the latest flavors are, but mostly Red Hat Linux Fedora Core I think.
The network glitches are probably power glitch related even though most
things are on UPSs. We're pretty far up in the mountains, so lightning and
AC supply side glitches are common. And the sheer size of the facility
induces surges from EMP transferred cable to cable on site too. The primary
fiber links are via 3Com ATM Core Builders with redundant fiber links. Its
mostly once things get out to the localized 8~24 port switches that latch up
occurs I think. Diagnostic code would help troubleshoot that since I could
see which branches failed when, and if they recover. Network loading is
minimal except from the main website server to the Internet via T1 ( soon
OC3, then that will be minimally loaded too except during distance learning
and video conferencing).
tnx,
Charles S. Osborne, K4CSO
Technical Director
Pisgah Astronomical Research Institute
1 PARI Drive, HC 73, Box 638
Rosman, NC 28772-9614
http://www.pari.edu
828-862-5813 direct
828-862-5554 main
828-862-5877 FAX
cosborne@pari.edu
Probably what to take this off list.
Eek screen capture. That's one of those heart stoppers on the Win9x platforms,
it's got nothing to do with Windows, it the device driver in some of those old
cards that CLI (Clear interrupts) for a long period. We had issues with this
causing Netware Client's to start outputting wrong time stamps IIR (It's been 12
years).
We solve the power glitch issue with an isolation transformer. We're at the end
of a 15 miles of power line and like you, it pickups a lot of trash on the way.
I'm sure your guys have done this, but it doesn't hurt to check. Failing that
try to push through a req for a toroidal type UPS, there you get isolation with
virtually instant cutover. The only issue I have with them is making sure you
turn them on without any load; in a glitchy environment the huge current in-rush
would cause all the UPS's on that circuit to trip.
If you can setup a NTP server that Win98se box with the GPSCon on it; that would
solve your time synchronization issues.
Question: What are they using to sample data with? Some sort of National
Instruments DAC, GPIB, HPIB device, or network?
Jack
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf
Of Charles S. Osborne
Sent: Wednesday, December 20, 2006 2:30 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] PC clock comparison software?
Lots of good info as always from this list.
I probably should mention what some of these PCs are doing.
Someone asked about the telescope control PCs. The 26m dishes have their own
dedicated GPS receivers for their local time standards. Those do the
celestial navigation and tracking via their control PCs.
Our optical telescope control PCs are almost all on XP or Win2000. So NTP
should have them covered reasonably well. Test software would confirm how
well.
The PCs that tend to misbehave the most are Win98se Pentium 100 ~ 400 MHz.
They are doing a variety of menial tasks like: seismic data, solar flare
monitoring, meteor burst recording, VLF signal recording for Sudden
Ionospheric Disturbances, and cosmic ray montoring. They churn along at 4 ~
40 samples per second typically of constant data flow to the hard drive.
Every minute or so they may push a screen capture to our website.
Others with a somewhat higher workload are doing webcam or weather station
image pushes to our website once a minute.
For time/frequency we have two Z3816As and a Ball Efratom MRT free running
Rubidium frequency standard. I tweak it using an HP53131time interval
counter compared to the Z3816A. GPSCon V1.038 is the software running on a
Win98se box. I have a newer XP box I've been trying to move to for better
serving reasons. But it keeps turning itself off every night even though
we've tried to turn off power saving and automatic updates. Its on a UPS
with four 100AH batteries, plus four 7AH gel cells on float on the Z3816A
48vdc power side. The slightest power glitch still takes the XP computer
down even though its on the UPS. But the Win98se P166 plugged into the same
outlet strip on the same UPS weathers it all for months at a time without
rebooting.
The main network servers are Linux of one variety or another. Not sure what
the latest flavors are, but mostly Red Hat Linux Fedora Core I think.
The network glitches are probably power glitch related even though most
things are on UPSs. We're pretty far up in the mountains, so lightning and
AC supply side glitches are common. And the sheer size of the facility
induces surges from EMP transferred cable to cable on site too. The primary
fiber links are via 3Com ATM Core Builders with redundant fiber links. Its
mostly once things get out to the localized 8~24 port switches that latch up
occurs I think. Diagnostic code would help troubleshoot that since I could
see which branches failed when, and if they recover. Network loading is
minimal except from the main website server to the Internet via T1 ( soon
OC3, then that will be minimally loaded too except during distance learning
and video conferencing).
tnx,
Charles S. Osborne, K4CSO
Technical Director
Pisgah Astronomical Research Institute
1 PARI Drive, HC 73, Box 638
Rosman, NC 28772-9614
http://www.pari.edu
828-862-5813 direct
828-862-5554 main
828-862-5877 FAX
cosborne@pari.edu
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts