Re: Missing CLOCK_BOOTTIME_RAW?

[Pali RohÃr]

On Monday 18 May 2020 13:26:14 Thomas Gleixner wrote:
> Pali RohÃr <pali@xxxxxxxxxx> writes:
> > On Saturday 09 May 2020 11:49:27 Thomas Gleixner wrote:
> >> Sure, but what's the problem? The adjustemt is done to make the observed
> >> time as correct as possible.
> >
> > Yes. But correction may take lot of time, e.g. also more then one day.
> >
> > So during this period when correction is in progress, measuring time
> > difference via CLOCK_MONITONIC will have incorrect results.
> >
> > It already happened for me, system clock was shifted by one hour and
> > chronyd started adjustment, it slow down system clock. 6 real hours
> > passed and via system clock was measured time difference only about
> > 5 hours and 20 minutes (correction was still in progress as system
> > clock at that time was still shifted by about 20 minutes).
> 
> 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?

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.

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.

> Thanks,
> 
>         tglx