Bruce Simpson, Ph.D.#AppArmor is an odd duck. It is trying to enforce profile rules for UNIX domain sockets based on their protocol field. Which probably bites you if you are a protocol #developer #scientist, or #financial trader, as it impacts production software critical to precision timing (#gpsd, #chronyd, #linuxptp, #ptpd2). This is despite the fact that most uses of #UNIX domain #sockets never even specify a protocol in their system calls to begin with... how bizarre.
P.S. To make matters more confusing, the summary_interval in #linuxptp ptp4l.conf is a log2 value, not a linear interval in units of seconds.
My only real indication of this was the lack of #linuxptp #ptp4l summary logging in #systemd's journalctl -f output, coupled with all the announce and delay timeouts at logging_level > 6; the #ThinkPad was NOT syncing AT ALL.
And it could not, by design, unless these #daemons can be persuaded to
"borrow" the bridge's assigned #IPv4 address on the physical #Ethernet port.
And it could not, by design, unless these #daemons can be persuaded to
"borrow" the bridge's assigned #IPv4 address on the physical #Ethernet port.
I now have a working #IEEE #1588 hardware-corrected #time sync setup using an #Intel #I226V card. No #Arista switch required. FreeBSD #ptpd slave sees #linuxptp master. Yet to test with the #NVidia #Mellanox #ConnectX-4 LX clients in #FreeBSD though. #BeagleBone Black support appears broken. Awaiting a #SiRFStar IV USB #GPS with alleged #PPS capability, and yet to recover my #GPSDO unit from my aunt's attic in Fife.
Scott LairdOkay, this is weird. My one ConnectX-4 system *really* dislikes running #linuxptp.
I'm currently using #Chrony for NTP sync; in *some* cases linuxptp/ptp4l gives better results., but *not* with ConnectX-4 NICs. I'm judging result quality by tracking the RMS offset from `chrony tracking`, as collected by the Prometheus Chrony collector.
As a steady state, my test system sees 25-40ns of RMS offset time. Nice and steady. Chrony is talking to 3 local NTP servers plus some pool servers, with `hwtimestamp *` set but no `refclock` config.
Just starting up `ptp4l` in the background (where it syncs PTP time from the network onto the NIC's PTP Hardware Clock, but *doesn't* touch the system clock) causes chrony's tracking error to jump from ~40ns to ~900ns. Stopping `ptp4l` makes the errors go away immediately.
In this state, there shouldn't be *any* interaction between Chrony and ptp4l at all, but I see a 45x increase in timing error.
Disabling `hwtimestamp *` doesn't help at all. I could see some weird dependency on the PHC when HW timestamps are used, but disabling them doesn't help at all.
This is on Ubuntu 24.04, with Linux 6.8.0-59 and linuxptp 4.0-1ubuntu1. It's using a MCX456A-ECAx NIC (psid MT_2190110032). I originally observed this with FW 12.27.4000; upgrading to the latest FW (12.28.2302) and rebooting showed no change.
I don't see similar problems w/ ConnectX-5.
*In addition to chrony being unhappy*, ptp4l isn't really syncing correctly, either. It's logging RMS errors that look mostly random, between 20 and 50000ns of error, with no real indication of setting down into sync.
For comparison, my pair of Intel X710 systems run with <15ns of RMS error via the same linuxptp build and same switch infra.