Re: Cost-effectivenesss of highly-accurate clocks for NTP

[Lamar Owen <lowen () pari edu>]

On 05/13/2016 03:39 PM, Eric S. Raymond wrote:
> Traditionally dedicated time-source hardware like rubidium-oscillator 
> GPSDOs is sold on accuracy, but for WAN time service their real draw 
> is long holdover time with lower frequency drift that you get from the 
> cheap, non-temperature-compensated quartz crystals in your PC. There 
> is room for debate about how much holdover you should pay for, but 
> you'll at least be thinking more clearly about the problem if you 
> recognize that you *should not* buy expensive hardware for accuracy. 
> For WAN time service, in that price range, you're wither buying 
> holdover and knowing you're doing so or wasting your money. 

Eric,

Thanks for the pointers; nice information.

A cheap way to get a WAN frequency standard is to use a WAN that is 
delivered over something derived from the telco's synchronous network; a 
POS on an OC3 with the clock set to network has an exceptionally stable 
frequency standard available.  Less expensive, get a voice T1 trunk 
delivered (robbed-bit signaled will typically be less expensive than 
PRI) and grab clock from that; tarriffs for RBS T1/fractional T1 around 
here at least are less than an analog POTS line).  Very stable.  The 
plesiochronous digital hierarchy on copper or synchronous digital 
hierarchy/SONET on fiber have cesium clocks behind them, and you can get 
that stability by doing clock recovery on those WAN circuits.  Back when 
this was the most common WAN technology frequency standards were there 
for the taking; Ethernet, on the other hand, not so much.

But a nice catch on using the isochronous nature of USB.  Cheap webcams 
also take advantage of the isochronous transfer mode.  Do note that 
isochronous is often not supported in USB-passthrough for 
virtualization, though.  But you shouldn't use a VM to do timing, 
either. :-)

Now I'm looking for myself one of those Navisys devices you 
mentioned..... do any of them have external antenna inputs, say on an 
SMA connector (MCX is in my experience just too fragile) with a bias tee 
to drive phantom to an active antenna?  The quick search I did seemed to 
indicate that the three you mentioned are self-contained with their own 
smart antenna.  External antenna input would be required here, where we 
use timing-grade GPS antennas to feed our Z3816's.  But for straight 
1PPS and GPS timecode, dealing with the Z3816's complexity is overkill.

Thanks again for the info; looking forward to seeing how NTPsec develops.