On Sun, Sep 03, 2023 at 11:52:40AM +0700, James Clark wrote: > On Mon, Aug 21, 2023 at 3:28 PM Miroslav Lichvar <mlich...@redhat.com> wrote: > > > As for the PTP-specific timestamping of the CM4 NIC, I'm interested in > > tests using the NTP-over-PTP transport with the latest chrony version > > (you might need to set hwtstimeout to 0.1 or even longer for the CM4). > > I've written a guide to how to set Fedora and chrony on the CM4 so as > to take advantage of both NTP-over-PTP and PHC extpps: > > https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/fedora.md > https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/chrony.md
Thanks for writing that. I don't have a CM4 to verify it. (They still don't seem to be in stock in any of the shops I normally buy from.) There seems to be a copr repo with rpiboot for Fedora, so you could avoid compiling it yourself: https://copr.fedorainfracloud.org/coprs/lsevcik/usbboot/ The latest gpsd version supports SOCK for message-based timing data, which can replace SHM 0. I'd suggest to add "extfield F323" to the client configuration for best performance. > It seems to be working properly: I get no errors and much better > results than with another local chrony server that is not using > hardware timestamping. But how do I tell if the hardware timestamping > is working properly in both directions? On the client, "chronyc ntpdata" should consistently show Hardware for both "TX timestamping" and "RX timestamping". On the server, "chronyc serverstats" should show increasing "NTP hardware RX timestamps" and "NTP hardware TX timestamps". The number of daemon and kernel timestamps should be incrementing only with new/restarted clients and clients not using interleaved mode. > I haven't tried to optimize it yet. The RMS offset on the client seems > to jump around more than I would expect: sometimes around 1us; > sometimes down to a few hundred nanoseconds. Not sure if that is the > switches or the CM4 flakiness or less than optimal configuration. That would indicate software timestamping. With hardware timestamping the offset should be stable to few tens of nanoseconds. > > What would be good tests/measurements to do? Plotting the offset and delay from the measurements log can nicely show how well it performs. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
