Comment 1 for bug 1927799

I've also hit this in a customer environment.

Two problems:

1. On one affected system, /dev/ptp0 was owned by a NIC which was in the NO-CARRIER state, and was over 8000 hours out of sync. When conditions on the system entered a state where the PHC was somehow preferred, the time shot back from October 18th to May 31st. This system has 10 NICs and /dev/ptp0 through /dev/ptp9. It would be better to somehow be able to pick the /dev/ptp device for a specific NIC rather than assuming /dev/ptp0. (This may also lead to another problem: do we need to rewrite the config on restart in case /dev/ptp* devices are enumerated differently, in order to find the one associated with the correct NIC?)

2. Even after correcting the above with a manual tweak to use a "better" PTP, I found that the PTP sources were giving times which were over 500 seconds out of sync with the configured NTP sources. In other words, the PTP time sources, even if connected, were unreliable for accurate time. In this case, we should have the option to disable them - which is the original bug here.

So, summarizing: we should **at least** allow for enable/disable of this functionality, but **also** it would be good to have some way of leaving it enabled but selecting an more appropriate device for the PHC source.