[time-nuts] 5071A Cs Oven

[Bob Camp]

Hi

This is one that's been close at hand for the last 15 years or so....

Bob

-----Original Message-----
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Stan
Sent: Thursday, October 04, 2012 1:58 PM
To: time-nuts at febo.com
Subject: Re: [time-nuts] 5071A Cs Oven

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-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of time-nuts-request at febo.com
Sent: Thursday, October 04, 2012 9:51 AM
To: time-nuts at 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" <tvb at LeapSecond.com>
To: "Discussion of precise time and frequency measurement"
	<time-nuts at febo.com>
Subject: Re: [time-nuts] 5071A Cs Oven
Message-ID: <CCE1197699D24CBDB6AC7D386B504875 at 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 <hmurray at megapathdsl.net>
To: Discussion of precise time and frequency measurement
	<time-nuts at febo.com>
Subject: Re: [time-nuts] Tracking NTP displacement and correlation
	between two clients.
Message-ID:
	<20121004164638.C0FEE800037 at ip-64-139-1-69.sjc.megapath.net>
Content-Type: text/plain; charset=us-ascii


bownes at 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 <attila at kinali.ch>
To: Discussion of precise time and frequency measurement
	<time-nuts at febo.com>
Subject: Re: [time-nuts] Tracking NTP displacement and correlation
	between two clients.
Message-ID: <20121004185031.b49767822c28ff64c18b5ca1 at kinali.ch>
Content-Type: text/plain; charset=US-ASCII

On Thu, 04 Oct 2012 09:46:38 -0700
Hal Murray <hmurray at 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 at 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 at febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.