>> Notice I wrote "sleep". I'm concerned about the suspend+wakeup case,
>> not the case when you're booting up.
>> [ I thought I'd made it abundantly clear. ]
> I'm not a laptop person. I don't know how to fix laptop-specific issues.
FWIW, the offending machine is a desktop.
I `suspend` most of my machines, whether desktops or laptops.
Only servers never sleep.
> 1) You are using a laptop.
It's not the case, but it shouldn't make any difference anyway.
Feel free to assume it's the case.
> 2) Your laptop's hardware clock drifts quite notably.
Right. Tho, AFAICT the same holds (to a lesser extent) of most machines.
> 3) At times, you perform a "sleep" or "suspend" or whatever it's called.
> This period of not-running-but-not-shut-down-either lasts for long
> enough that your clock drift becomes severe.
At least severe enough that I'd like to reduce it.
> 4) Apparently, the system clock does not advance while in this state.
While suspended, the machine's CPU is completely off.
Only the DRAM is still powered.
[ BTW, I suspect the same problem shows up for "suspend to disk" a.k.a
hibernate where the machine might be 100% turned off while sleeping,
but it might go through slightly different routes in the code. ]
> 5) After going from the not-running state to the running state, your
> system clock is reinitialized from the hardware clock. Which is
> not accurate enough for your purposes.
Apparently, yes. I don't actually know how/who reads the RTC to set the
system clock upon wakeup. Maybe `hwclock` is not involved at all, and
maybe part of this happens directly in the kernel.
> 6) After going from the not-running state to the running state, your
> NTP daemon does not perform a clock synchronization soon enough for
> your purposes. User programs have already begun to run. Or continue
> to run? I have absolutely no idea what goes on here.
Yes they just continue running "as if" the machine had never been turned
off (to them, it's mostly as if the scheduler had given priority to
other tasks for a *long* time).
> Now, for some reason, you have become fixated on the /etc/adjtime file,
Not at all. I only mention that file because that's the way this
problem used to be handled during shutdown+reboot back in the SysV-init
days using `/etc/init.d/hwclock.sh`.
> It sounds like whatever least-bad solution you end up using is going to
> depend on which NTP daemon you use, and will involve configuration
> thereof.
Actually, I think The Right Solution™ should be independent from any NTP
daemon, since in order to avoid time warps you'd like to drift-adjust
the RTC time before user-level processes (like the NTP daemon) are
woken up.
> It will not be something generic to adjtime_config(5) or
> hwclock(8) or util-linux. It also won't be something generic to Debian
> systems as a whole, because neither servers nor traditional desktop
> computers have this issue. It's a laptop issue.
Nowadays, there's not much difference between a desktop and a laptop
(they all use the same power-saving tricks, they all support suspending
the system, ...).
The problem does not affect servers, admittedly.
> David has said that chrony can do fancy things involving the hardware
> clock. Maybe you should investigate that solution path.
I'm trying to find out how to fix it Right, rather than how to work
around the problem (I already know how to work around the problem).
Fixing it right requires changing the code that reads the RTC time
upon wakeup. In any case, thank you all for your help.
Apparently none of you have the answer I'm looking for, but you did help
me narrow down the scope and make more precise what I'm after.
Indeed I see now that the time is read from RTC to set system time
directly by the kernel in `kernel/time/timekeeping.c` and
`drivers/rtc/class.c`.
So The Right Solution™ apparently involves changes to the kernel.
Stefan
