Re: [Ntp] NTP over PTP

[Miroslav Lichvar <[e-mail]>]

On Tue, Jun 29, 2021 at 09:15:22AM +0200, Heiko Gerstung wrote:
> > On Mon, Jun 28, 2021 at 05:02:43PM +0200, Heiko Gerstung wrote:
> >> > The unicast mode seems to be intended for networks with partial
> >> > on-path hardware support, where requirements on accuracy are less
> >> > strict, and I think this might already be better supported by NTP.
> >> They might be less strict but that does not mean they are worse/equal
> >> compared to NTP.
> > 
> > How so?
> Because of the removal of jitter/delay variation in the network stack and OS layer (kernel) of the server and the client. 

That jitter/delay has no impact on PTP or NTP measurements when using
hardware timestamping. Even with software timestamps they can be
eliminated if the timestamp can be captured in the network driver
right before passing the packet to hardware, as most drivers on Linux
can do.

> > You said unicast transparent clocks don't really exist. That would be
> > the only advantage of unicast PTP. Boundary clocks could fully support
> > hardware-timestamped NTP if someone was actually interested in
> > implementing that.
> I was wrong, or better: my knowledge was outdated. Arista for example supports unicast in their switches now.

Ok, I could extend the NTP-over-PTP draft to take advantage of that
if the support is expected to spread.

> > Without full on-path support NTP should generally perform better than
> > PTP as it doesn't assume network has a constant delay.
> Why do you think PTP assumes a constant network delay? PTP is measuring the delay constantly in both directions and calculates the round trip.

Yes, it does, but it is separate from the offset calculation.

The calculation is described in section 11.2 of 1588-2019. It uses
<meanDelay> and there is only the TX and RX timestamp of the sync
message like in the NTP broadcast mode. If the distribution of the
actual delay is not symmetric, as is common without full on-path
support, the average error of the measurements will not even get close
to zero. PTP relies on full hardware support. Without that, it
generally cannot perform as well as NTP.

Another issue with using PTP in network without PTP support is RX
timestamping fixed to the beginning of the message. If the server is
on a 1Gb/s link and the PTP client is on a faster link, there will be
an asymmetry of hundreds of nanoseconds due to the asymmetric delay
in forwarding of messages between different link speeds.

> > In the context of the drafts we are discussing here, I think it might
> > be easier for an existing PTP implementation to add support for
> > NTP+NTS than add NTS4UPTP.
> 
> We are maintaining three different PTP implementations here at Meinberg and I can tell you that this is not true. 

I don't know what implementations are those, but at least for the
well-known open-source implementations I think it would be.

> I did not say that hardware is not timestamping PTP event messages that carry a TLV. I just pointed out that some of the hardware timestampers might look at the length of a packet and do not timestamp anything that is longer then X bytes. A sync message is 44 bytes plus maybe 26 bytes for the AUTENTICATION_TLV.  If you remove the requirement for the AUTHENTICATION_TLV because you want to run NTS over PTP, your PTP "header" is 44 bytes + 48 bytes for the NTP header + anything that NTS adds (Unique Identifier EF, NTS Authentication and Encrypted Extension Fields EF, at least one NTS Cookie EF). It is a bit complicated (for me) to calculate the total maximum size of such an NTS over PTP packet, but I am guessing that you will end up with more than 128 bytes, which might be a limit packet matching algorithms have for quickly identifying if this can be a PTP event message. 

Ok, so it's not about the message having a fixed length, but a maximum
length. That looks like a very odd quirk. Do you have a specific
example of such a hardware?

-- 
Miroslav Lichvar