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

Martin Burnicki martin.burnicki at meinberg.de
Tue Mar 18 08:59:01 UTC 2014


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. ;-)

> Achieving the necessary resolution then turns into the troublesome issue
> of precision, which require calibrations and systematic studies.
>
>>>> 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.
>>>
>>> One of the key problems is getting the packets onto the network (delays
>>> withing the ethernet card) special hardware on teh cards which
>>> timestamps the sending and receiveing of packets on both ends could do
>>> better.a But it also depends on the routers and switches between the two
>>> systems.
>>
>> Of course all involved network nodes needed to be able to timestamp at
>> this high resolution, otherwise the overall accuracy would be degraded.
>>
>> And, it would probably be easier to achieve this accuracy with an
>> embedded device with dedicated hardware than with a a standard PC and a
>> NIC connected via the PCI bus.
>
> There is a whole myriad of issues you end up with when you try to get
> down that low.

Yep.

>> If there were a 1 GHz oscillator on the NIC used for timestamping then
>> you still have to provide a way to relate the timestamps from the NIC to
>> your local system time. If the only way to do this is via the (PCI?) bus
>> then the accuracy could suffer from bus latency, arbitration, etc.
>
> No go.
>
>> On a dedicated hardware the same oscillator/high resolution counter
>> chain could be used for system timekeeping, and to timestamp network
>> packets, which makes things much easier.
>
> You end up with quite dedicated hardware if you want to go there, yes.
> Regardless of how you do it.

Standard PC hardware hasn't been designed for timekeeping at highest 
accuracy, neither the cheap crystal oscillator usually assembled on the 
mainboard, nor the missing "hard link" between hardware on a PCI card 
and the CPU, nor the TSCs often used for timekeeping which may suffer 
from changes of the CPU clock frequency (with older CPU types) or 
changes of the front bus clock frequency (with newer CPU types).

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list