I have a machine whose RTC clock is drifting significantly and it is
often suspended for several days. I run NTP so the drift I see when
I wake the machine up gets fixed by "stepping" the clock after a while,
but that can take a while and I'd like to improve this
intermediate situation.
The /etc/adjtime is supposed to be there for such purposes but it seems
to be mostly unused: I assume its "UTC" setting is respected but the
first and second lines indicate it has not been updated since 2015
(i.e. when that Debian install was used in another machine).
I have two questions:
- How can I get Debian to use this file when waking up the machine from
suspend (which would presumably change the file by updating the first
line's "last adjust time")?
- How can I get `ntpd` to adjust the first line's "drift factor" when it
steps the clock?
The second question is less important (I can write the drift factor by
hand, e.g. in case `ntpd` is not being told when the clock is (re)set
based on the RTC, making it impossible for it to compute a drift factor).
I have a machine whose RTC clock is drifting significantly and it is
often suspended for several days. I run NTP so the drift I see when
I wake the machine up gets fixed by "stepping" the clock after a while,
but that can take a while and I'd like to improve this
intermediate situation.
The /etc/adjtime is supposed to be there for such purposes but it seems
to be mostly unused: I assume its "UTC" setting is respected but the
first and second lines indicate it has not been updated since 2015
(i.e. when that Debian install was used in another machine).
I have two questions:
- How can I get Debian to use this file when waking up the machine from
suspend (which would presumably change the file by updating the first
line's "last adjust time")?
- How can I get `ntpd` to adjust the first line's "drift factor" when it
steps the clock?
The second question is less important (I can write the drift factor by
hand, e.g. in case `ntpd` is not being told when the clock is (re)set
based on the RTC, making it impossible for it to compute a drift factor).
Do you really run ntp? You might already be running ntpsec,
its replacement.
The /etc/adjtime is supposed to be there for such purposes but it seemsYou might find your clock drift in /var/lib/ntpsec/ntp.drift
to be mostly unused: I assume its "UTC" setting is respected but the
first and second lines indicate it has not been updated since 2015
(i.e. when that Debian install was used in another machine).
or wherever /etc/ntpsec/ntp.conf specifies it.
I don't know how to speed up correcting the clock as I use chrony,
but ntpsec may have similar directives available.
Oh, indeed, thanks. I had computed it manually from
`journalctl | grep stepped` and it gave close enough results.
The question remains: how to make use of that info upon wakeup to adjust
the "initial" time before NTP takes over.
Indeed, I could try and shorten the time before the NTP info takes
precedence over the RTC-derived initial approximation (I haven't found
any way to tell ntpsec to do that, short of limiting the maximum
interval between pollings or maybe killing&restarting the deamon, both
of which seem too crude for my sense of aesthetics), but I'm more
interested in improving the initial approximation.
The question remains: how to make use of that info upon wakeup to
adjust the "initial" time before NTP takes over.
On Fri, Jun 28, 2024 at 09:48:12 -0400, Stefan Monnier wrote:
Oh, indeed, thanks. I had computed it manually from
`journalctl | grep stepped` and it gave close enough results.
The question remains: how to make use of that info upon wakeup to adjust the "initial" time before NTP takes over.
As I understand it, the drift is used to speed up or slow down the
system clock, so that it more closely tracks real time, and needs
fewer nudges by NTP.
As such, it really has nothing to do with how the system clock is
initialized at boot time (or wake-from-suspend time? I don't do laptops).
At boot time, the system clock is initialized by reading the hardware
clock, with the assumptions that the hardware clock is not very
accurate, but is better than nothing. The system clock will be
adjusted by NTP once the network is up and once the NTP daemon has had
a chance to communicate with its servers and figure out what time it
actually is.
Indeed, I could try and shorten the time before the NTP info takes precedence over the RTC-derived initial approximation (I haven't found
any way to tell ntpsec to do that, short of limiting the maximum
interval between pollings or maybe killing&restarting the deamon, both
of which seem too crude for my sense of aesthetics), but I'm more interested in improving the initial approximation.
I'm failing to understand your thought process here.
The hardware clock has a time, which is loaded into the system clock
to initialize it. That's it. The only variable factor here is whether
the hardware clock's time is in UTC or some local time zone.
You can't do anything with drift at this point, because you don't actually know how long you were asleep. All you know is the current HW clock time. It's not like you can say "Oh, I was asleep for 7.5234 hours, so I need
to adjust the HW clock time forward by X seconds because I know it runs
a bit slow." That information is not available to you.
Stefan writes:
The question remains: how to make use of that info upon wakeup to
adjust the "initial" time before NTP takes over.
hwclock -a can do this.
If you use it be sure ntpsec isn't trying to do
the same thing.
It's not clear to me which NTP (protocol) packages are set up to use
the util-linux stuff, assuming you're not rolling your own
startup/shutdown scripts. (That's the problem in the Subject line, in
a sense.)
The critical part of the whole operation AIUI is not what happens at
startup,
but at shutdown: writing to the RTC, and the correct preservation of
its state.
The hardware clock has a time, which is loaded into the system clock
to initialize it. That's it. The only variable factor here is whether
the hardware clock's time is in UTC or some local time zone.
You can't do anything with drift at this point, because you don't actually know how long you were asleep. All you know is the current HW clock time.
It's not like you can say "Oh, I was asleep for 7.5234 hours, so I need
to adjust the HW clock time forward by X seconds because I know it runs
a bit slow." That information is not available to you.
Stefan writes:
The question remains: how to make use of that info upon wakeup tohwclock -a can do this.
adjust the "initial" time before NTP takes over.
It's not like you can say "Oh, I was asleep for 7.5234 hours, so I need
to adjust the HW clock time forward by X seconds because I know it runs
a bit slow." That information is not available to you.
It is if /etc/adjtime is set properly when you go to sleep.
See `hwclock(8)` or `adjtime_config(5)`.
It is if /etc/adjtime is set properly when you go to sleep.
David writes:
It's not clear to me which NTP (protocol) packages are set up to use
the util-linux stuff, assuming you're not rolling your own
startup/shutdown scripts. (That's the problem in the Subject line, in
a sense.)
Chrony can. I don't know about Ntpsec. But that doesn't get the
adjustment made early enough.
The critical part of the whole operation AIUI is not what happens at startup,
The tricky part, I think, is correcting the rtc before it is used to initialize the system time. Otherwise you'll still have to step or slew
the system time.
but at shutdown: writing to the RTC, and the correct preservation of
its state.
You write to the rtc and to /etc/adjtime periodically at a rate
determined by the computed hot drift rate and also during a controlled shutdown.
Yeah, except... you're assuming a workflow that is not real or reliable.[...]
It is if /etc/adjtime is set properly when you go to sleep.You cannot assume that adjtime was updated the last time your system
stopped running, because your system might have stopped running due to
a crash, instead of a controlled shutdown.
It's not like you can say "Oh, I was asleep for 7.5234 hours, so I need to adjust the HW clock time forward by X seconds because I know it runs
a bit slow." That information is not available to you.
It is if /etc/adjtime is set properly when you go to sleep.
See `hwclock(8)` or `adjtime_config(5)`.
Yeah, except... you're assuming a workflow that is not real or reliable.
hobbit:~$ ls -l /etc/adjtime
-rw-r--r-- 1 root root 44 Mar 6 07:04 /etc/adjtime
hobbit:~$ uptime
14:47:40 up 29 days, 2:54, 29 users, load average: 1.58, 1.07, 1.15
Nothing writes to /etc/adjtime on a regular basis. It's only written
if you manually run an hwclock command, or if you change something
(such as deciding to store your HW clock in UTC instead of local time,
which is what I did on March 6 after learning that Debian had chosen
local time when I installed).
It is if /etc/adjtime is set properly when you go to sleep.
You cannot assume that adjtime was updated the last time your system
stopped running, because your system might have stopped running due to
a crash, instead of a controlled shutdown.
All of the arguments that are being constructed here are bogus.
The *only* thing you know at boot time is what's in the HW clock, and
if you're really lucky, you'll be able to figure out what time zone
it's allegedly set to (after reading /etc/adjtime from disk).
hobbit:~$ cat /etc/adjtime
0.000000 1708191089 0.000000
1708191089
UTC
hobbit:~$ date -d @1708191089
Sat Feb 17 12:31:29 EST 2024
With chrony, you can monitor the RTC over time and adjust the system
clock in accordance with its drift rate at boot time, without
correcting the RTC itself, or you can actually set the RTC from the
system clock periodically.
The particular problem at shutdown is that there were/are systems, as
you described, that write the system time to the RTC without
necessarily regarding how you might be running the clock otherwise.
That alteration is unknowable for chrony when it restarts after
booting.
On Fri 28 Jun 2024 at 14:54:42 (-0400), Greg Wooledge wrote:
The *only* thing you know at boot time is what's in the HW clock, and
if you're really lucky, you'll be able to figure out what time zone
it's allegedly set to (after reading /etc/adjtime from disk).
hobbit:~$ cat /etc/adjtime
0.000000 1708191089 0.000000
1708191089
UTC
hobbit:~$ date -d @1708191089
Sat Feb 17 12:31:29 EST 2024
I don't think you've mentioned which package(s) you're using to
control your system clock.
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. ]
Notice I wrote "sleep". I'm concerned about the suspend+wakeup case,I'm not a laptop person. I don't know how to fix laptop-specific issues.
not the case when you're booting up.
[ I thought I'd made it abundantly clear. ]
1) You are using a laptop.
2) Your laptop's hardware clock drifts quite notably.
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.
4) Apparently, the system clock does not advance while in this state.
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.
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.
Now, for some reason, you have become fixated on the /etc/adjtime file,
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.
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.
David has said that chrony can do fancy things involving the hardware
clock. Maybe you should investigate that solution path.
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.
I have a machine whose RTC clock is drifting significantly and it is
often suspended for several days. I run NTP so the drift I see when
I wake the machine up gets fixed by "stepping" the clock after a
while, but that can take a while and I'd like to improve this
intermediate situation.
On Fri 28 Jun 2024 at 11:14:34 (-0500), John Hasler wrote:
David writes:
It's not clear to me which NTP (protocol) packages are set up to use
the util-linux stuff, assuming you're not rolling your own startup/shutdown scripts. (That's the problem in the Subject line, in
a sense.)
Chrony can. I don't know about Ntpsec. But that doesn't get the adjustment made early enough.
By "use the util-linux stuff" I meant use /sbin/hwclock. Neither
chrony nor ntpsec can use hwclock by default as they don't list
util-linux as a dependency. They use their own binaries. IDK whether
you can deliberately configure them to use hwclock instead, or why
any one would do so.
* Invest in a decent GPS receiver, and install chrony and gpsd on
the machine. Doing so may get the system clock in synch faster; it
may not. Doing that sort of thing is well documented on the gpsd
home page.
Wouldn't you need to know how fast the laptop is travelling?
On Fri, Jun 28, 2024 at 02:05:48PM -0500, David Wright wrote:
On Fri 28 Jun 2024 at 11:14:34 (-0500), John Hasler wrote:
David writes:
It's not clear to me which NTP (protocol) packages are set up to use the util-linux stuff, assuming you're not rolling your own startup/shutdown scripts. (That's the problem in the Subject line, in
a sense.)
Chrony can. I don't know about Ntpsec. But that doesn't get the adjustment made early enough.
By "use the util-linux stuff" I meant use /sbin/hwclock. Neither
chrony nor ntpsec can use hwclock by default as they don't list
util-linux as a dependency. They use their own binaries. IDK whether
you can deliberately configure them to use hwclock instead, or why
any one would do so.
Still they can set (and AFAIK discipline) the "hardware clock", via the
Linux kernel -- if things are set up this way. See the notes on the Linux kernel's "11 minute mode" in the hwclock(8) man page.
David writes:
With chrony, you can monitor the RTC over time and adjust the system
clock in accordance with its drift rate at boot time, without
correcting the RTC itself, or you can actually set the RTC from the
system clock periodically.
That leads to the probelem that started this thread: system time being
set incorrectly at boot and then stepped later.
The particular problem at shutdown is that there were/are systems, as
you described, that write the system time to the RTC without
necessarily regarding how you might be running the clock otherwise.
That alteration is unknowable for chrony when it restarts after
booting.
Obviously you must make sure that only one process ever writes to the
RTC.
Actually you need never write to the RTC at all: just track its offset
and drift rate. That would require hacking the boot process to make
sure only your code ever reads it, though.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 168:54:42 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,823 |