FLASH: GPS SA discontinued MJD 51666!  Maybe some satellites started a little earlier, but around midnight EDT (04:06Z) things really improved (even though the first URA value changes were not broadcast until a few hours later).  On the first couple graphs, the UTC day started at about 39000 seconds so look starting around 53200 for less "noise" (smoother) somewhere near the average.  Sorry that my TAC data doesn't include the sawtooth correction (which would smooth it more and probably chop a little off the top/bottom).  The non-SA 58503A looks to be ~31ns peak-to-peak, near an order of magnitude stability improvement especially from around 100 to 2500 seconds averaging time.
I'll integrate these couple below someday...

I'm not especially comfortable with the term "atomic clock" because such devices really just know exactly how long a second lasts. The proper name for mine is the (Agilent) HP 5071A-001 Primary Frequency Standard (with high performance tube based on cesium or cęsium for those of you outside the US). The beginning of the second must be referenced somehow to the official international time which is typically UTC(BIPM). I also have another "atomic clock", the HP 5065A Rubidium vapor frequency standard (replaced some capacitors after discovering major problems on boards such as A15 and A8). Although Rb is considered "atomic", it must be referenced to a more official standard such as Cs (or GPS, etc).

In the picture below, the light colored unit on the second shelf from the top on the right (with red LED digits and open panel) is my master clock, and the unit at the left of same shelf is another 5071A (above the master clock are a couple of HP 5065A rubidiums).  In between those 5071As are my geodetic-quality GPS receiver from JPS (greenish) above a temperature measuring unit and a specialized Ashtech Z-12T receiver.  Underneath on the left is an HP 3488A for switching, HP 5087A for distributing 10MHz.  Below the master clock are some currently unused items like TST IRIG generator, 6460 & 6459 displays, pulse distribution, and a micro phasestepper.  In the middle of that shelf are Agilent(HP) 53131A and 53132As which are modern time interval counters, and above is the HP 58503A GPSDO which supplies UTC(USNO via GPS) and I use it for 10MHz external reference to the counters.  The bottom shelf contains plenty of APC UPS power and a PC, plus a Truetime NTS-200 NTP server, network equipment, cable/DSL modems, and some standard resistors.  The shelf with the PC display/keyboard has space for any unit-under-test (currently holding my old HP 5370B - sometimes also a heat sinked PRS10 Rb from SRS).  The blueish digits on the counter (averaging around 155ns) show me that my clock was basically on time (after accounting for antenna/cable delays).  Sometimes Hiding somewhere is a CNS Clock which is basically a TAC-2 with Motorola VP Oncore to provide me with another UTC(USNO via GPS).  I also have other spare equipment such as Austron Loran-C and disciplined oscillator, etc.  At the top left is a PC running Linux hooked to a real-time GPS network, and a spare Ashtech Z-12R.

To Doug Hogarth's Home Page (which has additional links relating to time)

What do I do with an atomic clock?  I experiment comparing to other clocks, trying to maintain my own timescale which I'll call UTC(DWH).  For accuracy, I can compare to the output from a GPS-based clock over the long term (that also shows stability over the long term).  The chart below plots how well I can obtain time from the TAC when averaging over some period.  The 1 Pulse Per Second output from TAC ranges about 399 nanoseconds (billionths of a second) peak-to-peak and it is noisy until after a couple thousand seconds.  Looks like about 6ns after a few hours, 5ns after a half-day, and 3ns after a day.  A later plot shows how short-term noise from the TAC can be reduced.

The next plot shows the corresponding information but instead of the TAC it uses the 58503A which ranges about 136ns peak-to-peak.  The stability starts out great but SA makes it get worse until around 1000 seconds where it becomes similar to the TAC (7ns after a few hours, etc).  Note that the first few points should not be trusted because my resolution was about 150 picoseconds.  Also, in another test it looked like the few ns level might take several days to reach and not get much better with additional days.

The next plot transitions to frequency using a more common method to present the same 58503A data (showing it is worst around 500 seconds).  It represents operation under SA; the second plot below shows how discontinuing SA dramatically improved the stability from averaging times of about one minute continuing out beyond a day.  As mentioned above, the first few points were not measured well enough.  See a later chart which shows stability better than 1e-13 after a day perhaps reaching near 1e-14 after about ten days.

The plots above focus on the level which can be obtained by averaging.  That is enough if I merely wanted to deal with the "rate" of my clock (frequency).  But I also want my 1PPS to be aligned to the proper nanosecond (phase).  That requires me to know the proper WGS-84 coordinates of my GPS antennas (so I use survey-quality methods as described elsewhere on this site), know the antenna cable delays, know the measuring cable delays, and any other delay such as a filter inside a GPS antenna or the absolute calibration of the receiver.  I have made such attempts and I believe that my RegAnt has about 18ns of delay (two different L1-only antennas have similar delay), that my 58503A has about 29ns of delay (some of which is presumably due to ignoring the troposphere model), and that my JPS receiver is a few ns advanced (not counting the additional delay in the RegAnt).

The following plot shows just over a day of the 1PPS from my JPS geodetic-quality receiver with the +/-12.5ns serial message applied.  It is with single-frequency C/A.  Stability seems as good as non-SA HP 58503A after about 12 minutes, and looked like around 17ns peak-to-peak.

The next plot tries dual-frequency ionosphere-free which so far seems to produce results with no dramatic difference.  Maybe there is a little more noise out to at least 15 minutes averaging time (due to less strong signal?) and peak-to-peak is around 22ns but presumably it will be less variation long term (which I will continue to track).

Since Rb might be better in the short term (<2500s) but then drifts, it can be interesting to compare.  In the plot below, we see a linear offset meaning the Rb is off frequency by about 1.15e-11.

However, after removing that linear offset, the apparent negative frequency drift quadratic in the plot below remains.  Rb ages (drifts in frequency), in this case the estimate is ~1.23e-11/month which is not quite spec (presumably due to fluctuating temperature).

So we remove that drift (and normalize about zero) to produce the plots below.  It shows that there was a daily cycle where the peak corresponds to overnight (cooler) - the Rb temperature coefficient is somewhere around 1.3e-12/C.  Note that if drift was not removed, the stability at around a day would be getting worse (~6e-13).  Due to my equipment, periods below about 300 seconds are not properly measured.

The plot below shows about 3.75 days from my Austron 2100R Loran-C frequency monitor (given the 5071A reference), a method used before GPS to transfer frequency between remote clocks.  It starts a few seconds after lock to GRI 9940's secondary at George WA.  Jumps of about 8ns can be easily seen, while the peak-to-peak is about 158ns.  GRI 5990 might have a little more noise?

The plot below shows why I don't use quartz frequency standards.  It shows my Austron 2110 disciplined quartz (given the 5071a reference).  Although the second-to-second data is "smooth", the peak-to-peak is ~25ns (some due to temperature changes).  If that is the performance locked to an excellent standard, it is presumably worse if looped only through my 2100R (a common setup).  Due to my equipment, periods below about 200 seconds are not properly measured.

The plot below shows how applying a negative sawtooth correction can improve the short term (<100 seconds) noise of the TAC, and it would presumably cut off about 40ns of the peak-to-peak (but it has a little problem of an ~12ns spike for a couple seconds every ~75 seconds).

Here is a half-day chart which shows that it takes a few hours after power-on for the 58503A to "settle down."

To Doug Hogarth's Home Page (which has additional pointers relating to time)