[time-nuts] Time in a cave

[Oz-in-DFW]

On 5/13/2015 1:01 PM, Tucek, Joseph wrote:
> In reply to everyone (but mostly Mark Spencer):
>
>> Does your "cave" have any connectivity to the outside world ?
> The cave has network connectivity, and is "network close" (but not physically close) to a high-quality surveyed GPS disciplined stratum 1 NTP server which we have permission to run off of.  The cave is actually partially underground, and the bit that isn't has building on top of it.  CDMA comes in enough to make your phone ring or receive a text, but phone calls are all "I'm amazed it didn't drop ye[call dropped]".  Antenna runs for GPS are not an option (I asked); it's too expensive/hard to get permission/too long, depending on which route to sky you want to take.
>
>> Are there any places your cave has connectivity to that might 
>> have enough of a sky view to provide periodic gps coverage ?
> See above, but yes.
>
>> Do you need a COTS (commercial off the shelf) solution or 
>> can you accept something that has been kludged together ?
> I can accept "semi-kludge".  Custom firmware on a model xyz phone sourced from ebay with a mere 5 wires soldered is great for fun time (and for fun I'd love to try it), but not so much for this.  Single COTS would be great (yeah, and I want a side of fries with my flying unicorn), but "here's two (or 3, or n) COTS things you usually won't plug together, but..." is fine.  Maybe 1 soldered wire....
>
>> Do you need a Peng or other professional to sign off on 
>> the solution ?
> Thank goodness no.  We also don't need traceability to NIST either.
>
>  A bit more information that people requested.  We only need to be 1ms to UTC (100us would make some people happier, but then so would a GPS antenna run).  The PTP sync inside the cluster, however, needs to be tight (sub 1 us if possible).  
PTP will do this if proper implemented, so it sounds like you're good
there.
> Holdover isn't critical (24 hour OK, weekend better, month is overkill) so long as sync within the cluster remains tight. 
This is where a lot of smart people get into trouble. Don't thing of
holdover as meeting all worst case specs.  Figure out what you /really/
need.  What will allow everything to work without catching fire?  Given
your description here, I'm guessing a millisecond or ten will do that as
long as local cluster relative accuracy is maintained.

It's really easy to over-specify this and get into exotic clock (for an
industrial application) territory. 100 usec in 72 hours is 3.86 e-10
which is still in the range of a */really/***good quartz oscillator.

There's a nice chart on slide 13 here:
http://freqelec.com/oscillators/understnding_osc_specs.pdf

I had a telecom customer that needed 5 us relative accuracy between all
nodes synced over GigE.  The specified 72 hour holdover at 1 us
(3.86E-12) and were surprised (and offended) when when we said it would
require a Rhubidium standard. After saner heads prevailed we were able
to ship standard product.
>  The cluster itself has proper hardware PTP support (NICs and switches) throughout, and is "low radius" -- 2 switch traversals from the grandmaster to each node tops.
>
> As for everyone's comments so far, it seems that there is an assumption that any PTP master worth its salt will keep its slaves tightly synced to one-another even if it has lousy sync to UTC.  Am I reading between the lines correctly?
Yes, the master will have a fairly low phase noise local oscillator as
it's internal reference. Everything will synch to that.  If all you are
doing is syncing the local cluster you don't even care about time
outside. This is true for most industrial applications that are just
syncing machinery.

-- 
mailto:oz at ozindfw.net    
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport)