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

Martin Burnicki martin.burnicki at meinberg.de
Wed Mar 19 09:16:33 UTC 2014


William Unruh wrote:
> On 2014-03-18, Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>> Magnus Danielson wrote:
>>> On 17/03/14 09:48, Martin Burnicki wrote:
>>>> You'd need hardware (FPGA?) which can be clocked at 1 GHz, and even in
>>>> the hardware signal processing you'd need to account for a number of
>>>> signal propagation delays which you can eventually ignore at lower clock
>>>> rates.
>>>>
>>>> So of course the effort becomes much higher if you want more accuracy,
>>>> but this is always the case, even if you compare NTP to the "time"
>>>> protocol, or PTP to NTP.
>>>
>>> You don't need to count at 1 GHz, you can achieve the resolution with
>>> *much* lower frequencies. One pair of counters I have achieve 2,7 ps
>>> single-shot resolution using 90 MHz clock. Interpolators does the trick.
>>> There is many ways to interpolate.
>>
>> Agreed. I just thought the way to use a higher counter clock is more
>> obvious. All depends on how accurate and precise you can get your
>> timestamps, and this is probably easier with network packet timestampers
>> at both sides of a cable than with a wireless time transfer method like
>> GPS which usually suffers from delays which can't easily be measured,
>> like ionospheric delays. And yes, I know that this can be improved if
>> you receive 2 GPS frequencies instead of only the L1. ;-)
>
> Unless it is a straight wire from one machine to the other, there are
> lots of unconstrained delays by wire as well-- all the switches, etc
> between you and the other end. Much worse than the ionosphere.

True.

However, there are special switches which are PTP-aware, which also do 
timestamping of incoming and outgoing PTP packets. The switch then adds 
the measured propagation delay into the PTP packet sent to the PTP 
slave, so the PTP slave can account for this and compensate the packet 
delay inserted by the switch.

There is also a different approach for switches where the switch acts as 
a PTP boundary clock, but the result is similar in that the switch's 
packet delay is compensated.

So if you are using such switches then from the client's point of view 
it looks like there is a straight direct network cable to the 
grandmaster, at least as far as latencies are concerned.

That's why I wrote in an earlier posting:

"Of course all involved network nodes needed to be able to timestamp at 
this high resolution, otherwise the overall accuracy would be degraded."

Unfortunately there are, as far as I know, no switches which are doing 
the same timestamping for NTP packets.

So if you'd use an NTP server and client which support timestamping of 
NTP packets you get'd the same accuracy as with PTP only if you really 
used a direct network cable. As soon as there is only a single switch 
the resulting accuracy would be degraded.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list