[ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
magnus at rubidium.dyndns.org
Tue Mar 18 20:52:03 UTC 2014
On 18/03/14 09:59, Martin Burnicki 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
>>> 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. ;-)
Indeed. If you read the right article from 1990 you also know you can do
it on L1 C/A only by monitoring both code and carrier phase, as their
ionospheric effect have opposite signs.
Carrier phase by the way is a good illustration that the frequency you
have (1,57542 GHz) is not the limiting factor, as you can make
observations to within 1/100 of the cycle, or about 2 mm. The precision
and accuracy needs *tons* of processing to get in that neighborhood,
especially since the tropospherical delay is hard to estimate and
compensate for in a single receiver.
Anway, resolution and counter frequency is and remains two different
things. Precision measurements can be made using two lower frequency
>> 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
>>>>> 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.
>>>>> 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
>>> 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.
>>> 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).
Indeed. In the old days, you could accurately count your clock cycles in
your assembler and a single common clock for the full machine. No such
More information about the questions