Received-SPF: pass (google.com: domain of linux-kernel+bounces-154068-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240418042706.1261473-1-maheshb@google.com> <163538a0495840eca34f6fbd09533ae1@AcuMS.aculab.com>
In-Reply-To: <163538a0495840eca34f6fbd09533ae1@AcuMS.aculab.com>
From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= <maheshb@google.com>
Date: Mon, 22 Apr 2024 15:04:27 -0700
Message-ID: <CAF2d9jj6H+jOfUbbw1ZEHmgqroXmn+oFV8NwTyKJ_P_T4G_5xg@mail.gmail.com>
Subject: Re: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in
 mono-raw base.
To: David Laight <David.Laight@aculab.com>
Cc: Netdev <netdev@vger.kernel.org>, Linux <linux-kernel@vger.kernel.org>, 
	David Miller <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, 
	Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, 
	Thomas Gleixner <tglx@linutronix.de>, Richard Cochran <richardcochran@gmail.com>, 
	Arnd Bergmann <arnd@arndb.de>, Sagi Maimon <maimon.sagi@gmail.com>, Jonathan Corbet <corbet@lwn.net>, 
	John Stultz <jstultz@google.com>, Mahesh Bandewar <mahesh@bandewar.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 21, 2024 at 11:27=E2=80=AFAM David Laight <David.Laight@aculab.=
com> wrote:
>
> 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.
>
Yes, this arbitrary jump in either direction is a problem and hence
the proposed update. However, since it's a UAPI and there could be use
cases that are happy with the current implementation, we can't break
them. Of course the use case that I'm bringing in (and probably what
you have in mind) differs but backward compatibility needs to be
maintained.

> 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.
>
As I understand, the UAPI is to read the PHC and also use the pre/post
timestamps to see the latency of that PHC read as well. CLOCK_REALTIME
is disciplined by NTP and to certain extents CLOCK_MONOTONIC as well
(only freq adjustments are applied). CLOCK_MONOTONIC_RAW is the only
unaffected time-base and hence this proposal / enhancement.

> 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.
Yes, a big step is a high possibility at the beginning (at boot) but
smaller steps as well as ppm adjustments are real possibilities
throughout and hence CLOCK_REALTIME and CLOCK_MONOTONIC are affected.
By adding the timestamps in CLOCK_MONOTONIC_RAW (as proposed in this
patch) should address this issue.

> It really would be nice if those big adjustments didn't affect
> CLOCK_MONATONIC.
> (as an example try sending RTP audio every 20ms)
>
Hmm, probably this is out of context for this patch and probably a
question for the time maintainers / experts?

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