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] [thread-next>] [day] [month] [year] [list]
Date: Wed, 08 May 2024 09:35:46 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Mahesh Bandewar <maheshb@...gle.com>, Netdev <netdev@...r.kernel.org>,
 Linux <linux-kernel@...r.kernel.org>, David Miller <davem@...emloft.net>,
 Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Richard Cochran
 <richardcochran@...il.com>, Arnd Bergmann <arnd@...db.de>, Sagi Maimon
 <maimon.sagi@...il.com>
Cc: Jonathan Corbet <corbet@....net>, John Stultz <jstultz@...gle.com>,
 Mahesh Bandewar <mahesh@...dewar.net>, Mahesh Bandewar
 <maheshb@...gle.com>
Subject: Re: [PATCHv4 net-next] ptp/ioctl: support MONOTONIC_RAW timestamps
 for PTP_SYS_OFFSET_EXTENDED

On Thu, May 02 2024 at 14:10, Mahesh Bandewar wrote:
> The ability to read the PHC (Physical Hardware Clock) alongside
> multiple system clocks is currently dependent on the specific
> hardware architecture. This limitation restricts the use of
> PTP_SYS_OFFSET_PRECISE to certain hardware configurations.
>
> The generic soultion which would work across all architectures
> is to read the PHC along with the latency to perform PHC-read as
> offered by PTP_SYS_OFFSET_EXTENDED which provides pre and post
> timestamps.  However, these timestamps are currently limited
> to the CLOCK_REALTIME timebase. Since CLOCK_REALTIME is affected
> by NTP (or similar time synchronization services), it can
> experience significant jumps forward or backward. This hinders
> the precise latency measurements that PTP_SYS_OFFSET_EXTENDED
> is designed to provide.

This is really a handwavy argument.

Fact is that the time jumps of CLOCK_REALTIME caused by NTP (etc) are
rare and significant enough to be easily filtered out. That's why this
interface allows you to retrieve more than one sample.

Can you please explain which problem you are actually trying to solve?

It can't be PTP system time synchronization as that obviously requires
CLOCK_REALTIME.

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ