On Wed, Jan 31, 2024 at 10:48 AM Joseph Beckenbach
<[email protected]> wrote:
>
> We have observed that we are not able to set the realtime clock’s time value below the monotonic clock’s time value in the Linux kernel.
>
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 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’s 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’s time is larger than the slave’s 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.
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 known offset between the “synchronized” time which is 1970 and the “real time” 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.
>
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
On Wed, Jan 31 2024 at 11:12, John Stultz wrote:
> On Wed, Jan 31, 2024 at 10:48 AM Joseph Beckenbach
> <[email protected]> wrote:
>>
>> We have observed that we are not able to set the realtime clock’s
>> time value below the monotonic clock’s 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’s 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’s time is larger than the
>> slave’s 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 “synchronized” time which is 1970 and the
>> “real time” 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