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:o...@ozindfw.net Oz POB 93167 Southlake, TX 76092 (Near DFW Airport) _______________________________________________ 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.