6 ms·

I agree with most of what you said. The author has other posts in the series where he tried to measure the accuracy relative to the PHC (not system clock) usin

• wowczarek 1y ago
  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.
• eqvinox 1y ago
  > 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?
  • RossBencina 1y ago
    > 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.
    • eqvinox 1y ago
      > 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.
      • RossBencina 1y ago
        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).