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

Martin Burnicki martin.burnicki at meinberg.de
Wed Mar 19 09:30:50 UTC 2014


Brian Inglis wrote:
> On 2014-03-18 02:59, Martin Burnicki wrote:
>
>> 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. ;-)
>
> Problem with PTP accuracy is how do you set and discipline your GM?
> With NTP probably.

Or from a GPS receiver.

> NIST site has a paper on TWSTFT stating that some of the delays cancel and
> others can be measured or estimated so that on commercial sat channels they
> can get uncertainties between two stations down to 0.1-1ns, which is better
> than they can get with common view even using L1+L2 freq and P code.
>
> BIPM monthly national TAI/UTC comparisons show uncertainties up to 10-20ns.

The original topic was if it's possible to get nanosecond accuracy over 
a network connection, i.e. from a PTP grandmaster to a PTP client, and 
this is basically a matter of accurate PTP packet timestamping on *all* 
involved network nodes.

Another question is which accuracy relative to UTC you can get into the 
grandmaster, which depends on the basic accuracy of the GPS receiver, 
and how you get this accuracy into your PTP grandmaster (I'm not talking 
about a standard PC getting the time from a GPS receiver via a 1 PPS 
slope triggereing an IRQ with associated latencies).

At the single nanosecond accuracy level it would also be important to 
*which* local realizations UTC(k) you are referring, UTC(NIST), 
UTC(USNO), UTC(PTB), ...


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list