[systemd-devel] [EXT] Re: Re: Re: Understanding the effect of AccuracySec=

[Windl, Ulrich]

Thanks Lennart,

Actually I have a physical "power meter", and I played with my laptop a bit:
In Windows 11 it consumes about 19W when idle, for Linux about 29W, but when it is doing a "little bit", then the power jumps up to 160W or so (Intel speed step technology).
The CPU is probably "power-capped", because when all the 32 logical CPUs go full speed there would be a "core meltdown", I guess. 😉
So the pattern is not as simple as "power" vs. "idle power", but there are multiple power steps actually.
But that would be a different thread...

Regards,
Ulrich

> -----Original Message-----
> From: Lennart Poettering <lennart at poettering.net>
> Sent: Monday, August 19, 2024 3:01 PM
> To: Windl, Ulrich <u.windl at ukr.de>
> Cc: Adrian Vovk <adrianvovk at gmail.com>; Andrei Borzenkov
> <arvidjaar at gmail.com>; Barry <barry at barrys-emacs.org>; Systemd Devel
> <systemd-devel at lists.freedesktop.org>
> Subject: [EXT] Re: [systemd-devel] Re: Re: Understanding the effect of
> AccuracySec=
> 
> On Mo, 19.08.24 12:15, Windl, Ulrich (u.windl at ukr.de) wrote:
> 
> > Thanks to everyone sharing information. Basically that’s what I
> > expected, too, except this:
> >
> > I run about 10 instances of the timer, and all 10 instances are
> > started at the same second. My initial expectation wad that systemd
> > might spread the instances in the 6 hour windows somehow.
> 
> That's what RandomizedDelaySec= is about. It's a difference concept.
> 
> https://www.freedesktop.org/software/systemd/man/latest/systemd.time
> r.html#RandomizedDelaySec=
> 
> > Maybe starting the next instance once the previous instance had finished.
> > I’m somewhat unsure about the energy saving: Will 10 jobs run
> > simultaneously consume less power than the 10 jobs run sequentially?
> > My guess is that the timer overhead may be negligible.
> 
> Yes, typically it should be more energy efficient to keep a system
> idle most of the time, and then pack everything it needs to do into a
> brief "spark" of work. Different jobs tend to require resources
> differently (i.e. some job might wait for CPU, another for disk IO,
> another for network IO and so on), hence if you run them altogether
> you maximize the chance to keep your hw busy, and thus removing the
> need to power on/power off it continiously. After all, powering
> on/powering off (i.e. getting from lower to higher power levels and
> back) is time intensive, and wastes resources.
> 
> of course, there are differences in hardware, and we only implement a
> very generic system here, but by reducing the amount of wakeups we
> should generally optimize energy behaviour.
> 
> Tools such as powertop for example help you analyzing this, they show
> you which parts of the OS cause which wakeups, and help you reducing
> them to optimize energy use/battery lifetime. We are just doing our
> part in not making things worse for that.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin