The connection was lost. Trying to connect again.

Post by ben

Earlier in the thread

Hanno Zulla @hzulla@infosec.exchange

This is FASCINATING. Researchers were able to pin down the cause of measurable global 60 second power spikes to software that does regular checks on the minute mark. They found large scale battery installations as one major cause, but obviously this is true for any other computerized system that does cron jobs and has a synchronized clock. As weird as it sounds, adding random 0-59.999s delays to cron jobs in Linux distributions and other software would actually help the power grid.

fz-juelich.de/en/news/archive/

Mystery of 60-Second Fluctuations in Power Grids Solved Why do our grids show a brief spike in electricity demand every minute? A team led by Dirk Witthaut from Forschungszentrum Jülich has now demonstrated that this is due to regular power checks carried out by large-scale battery storage systems. These findings could help to make our electricity supply more robust, as the team reports in an article published in Nature Energy.

· Public · edited

ben @benjamineskola@hachyderm.io

@hzulla would it actually help? Cron would still wake up at the minute mark in order to sleep again for a few more seconds.

I suppose you’d have two smaller spikes: at the minute, and some seconds later; and the second one would be different for every machine and so average out on a global scale. The first spike would still exist, just smaller, perhaps.

· Public

Replies

Marcus Müller @funkylab@mastodon.social

@benjamineskola @hzulla I think that premise, "cron would wake up on the minute mark" is incorrect: you'd randomize the time it sleeps, in both positive and negative directions Compare how systemd-timers sleep; they already have a well-configurable randomization of wake times, exactly to combat loading a shared resource with a large number is simultaneously triggering machines.

· Public

ben @benjamineskola@hachyderm.io

@funkylab I mean, yeah, if you modified cron to do so. I was assuming that this was adding a random sleep to the start of the cron job itself, which was perhaps a misinterpretation. (I think OpenBSD cron already has this feature, but I’m not sure if it avoids the wake up or only delays the start of the task; and I haven’t seen it in other crons.)

Although of course this might be a premature optimisation, because it hasn’t been shown that there’s a measurable amount of energy being used by cron wakeups in the first place.

@hzulla

· Public · edited

Gabriele Svelto @gabrielesvelto@mas.to

@benjamineskola @funkylab @hzulla maybe I'm off the mark here but cron implementations have always honored the RANDOM_DELAY env variable and it's always been recommended to set it to a non-zero value. IIRC systemd timers also honor it but I don't know if it's set by default or not.

· Public