lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87bk0rj1a1.fsf@somnus>
Date: Fri, 13 Sep 2024 12:28:22 +0200
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Miroslav Lichvar <mlichvar@...hat.com>
Cc: John Stultz <jstultz@...gle.com>, Frederic Weisbecker
 <frederic@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org, Richard Cochran
 <richardcochran@...il.com>, Christopher S Hall
 <christopher.s.hall@...el.com>
Subject: Re: [PATCH 00/21] ntp: Rework to prepare support of indenpendent
 PTP clocks

Miroslav Lichvar <mlichvar@...hat.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ