[lkml]   [2021]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Time keeping while suspended in the presence of persistent clock drift
On 14/12/2021 14:57:45+0100, Thomas Gleixner wrote:
> Joel,
> On Mon, Dec 13 2021 at 06:39, Joel Daniels wrote:
> > On Sat, 11 Dec 2021 14:36 +0100, Thomas Gleixner wrote:
> >> Can you please verify that the problem persists with NTP enabled and
> >> synchronized?
> >
> > Yes, I just verified that the problem still exists while
> > synchronized to NTP.
> ...
> > $ chronyc tracking && echo && chronyc sources
> > [...]
> > Ref time (UTC) : Mon Dec 13 13:30:52 2021
> > System time : 5.597892284 seconds fast of NTP time
> thanks for making sure that this is really a RTC issue on that machine.
> > The "if" branch does not apply as I have no clock sources flagged as
> > CLOCK_SOURCE_SUSPEND_NONSTOP but the "else if" branch does apply.
> Which CPU is in that box?
> > The kernel seems to believe that the time spent sleeping is exactly
> > the difference of two calls to read_persistent_clock64 with no option
> > to adjust for persistent clock drift.
> The kernel does not believe. It relies on the accuracy of the CMOS clock
> which is usually pretty good.
> > I would like to provide a way for user space to inform the kernel
> > that the persistent clock drifts so it can make a corresponding
> > adjustment when resuming from a long suspend period.
> >
> > In my use case it would be enough for me to set this parameter on
> > boot. In use cases with continuous network access, NTP daemons
> > could be enhanced to periodically update this parameter with the
> > daemon's best estimate of the persistent clock drift.
> That needs some thought. The RTC people (cc'ed now) might have opionions
> on that.

The RTC subsystem already has two interfaces to correct the drift of an
RTC. However, this is currently limited to RTC that have hardware
support for this feature. I guess we could had software emulation of the
feature to be able to correct for any RTCs but this will raise many
design questions, like how often the correction has to happen, what to
do with RTC that have a counter that doesn't reset when setting their
time, etc...

I guess this would be able to solve your particular issue has you will
need a mechanism to handle when you overshoot the regular correction

However, everything falls down once the machine is turned off, making
the whole effort moot...

Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering

 \ /
  Last update: 2021-12-15 22:43    [W:0.069 / U:1.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site