[time-nuts] IEEE 1588 PTP support on raspberry pi 4 compute module

[Magnus Danielson]

Hi Hal,

On 2020-10-21 19:04, Hal Murray wrote:
>> If you have fully symmetric delays, then there is no need for 1588. NTP will
>> do just fine. Unfortunately as even home networking hardware loads up,  ( =
>> lots of traffic in only one direction) this may not be the case. When things
>> *do* go asymmetric, then you *do* need 1588 compatible switches. 
> Even if the network is lightly loaded, there can be asymmetry in CPU 
> processing delays.
>
> In traditional NTP, the transmit time stamp is grabbed as late as possible 
> before sending a packet..  That cancels out if both CPUs are the same speed.  
> Adding authentication (crypto type computations) increases delay from grab to 
> send.  That will increase the offset if the CPUs are not matched.
>
> There is work in progress at the IETF working group on an "interleaved" mode 
> that would send the time stamp from one packet in the next packet.  That adds 
> a delay in getting the data which can't be good but I don't know how bad it 
> is.  I've been thinking that a system could measure that delay and add it to 
> the time stamp.  No code yet.
>
>
If you implement PTP as intended, with hardware time-stamping, you have
released the CPU to a much less significant real-time requirement and
the type of asymmetry you see in NTP is exactly what the core of PTP,
the hardware time-stamping, is aimed to remove as a factor. Now, there
exists NTP implementations with hardware time-stamping, and you can get
similar gain from doing that.

Essentially all home switches and routers have no PTP support. Most
professional equipment doesn't. We only see it in dedicated
environments, and not all of those that should have it does, with margin.

This is not to say that PTP is not sensitive to asymmetries, it is, and
it is clearly stated upfront in the IEEE 1588 standard. It's just that
for you to get good results with PTP, you should only have PTP-capable
hardware that timestamp in and out of it and compensate away any delays
it creates. If you do so, you can get pretty good results.

For NTP the working conditions isn't as benign.

The additional delay of the time-stamp to the following packet is
similar to the PTP 2-step process where the time-stamp is sent in a
separate follow-up packet. It adds some delay to the control-loop, but
considering the loop constant it's not a huge shift, so it does not
significantly affect the dynamics. The round-trip change process is very
slow, so it will be tracked fairly accurate anyway. What remains is
traffic jitter and that will be time-shifted but still annoying.

Anyway, NTP and PTP have somewhat different operational conditions, so
one should be careful in trying to extra-polate too much from one to the
other.

Cheers,
Magnus