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 <[email protected]> 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 -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- - Wojciech Owczarek _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
