Received-SPF: pass (google.com: domain of linux-kernel+bounces-154353-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Thomas Gleixner <tglx@linutronix.de>
To: =?utf-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS1?=
 =?utf-8?B?4KS+4KSwKQ==?= <maheshb@google.com>, 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>, 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>
Subject: Re: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally
 in mono-raw base.
In-Reply-To: <CAF2d9jj6H+jOfUbbw1ZEHmgqroXmn+oFV8NwTyKJ_P_T4G_5xg@mail.gmail.com>
References: <20240418042706.1261473-1-maheshb@google.com>
 <163538a0495840eca34f6fbd09533ae1@AcuMS.aculab.com>
 <CAF2d9jj6H+jOfUbbw1ZEHmgqroXmn+oFV8NwTyKJ_P_T4G_5xg@mail.gmail.com>
Date: Tue, 23 Apr 2024 02:24:59 +0200
Message-ID: <87edaxudr8.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 22 2024 at 15:04, Mahesh Bandewar (=E0=A4=AE=E0=A4=B9=E0=A5=87=
=E0=A4=B6 =E0=A4=AC=E0=A4=82=E0=A4=A1=E0=A5=87=E0=A4=B5=E0=A4=BE=E0=A4=B0) =
wrote:
> On Sun, Apr 21, 2024 at 11:27=E2=80=AFAM David Laight <David.Laight@acula=
b.com> wrote:
>>
>> 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.

It depends on what you are trying to do. You cannot adjust
CLOCK_REALTIME/TAI without knowing the current time, right?

So just declaring that this is a big bug and a problem is as wrong as it
gets. It's obviously not the right thing for all use cases, but that
makes the legitimate use cases not wrong.

>> 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)

They don't affect CLOCK_MONATONIC at all because there is no such clock :)

> Hmm, probably this is out of context for this patch and probably a
> question for the time maintainers / experts?

The quantity of the initial frequency adjustments depends on the
accuracy of the initial clock frequency calibration which is on most
sane systems within +/- 500ppm.

     500ppm of 20ms =3D=3D 10us

If the clock calibration is off by a larger margin then that needs to be
fixed.

It's clearly documented that CLOCK_MONOTONIC and CLOCK_REALTIME (and
therefore CLOCK_BOOTTIME and CLOCK_TAI) are strictly based on the same
frequency and only differ by offsets. So there is nothing to fix and
change.

Thanks,

        tglx