Message ID | 20240911-devel-anna-maria-b4-timers-ptp-ntp-v1-0-2d52f4e13476@linutronix.de (mailing list archive) |
---|---|
Headers | show |
Series | ntp: Rework to prepare support of indenpendent PTP clocks | expand |
On Wed, Sep 11, 2024 at 03:17:36PM +0200, Anna-Maria Behnsen wrote: > This problem can be solved by emulating clock_gettime() via the system > clock source e.g. TSC on x86. Such emulation requires: > > 1. timekeeping mechanism similar to the existing system timekeeping > 2. clock steering equivalent to NTP/adjtimex() I'm trying to understand what independent PTP clocks means here. Is the goal to provide virtual PTP clocks running on top of the system clocksource (e.g. TSC) similarly to what is currently done for physical PTP clocks by writing to /sys/class/ptp/ptp*/n_vclocks, expecting the virtual clocks to be synchronized by applications like phc2sys? Or is this more about speeding up the reading of the PHC, where the kernel itself would be tracking the offset using one of the PTP driver's PTP_SYS_OFFSET operations and emulating a fast-reading PHC?
On Thu, Sep 12, 2024 at 10:12:59AM +0200, Miroslav Lichvar wrote:
> I'm trying to understand what independent PTP clocks means here.
Me, too.
It is not easy to see where this is going...
Thanks,
Richard
Miroslav Lichvar <mlichvar@redhat.com> writes: > On Wed, Sep 11, 2024 at 03:17:36PM +0200, Anna-Maria Behnsen wrote: >> This problem can be solved by emulating clock_gettime() via the system >> clock source e.g. TSC on x86. Such emulation requires: >> >> 1. timekeeping mechanism similar to the existing system timekeeping >> 2. clock steering equivalent to NTP/adjtimex() > > I'm trying to understand what independent PTP clocks means here. Is > the goal to provide virtual PTP clocks running on top of the system > clocksource (e.g. TSC) similarly to what is currently done for > physical PTP clocks by writing to /sys/class/ptp/ptp*/n_vclocks, > expecting the virtual clocks to be synchronized by applications like > phc2sys? > > Or is this more about speeding up the reading of the PHC, where the > kernel itself would be tracking the offset using one of the PTP > driver's PTP_SYS_OFFSET operations and emulating a fast-reading PHC? That's one aspect. The independant PTP clocks are PTP clocks which are not synchronized with CLOCK_TAI. They are "standalone". They are used in automation and automotive setups. They have a grand clock master which is not synchronized to anything. There are also requirements for redundant networks where the clocks are not allowed to be synchronized between the networks to prevent common cause failures. These clocks are used for TSN and both applications and the network stack needs to be able to read the time. Going through the file decriptor based interfaces is slow and not possible in the kernel. The goal is to provide infrastructure which allows these clocks to be read via kernel interfaces and clock_gettime(PTPID) by emulating the clock via the system clocksource (e.g. TSC). That means they need timekeeping and steering infrastructure, to keep them in sync with the PHC. It's the identical mechanism to what system timekeeping and NTP do for the system clocks. So instead of creating duplicate infrastructure, this aims to reuse the existing one. Hope this helps to make it more clear. Thanks, Anna-Maria
The generic clock and timekeeping infrastructure supports only the already defined clocks and as they are not independent there is no need of generalization of data structures. But PTP clocks can be independent from CLOCK_TAI. PTP clocks already have clock_gettime() support via the file descriptor based posix clocks. These interfaces access the PTP hardware and are therefore slow and cannot be used from within the kernel, e.g. TSN networking. This problem can be solved by emulating clock_gettime() via the system clock source e.g. TSC on x86. Such emulation requires: 1. timekeeping mechanism similar to the existing system timekeeping 2. clock steering equivalent to NTP/adjtimex() In the already existing system timekeeping implementation the lock and shadow timekeeper are separate from the timekeeper and sequence counter. Move this information into a new struct type "tk_data" to be able to recycle it for the above explained approach. NTP/adjtimex() related information is all stored in static variables. Move all of them into the new struct type ntp_data to make it reusable. Even without the furture support for independent PTP clocks, the generalization of timekeeping and NTP/adjtimex() improves the structure and readability of the already existing code. Once this is implemented clock_gettime() support for these clocks via vdso can be implement as well but this is an orthogonal task. This queue covers only the generalization of ntp: - Patch 1-6: Basic cleanups - Patch 7-21: Introduction of struct ntp_data and move all static variables to the struct The queue is available here: git://git.kernel.org/pub/scm/linux/kernel/git/anna-maria/linux-devel.git timers/ptp/ntp Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: Miroslav Lichvar <mlichvar@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Christopher S Hall <christopher.s.hall@intel.com> To: John Stultz <jstultz@google.com> To: Frederic Weisbecker <frederic@kernel.org> To: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Thanks, Anna-Maria --- Anna-Maria Behnsen (1): ntp: Cleanup formatting of code Thomas Gleixner (20): ntp: Remove unused tick_nsec ntp: Make tick_usec static ntp: Clean up comments ntp: Convert functions with only two states to bool ntp: Read reference time only once ntp: Introduce struct ntp_data ntp: Move tick_length* into ntp_data ntp: Move tick_stat* into ntp_data ntp: Move time_offset/constant into ntp_data ntp: Move time_max/esterror into ntp_data ntp: Move time_freq/reftime into ntp_data ntp: Move time_adj/ntp_tick_adj into ntp_data ntp: Move ntp_next_leap_sec into ntp_data ntp: Move pps_valid into ntp_data ntp: Move pps_ft into ntp_data ntp: Move pps_jitter into ntp_data ntp: Move pps_fbase into ntp_data ntp: Move pps_shift/intcnt into ntp_data ntp: Move pps_freq/stabil into ntp_data ntp: Move pps monitors into ntp_data arch/x86/include/asm/timer.h | 2 - include/linux/timex.h | 8 - kernel/time/ntp.c | 840 +++++++++++++++++++++---------------------- 3 files changed, 419 insertions(+), 431 deletions(-)