linux-kernel - RE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in mono-raw base.

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: Sun, 21 Apr 2024 18:27:01 +0000
From: David Laight <David.Laight@...LAB.COM>
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>, Thomas Gleixner <tglx@...utronix.de>, "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>
Subject: RE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in
 mono-raw base.

From: Mahesh Bandewar
> Sent: 18 April 2024 05:27
> 
> The current implementation of PTP_SYS_OFFSET_EXTENDED provides
> PHC reads in the form of [pre-TS, PHC, post-TS]. These pre and
> post timestamps are useful to measure the width of the PHC read.
> However, the current implementation provides these timestamps in
> CLOCK_REALTIME only. Since CLOCK_REALTIME is disciplined by NTP
> or NTP-like service(s), the value is subjected to change. This
> makes some applications that are very sensitive to time change
> have these timestamps delivered in different time-base.
...

Isn't using CLOCK_REALTIME just a big bug?
As well as minor 'corrections' done by NTP it suffers from
major time-warps that can jump in either direction by arbitrary amounts.

If I understand the intent of the UAPI, a possibly solution is
to get the offset between CLOCK_REALTIME and CLOCK_MONATONIC and
ensure the same offset is added CLOCK_MONATONIC for the pre- and
post- timestamps.

This doesn't solve the problem of the NTP adjusted clock always
running slightly slow or fast.
The big NTP errors happen in the first (IIRC up to ~20 mins after boot)
when the system clock is being synchronised.
It really would be nice if those big adjustments didn't affect
CLOCK_MONATONIC.
(as an example try sending RTP audio every 20ms)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)