Leveraging PTM

Recently inexpensive mini-servers have become available that support
Precision Time Measurement (PTM) and I'm experimenting with how to
leverage this for chrony. PTM allows the Linux PTP hardware clock to
support cross-timestamping, which allows for the offset between the
NIC clock and the system clock to be calculated with high precision
(lspci shows a granularity of 4ns).

The minimum combination that seems to support PTM is Jasper Lake CPU
and i226-V. i225-V doesn't work (because it's disabled in the kernel),
and less than Jasper Lake (eg. J4125) also doesn't work. There are
reviews of these systems on servethehome.com. I have a couple; the
better one is https://www.aliexpress.com/item/1005005514347844.html,
which is an N6000 CPU (6W TDP) plus 4 x 1226-V ports. The barebones
config is $120.

My experimental setup combines this with a Raspberry Pi CM4 working as
PTP grandmaster. In my case, I have the CM4 connected to the
mini-server via a switch, because I am also experimenting with PTP,
but if you're interested only in NTP, then the ethernet port of the
CM4 could be directly to one of the ports of the mini-server.
Compared to connecting a PPS directly to an i210-T1 (as described in
the last example in the chrony docs
https://chrony-project.org/examples.html#_server_using_reference_clock_on_nic),
the nice aspects of this setup are:

- although there are two boxes involved, they are both small and low
power; systems with a PCIe slot tend to me much bigger (although the
Lenovo tiny desktops can get competitive in size)
- the 40-pin HAT connector on the CM4 IO board makes it easy to
connect a wide variety of GPS receivers (I've documented some here
https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/gps-hw.md)
- there are 3 NICs available on the mini-server, and their NIC clocks
can be synchronized accurately via the system clock using PTM

Although the CM4 works well for syncing the NIC with a GPS receiver,
it has some limitations compared to the mini-server: it is painfully
slow to get the time from the PHC on the CM4; there's only one NIC; it
can only timestamp PTP packets. This setup works around these
limitations.

On the mini-server side, my setup is very basic at the moment:

- there's ptp4l running with its default configuration (UDPv4
transport, and E2E delay)
- I've added a single line to the chrony config: refclock PHC
/dev/ptp1 dpoll 4 offset -37 precision 1e-7

With this setup, chronyc tracking shows:

Reference ID : 50484330 (PHC0)
Stratum : 1
Ref time (UTC) : Thu Aug 17 04:35:49 2023
System time : 0.000000008 seconds slow of NTP time
Last offset : -0.000000005 seconds
RMS offset : 0.000000025 seconds
Frequency : 53.193 ppm slow
Residual freq : +0.000 ppm
Skew : 0.003 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000006092 seconds
Update interval : 16.0 seconds
Leap status : Normal

This isn't quite as good as the results from example config, which
shows an RMS offset of 4ns. I don't understand how it manages to be
this accurate. The docs for the example config say that using the same
NIC clock for PPS input as for timestamping NTP packets "cancels out
any asymmetry between the system clock and hardware clock in the
server’s timestamps of NTP packets". There's something clever going on
here, which I would like to understand better. I am thinking I ought
to add hwtimestamp to my config, but in my case the NIC clock for
timestamping NTP packets will be different from the NIC clock used to
set the system clock.

I am planning to write this up, but, before I do, I would like to get
some feedback about whether this overall approach makes sense and, if
so, how I can refine the configuration, in particular:

- Is hwtimestamp going to help? Is it just a matter of enabling
hardware timestamping on interfaces other than the one connected to
the CM4?
- Is it better to use phc2sys -E ntpshm instead of the PHC refclock?
- How do I figure out optimum polling/update rates? Is it just a
matter of trial and error? Any hints?
- How do I get an accurate error of measurement from "chronyc
sources"? I think this depends on  the precision in the refclock, but
I'm not sure how I make that  accurate.
- Would it be better to use the PTP layer 2 ethernet transport for this?

Hope this is of interest.

James

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]