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@xxxxxxxxxxxxxx> > Sent: Monday, August 19, 2024 3:01 PM > To: Windl, Ulrich <u.windl@xxxxxx> > Cc: Adrian Vovk <adrianvovk@xxxxxxxxx>; Andrei Borzenkov > <arvidjaar@xxxxxxxxx>; Barry <barry@xxxxxxxxxxxxxxxx>; Systemd Devel > <systemd-devel@xxxxxxxxxxxxxxxxxxxxx> > Subject: [EXT] Re: Re: Re: Understanding the effect of > AccuracySec= > > On Mo, 19.08.24 12:15, Windl, Ulrich (u.windl@xxxxxx) 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