[time-nuts] Time in a cave

Wojciech Owczarek wojciech at owczarek.co.uk
Fri May 15 08:34:33 UTC 2015


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.tucek at 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 at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 
-

Wojciech Owczarek



More information about the Time-nuts_lists.febo.com mailing list