Re: [chrony-users] Chrony on CM4

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Sun, Sep 03, 2023 at 11:52:40AM +0700, James Clark wrote:
> On Mon, Aug 21, 2023 at 3:28 PM Miroslav Lichvar <mlichvar@xxxxxxxxxx> 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-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.