On Mon, Nov 28, 2022 at 03:39:32PM -0500, Aaron Ball wrote: > On some new time servers, we're using an Intel E810 NIC with two ports that > share a single clock, with PTP coming from a GPS appliance on one interface > and hardware-timestamped NTP being served on the other. Are there any risks > we should be aware of around the shared clock in this application? (All our > existing time servers have a unique clock per interface.)
Stability of the PHC synchronized by PTP will impact stability of chrony's tracking of the PHC. If this is the main time source that chrony will use/serve, it shouldn't matter much. Ideally, you would use a virtual clock for PTP in order to let the physical clock run free. This is supported since Linux 5.14 and in the latest code of linuxptp (with a pending bug fix posted on -devel). You can create a vclock with echo 1 > /sys/class/ptp/ptp0/n_vclocks and then start: ptp4l -i eth0 --phc_index $VCLOCK_PHC to use the vclock instead of the physical clock, which can be used by chronyd. However, the ice driver (used for E810) currently doesn't work well with vclocks due to a locking issue. There are frequent "BUG: scheduling while atomic" errors reported. It was reported on the wired-lan list and it might be fixed with some planned changes soon. There is also an issue with large delays in getting of the TX timestamp on the E810. It sometimes takes tens of milliseconds for the timestamp to be available, which causes frequent fallbacks to software timestamping. Not an ideal HW for NTP, at least with the current driver/firmware. -- 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.
