Re: Missing CLOCK_BOOTTIME_RAW?

[Thomas Gleixner]

Pali RohÃr <pali@xxxxxxxxxx> writes:
> On Monday 18 May 2020 13:26:14 Thomas Gleixner wrote:
>> System clock shifted by one hour? You mean DST change?
>
> Yes, clock was shifted by one hour.
>
>> If chronyd
>> adjusts that by smoothing the frequency, that's just broken and really
>> not the kernel's problem.
>
> And what other can time synchronization daemon does?

DST switching is a matter of switching time zones and has absolutely
nothing to do with frequencies. In fact smearing DST is a blantant
violation of the timekeeping guarantees.

I've never heard about that before. All I know is that chronyd can be
configured to smear leap seconds, but that doesn't take 6 hours and does
not screw with the time accuracy in the range of 20 minutes.

> Well, I think this is not related to chronyd. Any userspace application
> may call adjtime(). It is not privilege that only chronyd is allowed to
> use that syscall.

Of course not, but the kernel relies on that application behaving
sanely. If it does not then the time stamps you are complaining about
are the least of your worries.

> I agree that this is not a kernel problem.
>
> But I'm asking, how my userspace application can measure time difference?
> As I wrote CLOCK_MONITONIC is not suitable as it is affected by those
> NTP adjustments and that is why I thought that CLOCK_MONITONIC_RAW is
> better as it is not affected by these NTP problems.
>
> But CLOCK_MONITONIC_RAW has a problem that is stopped during system
> sleep and that is why I thought that CLOCK_BOOTTIME_RAW should be there.

And how do you make CLOCK_BOOTTIME_RAW accurate? The clock hardware
can stop accross suspend/resume and the kernel then uses RTC or some
other hardware to inject the sleep time. That injection is not and
cannot be correct vs. the raw clock.

So exposing CLOCK_BOOTTIME_RAW would just provide yet another illusion
of time.

Thanks,

        tglx