Received-SPF: pass (google.com: domain of linux-kernel+bounces-62528-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Thomas Gleixner <tglx@linutronix.de>
To: John Stultz <jstultz@google.com>, Joseph Beckenbach
 <Joseph.Beckenbach@se.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Setting real-time clock below monotonic clock
In-Reply-To: <CANDhNCoh3O=Ds_oLkGer7KKVUW4Zdf_vDdDmyJFVKhDSGU5c-g@mail.gmail.com>
References: <AS4PR04MB9715AECEB559CC8B637D67638A7C2@AS4PR04MB9715.eurprd04.prod.outlook.com>
 <CANDhNCoh3O=Ds_oLkGer7KKVUW4Zdf_vDdDmyJFVKhDSGU5c-g@mail.gmail.com>
Date: Tue, 13 Feb 2024 00:22:38 +0100
Message-ID: <87wmr9i7y9.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 31 2024 at 11:12, John Stultz wrote:
> 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
>> kernel.
>>
>
> Indeed. That behavior was intentional.

It's actually required as a CLOCK_REALTIME value before CLOCK_MONOTONIC
would cause the offset to be negative which would result in a myriad of
issues all over the timekeeping and timer code. Those could be solved
but the price for it would be not worth it as it pretty much slows down
every fast path.

>> 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 value. In this situation, it does not matter what the
>> date is, but we need the time to be synchronized across multiple
>> devices (using generalized Precision 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 master starts its time from
>> January 1, 1970 when it is booted, and when this gPTP master is
>> booted after the gPTP slave, the master=E2=80=99s time is larger 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
>> master, 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.

That's a known issue for quite some time and has been reported
before.

Those systems use a non-standard clock master which itself is not
synchronized to CLOCK_TAI. As the default startup time (if no RTC is
available) is Jan. 1st 1970 this is expected in case that the master
starts after the slaves.

> So I'm not sure it's reasonable to expect the kernel to support that
> case.

I don't think it is.

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

Other than naive assumptions about how timekeeping works, no.

>> Currently, we are planning to use a workaround where we keep track of
>> a known offset between the =E2=80=9Csynchronized=E2=80=9D time which is =
1970 and 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
>> afterwards, we think this will work for now.

What's wrong with having a reasonable synchronized time on the clock
master to begin with?

If a slave starts up before the master then it has to be able to deal
with an initial time jump nd it does absolutely not matter in which
direction this time jump goes, no?

Thanks,

        tglx