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.

--
These are my opinions.  I hate spam.

Hi Hal,

On 2020-10-21 19:04, Hal Murray wrote:

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

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

On Wednesday, 21 October 2020, Hal Murray hmurray@megapathdsl.net wrote:

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

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.

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.