If this is the 5071A on that online auction site, I found out from the seller that the error log shows "Cs oven timeout."
This might be because of a bad oven supply (expensive) or a bad tube (really expensive)! Stan -----Original Message----- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of time-nuts-requ...@febo.com Sent: Thursday, October 04, 2012 9:51 AM To: time-nuts@febo.com Subject: time-nuts Digest, Vol 99, Issue 30 Message: 6 Date: Thu, 4 Oct 2012 09:45:22 -0700 From: "Tom Van Baak" <t...@leapsecond.com> To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com> Subject: Re: [time-nuts] 5071A Cs Oven Message-ID: <CCE1197699D24CBDB6AC7D386B504875@pc52> Content-Type: text/plain; charset="iso-8859-1" Bob, Right, not good. There should be a fault message associated with it. Check the internal log. OTOH, to conserve cesium, I've heard that some people run 5071A in standby mode most of the time and only turn on the cesium for a fraction of an hour a day or a week (to recal the quartz). Running in this standby mode is also advisable if one wants the best short-term performance out of a 5071A, without the loop noise. In this respect it's just like a GPSDO - you get the best short-term performance if you turn off disciplining. /tvb > Hi > > Is "Cs oven: 0.0V" a good thing on a 5071A? > > I suspect not, since either it or GPS is off frequency. > > Bob ------------------------------ Message: 7 Date: Thu, 04 Oct 2012 09:46:38 -0700 From: Hal Murray <hmur...@megapathdsl.net> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Subject: Re: [time-nuts] Tracking NTP displacement and correlation between two clients. Message-ID: <20121004164638.c0fee800...@ip-64-139-1-69.sjc.megapath.net> Content-Type: text/plain; charset=us-ascii bow...@gmail.com said: > Due to reasons I really can't go into, a systems user is concerned with the > displacement of two servers from the same pair of stratum 2 NTP servers. > I'm convinced that it really isn an issue as long as the two systems in > question remain within a few 10's of ms. However, I have no off the shelf > method of collecting and correlating the data. Before I go out and invent > the wheel, I thought I would check and see if anyone has done such a thing > and saved the scripts and whatnot. Assuming you are running the standard ntpd... It includes all sorts of logging. Set up the two systems so they use each other as servers. Turn on rawstats. ntpd will add a line each time it exchanges a pair of packets with a server. That line will have the IP Address and 4 time stamps. See the documentation. Details are in monopt.html The 4 time stamps are: time the request left the local system time the request arrived at the remote system time the response left the remote system time the response arrived at the local system If you subtract the first two, you get the network transit time for the request packet as skewed by the clock offset. Subtracting the last two gives you the transit time for the response packet. If you assume the network transit times are equal, you can compute the clock offset. If you are on a LAN, the transit times will probably be tiny on the scale of 10s of ms. (If you assume the clocks are both accurate, you can compute the network transit time in each direction.) If you want to graph the results, you have to split out the lines for the server you are interested in. Then you can feed it to gnuplot/whatever. You can also do the monitoring from another system, but then you have to sort out what happens when the clock on that system is off. How good is your connection to the big bad internet? If you run a big download over a slow link, the queuing delays can confuse ntp. You might want to look at the timings from your systems to the stratum-2 servers and/or from the stratum-2 servers to the outside world. -- These are my opinions. I hate spam. ------------------------------ Message: 8 Date: Thu, 4 Oct 2012 18:50:31 +0200 From: Attila Kinali <att...@kinali.ch> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Subject: Re: [time-nuts] Tracking NTP displacement and correlation between two clients. Message-ID: <20121004185031.b49767822c28ff64c18b5...@kinali.ch> Content-Type: text/plain; charset=US-ASCII On Thu, 04 Oct 2012 09:46:38 -0700 Hal Murray <hmur...@megapathdsl.net> wrote: > If you assume the network transit times are equal, you can compute the clock > offset. If you are on a LAN, the transit times will probably be tiny on the > scale of 10s of ms. Within a LAN, RTT is usually in the range of 200us with a jitter in the same range (it can happen that jitter is significanlty higher than RTT, if you have bursty traffic in your LAN) Attila Kinali -- There is no secret ingredient -- Po, Kung Fu Panda ------------------------------ _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts End of time-nuts Digest, Vol 99, Issue 30 ***************************************** _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.