Re: [time-nuts] Time in a cave
On 05/12/2015 07:00 PM, Tucek, Joseph wrote: I'm looking for information on non-GPS time sources. ... My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. Would WWVB meet your requirements for periodic comparisons, or is this place too noisy for that? When you say 'cave' how deep are you talking? ___ 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.
Re: [time-nuts] Time in a cave
As many have already asked, the key is what accuracy you need and what precision you really need. I am well aware that defining those requirements is not a trivial task - even big organisations struggle with this (not talking about power and telecom). Another important question is what will be the impact of not meeting those requirements - do you know what happens if timing will be off? Will things will not work, or all results will look seemingly normal, but you will know that the results are potentially skewed? I'm making an assumption here that the end devices will be standard computer systems (i.e. running some major known OS) rather than some specialised equipment running proprietary firmware. Depending on what the requirement is, you can use different means of distributing time between your nodes. On the host side, you can use software-only PTP which can get you sub-10us with modern equipment at zero extra cost, or you can use hardware PTP which will get you the lower part of sub-microsecond. To be fair, with traditional servers, realistically you will not be able to get time into the OS kernel clock with precision much better than sub-100 nanoseconds even at best network conditions. This means that essentially any commercial PTP GM will suffice. Meinberg, Endrun, Microsemi, Juniper, they will all do it. All of those products can operate in freerun to hand-set time. As long as short-term drift variation of your time server / non-linearity over the sync message interval does not exceed your requirements, you may set it completely by hand. Any PTP or 1PPS solution is indoor capable. Also make sure that the network kit you're using shows relatively low latency, and first of all low packet delay variation (or jitter), and be prepared to see PTP hardware slave implementations that will not necessarily support PTP unicast / telecom profile. Meaning that your GM must support the default PTP profile (all multicast) and your network must be multicast aware - simple if it's the same VLAN, but less so when the traffic is distributed across different subnets. So this is inside your bubble. Now as to the external reference... Is it a cave or other remote location you're working in, or an access centre or data centre with no GPS service to customers and no roof access? What is your external connectivity looking like? Does this cluster have any link to call home? You could deliver external PTP from outside over a dedicated circuit, or even try doing this via a shared service - but over the Internet it will be too much for PTP. If it is a remote location, this may be an ideal task for a tool I've been using to calibrate timing kit in data centres. There are some products on the market that have battery backup - like TimePort: http://www.chronos.co.uk/index.php/en/timeport-2 - they should have some US distributors, but I'm sure there are also other products like this - this one uses the Symmetricom / Microsemi Chipscale Atomic Clock oscillator solution. The idea is that you take it outiside, let it sync and fully lock to GPS, then put it in holdover and bring it back in - and you have a 1PPS and 10MHz source with a few days worth of decent holdover. I think it can also do NMEA or some other Time of Day output. Then you sync your PTP GM periodically to that, you can even do it in maintenance windows. TimePort also does PTP by the way, so then you would need to purchase a PTP boundary clock with a decent oscillator that can survive the moments when you remove your reference. If you say that CDMA will work, a CDMA-PTP solution such as the Endrun one will work for you. I have worked with them and they do their job - OK, CDMA may not be a time source officially traceable to a primary reference like GPS is, but unless you're a purist, it will be better than freerun anyway. ...and finally, there is eLORAN :) Cheers, Wojciech On 13 May 2015 at 00:00, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My
Re: [time-nuts] Time in a cave
Harlan, On 05/14/2015 01:34 AM, Harlan Stenn wrote: NTF is working to improve the products under its umbrella all the time, and we're seriously resource-constrained. OK, we're disturbingly resource-constrained. While the PTPd folks seem to have enough developer resources and Richard Cochran has not complained about the developer resources for Linux PTP, none of the projects have adequate documentation writers. Work is silently being made to ensure that NTP vendors become NTF members, and that way start to pay back for the code they use and at least somewhat help solving the resource issues. Hope that you seen that in your end. Cheers, Magnus ___ 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.
Re: [time-nuts] Time in a cave
joseph.tu...@hp.com said: 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. That sounds like it is likely to be a reasonably common case. I'd expect the vendors for PTP grand masters to have a good solution. If network close is just cat-5 cable (no telco gear) to another building, you may be able to put your grand master over there and let PTP do it's thing to get the time back to where you want it. An alternative approach would be to put the GPS antenna and receiver over there and send the serial and PPS back over a cat-5 cable. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] Time in a cave
On 5/13/2015 4:44 PM, Tucek, Joseph wrote: In response to Oz-in-DFW Given your description here, I'm guessing a millisecond or ten will do that as long as local cluster relative accuracy is maintained. Spot on; I hope I'd made it clear earlier, but perhaps I've been communicating poorly. Sort of. All I remember without combing through the notes were subjective relative statements and no quantitative values. My goals w.r.t. to sync to UTC and w.r.t. holdover are very loose. I do need time sync intra-cluster to be tight (sub millisecond, 100 nano as a stretch goal). There are four orders of magnitude between 1 millisecond and 100 nanoseconds - that's a heck of a stretch. Is this what you really mean? What is the cluster doing that needs such good absolute time? did you mean 100 microseconds as a stretch (one order of magnitude.) UTC sync can comparatively be terrible; 10-1 ms is fine, 10 e -1 milliseconds as in 100 microseconds? This is achievable but will require some care. Even 10 ms is 'pretty darn good' for all but a very few industrial applications. Most datacenter applications I've done only guarantee 100 ms absolute. Internal distribution is much better of course. and I can live with bad NTP, 100 ms if I must. From specs, */really/* good quartz is my limit and /good/ quartz is acceptable, so long as it doesn't mess with the intra-node PTP tightness. It doesn't until it gets really bad. Like shattered bad. I'm mostly looking at TCXO options. OCXO isn't out of the question, but rubidium doesn't seem to give $/value. This begins to sound like you really don't know what you need and are specing the best you can afford to be sure. In my experience this is a good way to get bitten, because you really are not sure. Many industrial applications require excellent relative accuracy within a cluster. Time synchronizing chains of rotating machinery is surprisingly demanding, but you almost don't care about absolute accuracy outside the local clock domain. It's a rare application that /needs/ better than a second absolute. Most of these are 'big science' projects or infrastructure that covers a large geographical areas. Time errors can be catastrophic. If you are working with one of the rare ones, you really need to understand the real requirement and then design for that with margin. If not, you should still be able to estimate the absolute need and /then/ add margin to that. 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. Thanks for the info. PTP isn't as well understood/documented as NTP, so I've not been as certain about my decisions. Of course, that is fair for a relatively new standard. PTP is both well understood and documented, but it sounds like it's not for your industry and application. This tends to imply that it's not time critical. Currently, I think my two best options are: 1) CDMA enabled PTP appliance (set and forget), or No, for a few reasons: First, it's going away sooner than you think. Verizon says 2021, but they are doing everything they can to accelerate that. I'll be surprised if it's still viable in 2018. Analog cellular was shut off in February of 2008, but was barely useable in metro areas several years before that. The operators shut off all but the absolute minimum capacity to save costs and provide incentive to move to newer technologies. Expect your cave to lose coverage much sooner than 2021. Second, while in-spec cellular is a good frequency reference, there is no requirement for absolute time that you have access to. The time available over the air interface can be off by /minutes./ Typically it's within seconds of UTC and many operators now do far better than that. You are better off with WWVB or open Internet NTP in terms of predictable accuracy. 2) PTP appliance running as stratum 2 from good NTP. Yes, or something you operate that is network close and has a GPS reference. Thanks to everybody for the feedback. -joe -- 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.
Re: [time-nuts] Time in a cave
If you don't require an accurate external sync (GPS), one options is to use solarflare 10GB NIC's with the high resolution clock on board, using this clock to govern the PC clock.Running PTP through this can yield +-250ns synchronisation between the nodes due to the hardware implementation for the PTP stack and does support external sync to a GPS PTP signal if available. I have no association with the company, but I like the product. http://www.solarflare.com/Precision-Time-Synchronization-PTP J. On Wed, May 13, 2015 at 9:00 AM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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. -- -- Teach your kids Science, or somebody else will :/ ja...@ball.net vk2...@google.com vk2f...@google.com callsign: vk2vjb ___ 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.
Re: [time-nuts] Time in a cave
On 5/12/2015 6:00 PM, Tucek, Joseph wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe LTE and WCDMA both provide time, but it's a function of how carefully the operators actually maintain it. That's less of a problem today, but there are no absolute /guarantees/, even with IS-95 CDMA. The only guarantee is that the basestations in the system will track within a few microseconds of each other. What you don't say is how much accuracy you need. Is a hundred milliseconds enough, or do you need sub-microsecond absolute accuracy? How much holdover accuracy do you need? These are considerably different probelms. You indicate that you need to provide PTP to a 'cluster.' Is relative accuracy within the cluster all that's important, or do you need to coordinate with the outside? If so, there are a host of other considerations. Too many applications grossly over specify some requirements in the name of safety and miss critical performance needs. More information might let the group a more complete answer. -- 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.
Re: [time-nuts] Time in a cave
Can you use a cell phone as a time source? For instance I see: http://time-server.android.informer.com/ as an android app that is an ntp server. I know this depends on the accuracy of the cell phone network. On Tue, May 12, 2015 at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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. ___ 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.
Re: [time-nuts] Time in a cave
sync to UTC is a secondary concern so long as the cluster agrees with itself. If this is really true then you cancun off the PC's internal clock and set the PC's clock now and then with your wrist watch. OK so maybe you need to track UTC a little more closely. The question is (1) What is your accuracy requirement. Do you need Few tens of milliseconds or do you need nanoseconds. You say you are in a cave but then talk about CDMA. Which is it? What connectivity do you really have? Is this a tall building with a south facing window or a mine shaft. Can you access the Internet? If you can get any Internet connection and need only to be a few tens of mSec from UTC then us a set of NTP pool servers -- Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] Time in a cave
HI Ok, some basics: GNSS = GPS, they are the same thing with the same issues, GNSS lets you hit the Russian system as well as the US. CDMA = your cell phone guy sets the clock. Many people have put *big* dollars into these systems only to find that the local cell phone guy(s) really don’t care what time it is. You can argue about that being right or wrong, we get to buy lots of stuff on eBay because it’s often wrong. Time synch at the user level is a manual (!) setting on the basestation equipment. It’s independent of the CDMA. You would have to check the setup at your local tower to know what they have done. You are also dependent on them not changing that setting as soon as you leave. Good luck getting any real information along those lines. Probably your best bet is an atomic clock of some sort (cheap Rb through Hydrogen maser). The only question is the budget being $200 or $200,000 (or something in-between). Bob On May 12, 2015, at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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. ___ 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.
Re: [time-nuts] Time in a cave
On 5/12/15 4:00 PM, Tucek, Joseph wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. But the entire cluster is interconnected? Or do you need some sort of wireless distribution. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). What about an off the shelf Rb that puts out 1pps or NTP or PTP. SRS (http://www.thinksrs.com/products/fs725.htm) does 1pps MicroSemi (aka Symmetricom,HP,Datum, etc.) has all manner of equipment that has quartz or Rb references and probably any interface you care to name (for a price). If you need sync to outside sources periodically, most of these could be carried to somewhere you have sky visibility to get a GPS 1pps, wait long enough to synchronize it up, then carry it back down and go on holdover. My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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. ___ 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.
Re: [time-nuts] Time in a cave
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.
Re: [time-nuts] Time in a cave
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). Holdover isn't critical (24 hour OK, weekend better, month is overkill) so long as sync within the cluster remains tight. 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? Thanks for the help so far. -Joe ___ 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.
Re: [time-nuts] Time in a cave
In response to Oz-in-DFW Given your description here, I'm guessing a millisecond or ten will do that as long as local cluster relative accuracy is maintained. Spot on; I hope I'd made it clear earlier, but perhaps I've been communicating poorly. My goals w.r.t. to sync to UTC and w.r.t. holdover are very loose. I do need time sync intra-cluster to be tight (sub millisecond, 100 nano as a stretch goal). UTC sync can comparatively be terrible; 10-1 ms is fine, and I can live with bad NTP, 100 ms if I must. From specs, */really/* good quartz is my limit and /good/ quartz is acceptable, so long as it doesn't mess with the intra-node PTP tightness. I'm mostly looking at TCXO options. OCXO isn't out of the question, but rubidium doesn't seem to give $/value. 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. Thanks for the info. PTP isn't as well understood/documented as NTP, so I've not been as certain about my decisions. Of course, that is fair for a relatively new standard. Currently, I think my two best options are: 1) CDMA enabled PTP appliance (set and forget), or 2) PTP appliance running as stratum 2 from good NTP. Thanks to everybody for the feedback. -joe ___ 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.
Re: [time-nuts] Time in a cave
Hi a few questions, Does your cave have any connectivity to the outside world ? Are there any places your cave has connectivity to that might have enough of a sky view to provide periodic gps coverage ? Do you need a COTS (commercial off the shelf) solution or can you accept something that has been kludged together ? Do you need a Peng or other professional to sign off on the solution ? (In my experience PTP may on occasion be found in industrial settings where a Peng may be required to sign off on the solution.) Mark Spencer On 2015-05-12, at 4:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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. ___ 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.
Re: [time-nuts] Time in a cave
Hi Any CDMA device is a *really bad* idea. It’s perfectly legal to run CDMA several seconds out of sync with UTC. There are a number of networks that do exactly this. PTP is fine as long as *all* your network infrastructure (switches / hubs / routers) is PTP enabled. If any of your links are not fully PTP stamping devices you will get into time issues as your network load varies. Bob On May 13, 2015, at 5:44 PM, Tucek, Joseph joseph.tu...@hp.com wrote: In response to Oz-in-DFW Given your description here, I'm guessing a millisecond or ten will do that as long as local cluster relative accuracy is maintained. Spot on; I hope I'd made it clear earlier, but perhaps I've been communicating poorly. My goals w.r.t. to sync to UTC and w.r.t. holdover are very loose. I do need time sync intra-cluster to be tight (sub millisecond, 100 nano as a stretch goal). UTC sync can comparatively be terrible; 10-1 ms is fine, and I can live with bad NTP, 100 ms if I must. From specs, */really/* good quartz is my limit and /good/ quartz is acceptable, so long as it doesn't mess with the intra-node PTP tightness. I'm mostly looking at TCXO options. OCXO isn't out of the question, but rubidium doesn't seem to give $/value. 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. Thanks for the info. PTP isn't as well understood/documented as NTP, so I've not been as certain about my decisions. Of course, that is fair for a relatively new standard. Currently, I think my two best options are: 1) CDMA enabled PTP appliance (set and forget), or 2) PTP appliance running as stratum 2 from good NTP. Thanks to everybody for the feedback. -joe ___ 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. ___ 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.
Re: [time-nuts] Time in a cave
On Tue, May 12, 2015 at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP I believe this was recently discussed on ntp:questions. People often forget dial-up (ACTS) which is supported by the PTP capable Microsemi SyncServer 3NN models which also have OCXO/TCXO/Rb hold-over options. EndRun used to make ACTS capable units as well but I believe the current products are RF only. If your UTC requirements are sufficiently loose you can use VoIP as opposed to a tradition land-line. ___ 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.
Re: [time-nuts] Time in a cave
Tucek, Joseph writes: I do need time sync intra-cluster to be tight (sub millisecond, 100 nano as a stretch goal). UTC sync can comparatively be terrible; 10-1 ms is fine, and I can live with bad NTP, 100 ms if I must. From specs, */really/* good quartz is my limit and /good/ quartz is acceptable, so long as it doesn't mess with the intra-node PTP tightness. I'm mostly looking at TCXO options. OCXO isn't out of the question, but rubidium doesn't seem to give $/value. If you want intra-cluster at sub-millisecond, NTP is possible, and that should be trivial with PTP. I've been attending the ISPCS plugfests for the past few years' time and I've been making sure that we can take time from upstream NTP or PTP, and distribute that time via NTP or PTP. 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. Thanks for the info. PTP isn't as well understood/documented as NTP, so I've not been as certain about my decisions. Of course, that is fair for a relatively new standard. Network Time Foundation includes the NTP Project, Ntimed (and PHK plans to at least look at PTP support sometime), and 2 PTP projects - PTPd, which is designed to be portable and generally useful, and Linux PTP, which is designed to be optimized for the latest Linux kernels. Currently, I think my two best options are: 1) CDMA enabled PTP appliance (set and forget), or 2) PTP appliance running as stratum 2 from good NTP. Either should be fine. I saw you can't run an antenna wire from where you'll be, but perhaps a lan cable? That might go to either a GPS device or to a small NTP or PTP device. NTF is working to improve the products under its umbrella all the time, and we're seriously resource-constrained. OK, we're disturbingly resource-constrained. While the PTPd folks seem to have enough developer resources and Richard Cochran has not complained about the developer resources for Linux PTP, none of the projects have adequate documentation writers. Guess what I think would be a Swell Idea? -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ 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.
Re: [time-nuts] Time in a cave
Paul writes: On Tue, May 12, 2015 at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP I believe this was recently discussed on ntp:questions. People often forget dial-up (ACTS) which is supported by the PTP capable Microsemi SyncServer 3NN models which also have OCXO/TCXO/Rb hold-over options. One problem is that while ACTS used to be a very good way to keep time, now that modems no longer have constant processing time and phone lines are no longer end-to-end copper and the signal likely goes thru a number of domain changes (Audio/Digital, Frame Relay, ATM, ...), I'm told that ACTS is nowhere near as good as it used to be. H ___ 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.
[time-nuts] Time in a cave
I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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.
