[ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

Joe Gwinn joegwinn at comcast.net
Thu Mar 20 00:53:11 UTC 2014


In article <5328AD2B.9 at rubidium.dyndns.org>, Magnus Danielson
<magnus at rubidium.dyndns.org> wrote:

> On 18/03/14 01:24, Joe Gwinn wrote:
> > In article <532778BF.50303 at rubidium.dyndns.org>, Magnus Danielson
> > <magnus at rubidium.dyndns.org> wrote:
> >
> >> On 17/03/14 13:50, Joe Gwinn wrote:
> >>> In article <lg61s4$ong$3 at dont-email.me>, William Unruh
> >>> <unruh at invalid.ca> wrote:
> >>>
> >>>> On 2014-03-16, Joe Gwinn <joegwinn at comcast.net> wrote:
> >>>>> I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
> >>>>> achieve sub-microsecond to nanosecond-level synchronization over
> >>>>> ethernet (with the right hardware to be sure).
> >>>>>
> >>>>> I've been reading IEEE 1588-2008, and they do talk of one nanosecond,
> >>>>> but that's the standard, and aspirational paper is not practical
> >>>>> hardware running in a realistic system.
> >>>>
> >>>> 1ns is silly. However 10s of ns are possible. It is achieved by Radio
> >>>> Astronomy networks with special hardware (but usually post facto)
> >>>
> >>> IEEE 1588-2008 does say one nanosecond, in section 1.1 Scope.
> >>>
> >>> I interpret it as aspirational - one generally makes a hardware
> >>> standard somewhat bigger and better than current practice, so the
> >>> standard won't be too soon outgrown.  IEEE standards time out in five
> >>> years, unless revised or reaffirmed.
> >>>
> >>>
> >>>>> I've seen some papers reporting tens to hundreds of nanoseconds average
> >>>>> sync error, but for datasets that might have 100 points, and even then
> >>>>> there are many outliers.
> >>>>>
> >>>>> I'm getting PTP questions on this from hopeful system designers.  These
> >>>>> systems already run NTP, and achieve millisecond level sync errors.
> >>>>
> >>>> Uh, perhaps show them to achievement of microsecond level sync errors?
> >>>> That is already a factor of 1000 better than they achieve.
> >>>
> >>> I forgot to mention a key point.  We also have IRIG hardware, which
> >>> does provide microsecond level sync errors.  The hope is to eliminate
> >>> the IRIG hardware by using the ethernet network that we must have
> >>> anyway.
> >>
> >> IRIG-B004 DCLS can provide really good performance if you let it.
> >>
> >> To get *good* PTP performance, comparable to your IRIG-B, prepare to do
> >> a lot of testing to find the right Ethernet switches, and then replace
> >> them all. Redoing the IRIG properly start to look like cheap and
> >> straight-forward.
> >
> > I've used IRIG-B004 DCLS before, for cables two meters long within a
> > cabinet.  Worked well.  How well do they handle 100 meter cables, in
> > areas where the concept of "ground" can be elusive?
> 
> The rising edge of the 100 Hz is your time reference, the falling edges 
> is your information. Proper signal conditioning and cabling should not 
> be a problem given proper drivers and receivers.
> 
> IRIG-B004 DCLS also travels nicely over optical connections, and 
> grounding issues will be less of a problem. Known to work well in power 
> sub-stations, so there can be off the shelf products if you look for them.

That's a pretty severe environment.

I should give more context:  On ships at full steam, there can be a
steady seven volts rms or so at power frequency (and harmonics) between
bow and stern, which will cause large currents to flow in the shield. 
This is well below the frequency at which inside and outside shield
currents become decoupled due to skin effect, so the full voltage drop
in the shield may be seen on the center conductor.  

We use optical links a lot, and triax some.

One can also make RF boxes largely immune with a DC-block capacitor in
series with the center conductor.


> > This is for proposed new systems, so there are no switches to replace.
> >
> > In response to questions from hopeful engineers, I had already made the
> > point about the need for serious testing, with asymmetrical loads a
> > factor larger than the real system will sustain.  I'm not sure they are
> > convinced of the need.
> >
> > Anyway, the hope is that PTP will be simpler and cheaper than having
> > multiple IRIG systems, assuming that one starts from scratch.
> 
> Maybe, depends on your needs. Consider doing a separate network for PTP.
> That approach have been used in systems where you want to make sure it 
> works.

That fails economically - might as well stick to IRIG.


> >>>> One of the key problems is getting the packets onto the network (delays
> >>>> withing the ethernet card) special hardware on the cards which
> >>>> timestamps the sending and receiveing of packets on both ends could do
> >>>> better.  But it also depends on the routers and switches between the two
> >>>> systems.
> >>>
> >>> Yes.  My question is basically a query about the current state of the
> >>> art [in PTP].
> >>
> >> The state of the art is not yet standard and not yet off the shelf
> >> products, if you want to call it PTP.
> >
> > This is my fear and instinct.  But people read the adverts and will
> > continue to ask.  And some customers will demand.  So, I'm digging
> > deeper.
> >
> > Are there any good places to start?
> 
> You asked here, it's not the worst place to start. :)

To be sure.  

There is a truism in the standards world, that it take three major
releases (versions) of a standard for it to achieve maturity.  PTP is
at version 2, so one more to go.

Joe Gwinn



More information about the questions mailing list