Yes, I saw those PTP posts and where the methodology lacks a bit.

Re. asymmetries canceling out, OK, I oversimplified, and this is true in theory and often in practice, but for example, having done this with nearly all generations of enterprise type Broadcom ASICs sort of 2008 onwards I know that there are so many variations to this behaviour that the only way to know is to precisely measure latencies in one direction and the other for a variety of speed, CT vs. S&F and frame sizes, and even bandwidth combinations and see. I used to characterise switches for this, build test harnesses, measurement tools etc., and I saw everything ranging from: CT one way, S&F the other way, but not for all speed combinations, then CT behaviour regardless of enabling or disabling it, finally even things like latency having quantised step characteristics in increments of say X bytes because internally the switching fabric used X-byte cells, and then CT only behaving like CT above certain frame sizes. There's just a lot to take into account. There are even cases where a certain level of background traffic _improves_ latency fairness and symmetry, an equivalent of keeping the caches hot.

The author's best bet at reliable numbers would be to get himself a Latte Panda Mu or another platform with TGPIO and measure against 1PPS straight from the CPU. That would be the ultimate answer. Failing that, at least a PTM NIC synced to the OS clock, but that will alter the noise profile of the OS clock.

But you and me know all this because we've been digging deep into the hardware and software guts of those things for years, and have done this for a job, and what's a home lab user to do. It's a never-ending learning exercise and the key is to acknowledge the possible unknowns, and by that I don't mean scientific unknowns but that we don't know what we don't know, and bloggers sometimes don't do this.

> Steering the same PHC with phc2sys as chronyd is using for HW timestamping is not the best approach as that creates a feedback loop (instability).

This is standard practice, though, for most PTP slave clocks. The feedback is just factored into the math. (Why? No idea. I just know how the code works.)

Although… it's standard practice in PTP setups that are designed for it. Not NTP… if only there were a specification… :)

I do have to wonder though. Of what use are timestamps from an unsynchronized PHC to chrony? Is it continuously taking twin sys+PHC timestamps to line up things?

> I do have to wonder though. Of what use are timestamps from an unsynchronized PHC to chrony? Is it continuously taking twin sys+PHC timestamps to line up things?

That would be the logical way to do it. You want the lowest jitter timestamps you can get on the incoming ethernet frames. If conditions are stable enough you can compute a timebase translation between your MAC local clock and sys clock using the best available method, potentially using many samples over a (relatively) long time frame. And as the GP says, this gives a feed-forward structure without any need for stabilising a feedback loop.

gPTP full-duplex ethernet peer synchronisation uses timestamps from free-running local clocks at each end of the link.

> gPTP full-duplex ethernet peer synchronisation uses timestamps from free-running local clocks at each end of the link.

Do you mean free-running as opposed to VCXO? Most implementations I know indeed use free-running clocks, but there's an increment/rate register in hardware that specifies what value to add to the time counter per crystal tick, which gets updated by the PTP layer — and timestamps use that. So even though the crystal is physically free running, the feedback loop is still there, it just doesn't include the crystal itself.

I know that ethernet MACs typically provide a dynamic mechanism to change the fractional phase increment of the timestamp counter, but it is clear from the gPTP specification that what is referred to as the "Local Clock" at each station is free running with respect to the PTP time base and with respect to connected peers. "Local Clock" is the time used to timestamp packet arrival/transmit times. "PTP Time" (i.e. TAI if we're GPS synchronised) is an independent logical time, separate from Local Time at each station.

It is very clear that there is no feedback loop in 802.1AS (gPTP). I can't speak to other PTP versions. Local clocks (used, among other things for peer delay estimation) are specified to be free running with respect to the PTP time base and to connected peers, not disciplined to PTP Time, asynchronous, not synchronised, not syntonised. The peer delay mechanism equations compensate for both time offset and rate difference in peer local clocks. Furthermore, in order to average estimates over multiple measurements, time offset and rate difference are assumed to be stable (i.e. messing with the rate of a local clock violates invariant assumptions of the peer delay algorithm).

A few more qualifications: I am talking here about non-master peers. I think it might be compliant for the grand master to discipline the local clock to the time source (e.g. GPS PPS), provided it appears stable to connected peers, but it is not at all required by the protocol. Similarly, you might discipline Local Clock to some other stable clock, or to perform temperature compensation. In principle you could synchronise Local Clock to system clock (both free-running with respect to PTP time) so that your packet timestamps are automatically in sys-clock timebase. Once again, there is nothing in the PTP spec that requires this, but the potential utility is clear on a general purpose OS (not necessarily so on an embedded device).

The local clock [in this HW] is synced to PTP, cf. https://ww1.microchip.com/downloads/aemDocuments/documents/O...

There's only one clock in HW, not two. And you really want PTP time in HW for PPS/timestamp IO. (And gPTP uses 1588 HW, there are no special 802.1AS HW implementations that I'm aware of.)

Whether this matches the spec — no idea. My knowledge is from implementations… there could of course be ones that have two clocks. Can you link one?

I have seen enough confusion in hardware specs that I would only trust the IEEE spec.

In gPTP there is one hardware clock, yes. The Local Clock. PTP time is not a hardware clock, it is a virtual clock. The Local Clock is not synchronised to PTP time. Do you have a copy of 802.1AS-2020 there? Here are a few quick quotes resulting from searching for "local clock":

"3.16 local clock: A free-running clock, embedded in a respective entity (e.g., PTP Instance, CSN node), that provides a common time to that entity relative to an arbitrary epoch." (p. 21)

"Each PTP Instance measures, at each PTP Port, the ratio of the frequency of the PTP Instance at the other end of the link attached to that PTP Port to the frequency of its own clock. The cumulative ratio of the Grandmaster Clock frequency to the local clock frequency is accumulated in a standard organizational type, length, value (TLV) attached to the Follow_Up message (or the Sync message if the optional one-step processing is enabled). The frequency ratio of the Grandmaster Clock relative to the local clock is used in computing synchronized time, and the frequency ratio of the neighbor relative to the local clock is used in correcting the propagation time measurement." (p. 44)

"10.1.2.1 LocalClock entity The LocalClock entity is a free-running local clock (see 3.16) that provides a common time to the PTP Instance, relative to an arbitrary epoch. A PTP Instance contains a LocalClock entity. The requirements for the LocalClock entity are specified in B.1. All timestamps are taken relative to the LocalClock entity (see 8.4.3). The LocalClock entity also provides the value of currentTime (see 10.2.4.12), which is used in the state machines to specify the various timers.

NOTE—The epoch for the LocalClock entity can be the time that the PTP Instance is powered on. " (p.66)

Need I continue?

I may be mistaken, but I thought in this sub-thread we were talking about the PTP clock and the system clock (e.g. the x86 tsc). Only one of these is relevant to PTP but the system clock is the only one available to timestamp software events and so you may want to be able to convert between tsc time, NIC local clock time, or PTP time. If you want to schedule GPIO events on the NIC, given a PTP time you can compute the corresponding local clock time, and schedule the event on the GPIO. This does not require disciplining the NIC clock (i.e. the PTP local clock, as defined in my quotes above) to PTP time.