[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <163538a0495840eca34f6fbd09533ae1@AcuMS.aculab.com>
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)
Powered by blists - more mailing lists