Received-SPF: pass (google.com: domain of linux-kernel+bounces-176237-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: <20240502211047.2240237-1-maheshb@google.com> <87fruspxgt.ffs@tglx>
 <CAF2d9jigGhpSAj2hnUG2QSvYeSzTvD1FUf7tT8BW1NU8EouyOA@mail.gmail.com>
In-Reply-To: <CAF2d9jigGhpSAj2hnUG2QSvYeSzTvD1FUf7tT8BW1NU8EouyOA@mail.gmail.com>
From: Yuliang Li <yuliangli@google.com>
Date: Fri, 10 May 2024 14:27:46 -0700
Message-ID: <CADj8K+M9qjLGAKcsV_9YoPQ5SGXe3vmi69Y65m1RUyLOMrJeHg@mail.gmail.com>
Subject: Re: [PATCHv4 net-next] ptp/ioctl: support MONOTONIC_RAW timestamps
 for PTP_SYS_OFFSET_EXTENDED
To: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= <maheshb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Don Hatchett <hatch@google.com>, 
	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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you Mahesh. Please see my answers below.

The mono_raw allows PHC to correlate with a non-adjusted time. This
enables other types of clock sync algorithms to be developed.
For example, if we want to measure the drift rate between CPU
oscillator and PHC. We could run a linear regression over multiple
pairs of <phc, sys>. But if sys time itself is being adjusted (e.g.,
clock_realtime), the linear regression is running over a polyline
hence less effective. With mono_raw, linear regression truly measures
the drift rate of the CPU oscillator.
This capability allows more types of clock sync algorithms to be developed.

Thanks,
Yuliang


On Wed, May 8, 2024 at 7:54=E2=80=AFPM 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)
<maheshb@google.com> wrote:
>
> On Wed, May 8, 2024 at 12:35=E2=80=AFAM Thomas Gleixner <tglx@linutronix.=
de> wrote:
> >
> > 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.
> >
> Let me add a couple of folks from the clock team. @Yuliang Li  @Don Hatch=
ett
> I'm just a nomad-kernel-net guy trying to fill-in gaps :(
>
> > Thanks,
> >
> >         tglx