Messages in this thread | | | Date | Mon, 18 May 2020 13:35:22 +0200 | From | Pali Rohár <> | Subject | Re: 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
| |