Pali Rohár writes:
> On Monday 18 May 2020 14:13:48 Thomas Gleixner wrote:
>> 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 need
On Monday 18 May 2020 14:13:48 Thomas Gleixner wrote:
> Pali Rohár 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 freque
Pali Rohár 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.
>
> An
On Monday 18 May 2020 13:26:14 Thomas Gleixner wrote:
> Pali Rohár 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
Pali Rohár 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 correct
On Saturday 09 May 2020 11:49:27 Thomas Gleixner wrote:
> Pali,
>
> Pali Rohár writes:
> > On Friday 08 May 2020 22:59:57 Thomas Gleixner wrote:
> >> Pali Rohár writes:
> >> Neither CLOCK_BOOTTIME nor CLOCK_MONOTONIC jump. They are frequency
> >> corrected when NTP, PTP or PPS are in use. The fr
Pali,
Pali Rohár writes:
> On Friday 08 May 2020 22:59:57 Thomas Gleixner wrote:
>> Pali Rohár writes:
>> Neither CLOCK_BOOTTIME nor CLOCK_MONOTONIC jump. They are frequency
>> corrected when NTP, PTP or PPS are in use. The frequency correction is
>> incremental an smothed. They really don't jum
P daemon to slow down or speed up system
clock to synchronize it (when system clock is incorrect).
So I thought that this clock is better for time differences as measured
time would not be affected when NTP daemon speeded up system clock via
adjtime().
You wrote that this clock is subject to dr
r and the master clock.
> So for me it looks like that there is missing CLOCK_BOOTTIME_RAW clock
> which would not be affected by NTP jumps (like CLOCK_MONOTONIC_RAW) and
> also would not be affected by system suspend (like CLOCK_BOOTTIME).
>
> Please correct me if I'm wrong in so
TTIME is affected by NTP jumps but provides correct time
difference when system was suspended during measurement.
So for me it looks like that there is missing CLOCK_BOOTTIME_RAW clock
which would not be affected by NTP jumps (like CLOCK_MONOTONIC_RAW) and
also would not be affected by system su
10 matches
Mail list logo
