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

[Wojciech Owczarek]

(this message is half redundant now since there were some more posts since
I typed it)

On Wednesday, 21 October 2020, Hal Murray <hmurray at megapathdsl.net> wrote:
>
>
> Even if the network is lightly loaded, there can be asymmetry in CPU
> processing delays.


And that is why software timestamps (in a non-realtime OS) are the worst
thing that can happen to synchronisation.


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


That is all only a part of the problem. NTP(/d) can't do anything about the
fact that even once the socket send call is made, the kernel will
essentially send the packet when it feels like it. Nothing can cancel out
the unpredictable latency of software-driven interrupt handling either.
Crypto or anything else in userspace after grabbing a timestamp is a killer
to sync - PTP (2019) is attempting to do crypto via side channels. NTP's
focus from its inception was on sync over the Internet, where the
timestamping uncertainty component was negligible compared to the network
component, and it was a similar case over early LANs. With today's network
hardware this uncertainty can no longer be ignored. Now when I say NTP I
mean the protocol, not it's implementations.

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


Interesting - this is pretty much PTP's two-step mode. The only way to
attempt at grabbing a TX timestamp sensibly in software is by the kernel,
just before it passes the packet to hardware, and long after the
application "sent" it, and Linux supports this. PTP's Follow-Up message is
transmitted as soon as the TX timestamp is grabbed. This extra dead time is
minimal. No way can that timestamp be transmitted in the original packet
itself - that would be like PTP's one-step mode, but only hardware can do
it. FPGA- or otherwise hardware-based NTP servers do this today.



>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>