Received-SPF: pass (google.com: domain of linux-kernel+bounces-47004-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <AS4PR04MB9715AECEB559CC8B637D67638A7C2@AS4PR04MB9715.eurprd04.prod.outlook.com>
In-Reply-To: <AS4PR04MB9715AECEB559CC8B637D67638A7C2@AS4PR04MB9715.eurprd04.prod.outlook.com>
From: John Stultz <jstultz@google.com>
Date: Wed, 31 Jan 2024 11:12:34 -0800
Message-ID: <CANDhNCoh3O=Ds_oLkGer7KKVUW4Zdf_vDdDmyJFVKhDSGU5c-g@mail.gmail.com>
Subject: Re: Setting real-time clock below monotonic clock
To: Joseph Beckenbach <Joseph.Beckenbach@se.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 31, 2024 at 10:48=E2=80=AFAM Joseph Beckenbach
<Joseph.Beckenbach@se.com> wrote:
>
> We have observed that we are not able to set the realtime clock=E2=80=99s=
 time value below the monotonic clock=E2=80=99s time value in the Linux ker=
nel.
>

Indeed. That behavior was intentional.

>
> We have a situation where we will try to set the realtime clock time to a=
 very low value (close to January 1, 1970) and below the monotonic clock va=
lue. In this situation, it does not matter what the date is, but we need th=
e time to be synchronized across multiple devices (using generalized Precis=
ion Time Protocol or gPTP) for our application. It=E2=80=99s possible this =
synchronized time might be a low value (close to 1970) because the gPTP mas=
ter starts its time from January 1, 1970 when it is booted, and when this g=
PTP master is booted after the gPTP slave, the master=E2=80=99s time is lar=
ger than the slave=E2=80=99s monotonic clock (which also starts from 0 when=
 it is booted). When the slave tries to adjust its clock to match the maste=
r, we get an error.
>

I appreciate there may be many constraints here, but it feels like the
device you're trying to sync to, reporting its time as close to Jan 1
1970 is misconfigured.
So I'm not sure it's reasonable to expect the kernel to support that case.

Is there some different perspective I'm missing, though?

>
> Currently, we are planning to use a workaround where we keep track of a k=
nown offset between the =E2=80=9Csynchronized=E2=80=9D time which is 1970 a=
nd the =E2=80=9Creal time=E2=80=9D such as 2024. Since the time only jumps =
once at the beginning of sync and should not change by more than a second a=
fterwards, we think this will work for now.
>

It seems if the device you're syncing to would start its configured
time from date even slightly closer to now (start with 1980!), it
would also avoid the problem?

>
> We currently do not want to spend time pushing for a change in the Linux =
kernel. But I wanted to at least report this use case we have and the issue=
 we are having because of this behavior in the Linux kernel.
>

I'm sorry I don't have a better response for you here, but I
appreciate you sending out the mail. It's nice to have more folks
working on time/time sync interacting on the list.

thanks
-john