On Fri 28 Jun 2024 at 15:05:34 (-0500), John Hasler wrote:
> 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 cl
On Sat 29 Jun 2024 at 06:53:48 (+0200), to...@tuxteam.de wrote:
> 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
On Sat, 29 Jun 2024 16:39:14 +0100
"mick.crane" wrote:
> > * 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 y
On 2024-06-29 04:52, Charles Curley wrote:
On Thu, 27 Jun 2024 12:48:03 -0400
Stefan Monnier wrote:
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
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/shut
On Thu, 27 Jun 2024 12:48:03 -0400
Stefan Monnier wrote:
> 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 wh
On 29/06/2024 01:49, Stefan Monnier wrote:
But note that when we wake up ntpsec is already running
It should be possible to stop the NTP daemon on suspend (or hibernate)
and start it on resume.
I think, what you are truing to achieve is doable. I do not agree with
Greg. The question is what
On Fri 28 Jun 2024 at 17:03:47 (-0400), Stefan Monnier wrote:
> > 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 alre
>> 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
On Fri, Jun 28, 2024 at 14:44:03 -0500, David Wright wrote:
> 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 (aft
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 threa
> 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,
On Fri 28 Jun 2024 at 14:54:42 (-0400), Greg Wooledge wrote:
> > > 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 /e
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.)
> > 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
John Hasler [2024-06-28 09:41:06] wrote:
> 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.
Indeed, and my question can be thought of as asking how to run
`hwclock -a` when we wake up (
> 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 l
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
ad
On Fri 28 Jun 2024 at 09:41:06 (-0500), John Hasler wrote:
> 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.
Sure it can.
> If you use it be sure ntpsec isn't trying to do
> the
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.
--
John Hasler
j...@sugarbit.com
Elmwood, WI USA
On Fri 28 Jun 2024 at 10:06:23 (-0400), Greg Wooledge wrote:
> 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 i
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.
> Do you really run ntp? You might already be running ntpsec,
> its replacement.
I call it ntp but yes, it's ntpsec.
>> 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 indica
> I think hwclock(8) has the info you need. On my system (yes, one of
> those) there is an /etc/init.d/hwclock.sh which seems to take care
> of that. No idea how the young'uns do it, though :-)
AFAICT this `hwclock.sh` (which I do have) is not used (I'm using
systemd) and even less so upon suspend
On Thu 27 Jun 2024 at 12:48:03 (-0400), Stefan Monnier wrote:
> 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
On Thu, Jun 27, 2024 at 12:48:03PM -0400, Stefan Monnier wrote:
> 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
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/
27 matches
Mail list logo
