lkml.org 
[lkml]   [2020]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Missing CLOCK_BOOTTIME_RAW?
On Monday 18 May 2020 13:26:14 Thomas Gleixner wrote:
> Pali Rohár <pali@kernel.org> 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

\
 
 \ /
  Last update: 2020-05-18 13:35    [W:0.146 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site