1) new hwtimestamp option to synchronize the PHC to system clock
- stability of the PHC will not be best as it is impacted by the
stability of the system clock and PCIe latency
This is what I do today. Run chrony (with HW timestamping) to synchronize system clock. Run exnic-clock-sync (or sys2phc from ptp project) to sync all my PHCs to the system clock. Typically I have multiple PHCs on private networks without NTP or PTP that I want to use for timestamping and I do cross PHC/NIC timestamping so they need to be synchronized.
It would be useful if chrony could sync all PHCs to the system clock taking account to the loop created when using chrony with hwtimestamp.
2) new hwtimestamp option to synchronize the PHC to NTP sources (or
refclocks) available on that interface and synchronize the system
clock to the PHC
- difficult to implement support for the general case where
different sources are on different interfaces (e.g. source
selection/combining is tricky)
This would not work well for source combining, but it should work with source selection. Selected source would synchronize the rest of the clocks in the system.
3) new option to synchronize a PHC instead of the system clock,
replacing it in all time operations
- worse accuracy with sources on interfaces not using the specified
PHC (no kernel timestamping)
- separate chronyd instance (using PHC refclock) is needed for
synchronization of the system clock
This would work well when you have a primary interface / PHC combo with access to the NTP sources. But what about synchronizing the other PHCs in the system to the reference source?
I've been experimenting with 3). I'm attaching a patch (or rather a
quick hack making some shortcuts in the code) if you would like to
test it. There is a -c option to specify a /dev/ptp device. HW
timestamping must be enabled only the interface using that clock.
I will take a look.
In my tests it worked very well. My use case was a super stable server
using a PHC synchronized to PPS signal connected to its input.
I have similar setup but over a WAN (multiple sources over different NICs/PHCs, GPS / PTP not available) and trying to do the best I can.
It seems to me that case 1) would be most generally useful despite the lower accuracy. For most cases of 3) (single grandmaster over LAN) it would be possible to deploy PTP instead.