Message-ID: <20200518124902.yuw2rtmjndi7nbd2@pali>
Date:   Mon, 18 May 2020 14:49:02 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Missing CLOCK_BOOTTIME_RAW?

On Monday 18 May 2020 14:13:48 Thomas Gleixner wrote:
> Pali Rohár <pali@...nel.org> 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.

Problem was that "external source" changed RTC.

But I think this is irrelevant here.

Important was state of machine. Machine was in state that had incorrect
system clock, had running NTP daemon and there was need to somehow make
system clock again correct.

And such situation may happen at any time. Either user unintentionally
change "current time" in his desktop GUI application or call "date"
application with "set" parameter (instead of get), ...

> 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 do not thing it is too bad... When I needed to deal in userspace with
time/date/clock I just needed either "current time in UTC" to show it to
user (possible in different timezone and pretty formatted) or I needed
"timestamp since some epoch" suitable for measuring time differences.

For first case I used CLOCK_REALTIME and for second case I used
CLOCK_MONOTONIC_RAW (as it was not affected by adjtime()).

And I would like to know, it is correct to use these two clocks in those
situations?

> > 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.

Now I see. Usage of external source during suspend would just lead to
another problems. So idea about CLOCK_BOOTTIME_RAW is nice but there is
no way how to provide it.

Anyway, what would happen with CLOCK_BOOTTIME when during suspend is
that external RTC source shifted back? Is kernel guarantee that
CLOCK_BOOTTIME is always monotonic even in this case?

Powered by blists - more mailing lists