Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

[Miroslav Lichvar <[e-mail]>]

On Wed, May 26, 2021 at 12:11:31PM -0400, Daniel Franke wrote:
> If a client is going to be exchanging delay messages just as often as
> it receives sync messages, then I don't understand the point of using
> the sync messages at all. The DELAY_RESP message contains a receive
> timestamp, so it contains all the information a client needs for time
> synchronization.

The delay response doesn't have a transmit timestamp and it's not an
event message, i.e. it is not timestamped on the receiving side. In
PTP there are event messages and general messages, exchanged on two
different UDP ports.

I think the reason for that is that PTP originated in time when
hardware timestamping was difficult and expensive, so the protocol
minimizes their rate and tries to distribute them evenly over time.
Even on modern hardware, transmit timestamps can be typically captured
only one at a time, so they need to be limited to the sync messages.

> I thought the whole point of having both
> message types was that delay measurements didn't need to be sent
> nearly this often because delays are expected to be stable over time,
> and that sync messages can be broadcast.

That is a reason but not the only one, I think.

The calculation of the offset in the PTP specification uses only two
timestamps assuming the delay is constant. Implementations can use an
out-of-spec approach similar to NTP using four timestamps
corresponding to the latest sync message and latest delay request, but
the T3-T2 interval is not as tight as in the NTP client/server mode.
It's more like the NTP symmetric mode, but with a random interval.

-- 
Miroslav Lichvar