This is FASCINATING.
-
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.
@hzulla if only there would be something Like anacron.
-
Uhh...
I certainly do. For the longest time I wondered what would happen if one deployed a malware that
- synchronized clocks by NTP
- shut down all affected systems at precisely the same time on the evening (so that power plants are ramped down quicker)
- and at the time where normally the evening dip would turn upward suddenly turn on all those systems again (ACPI RTC wakeup) and launched some really CPU & GPU heavy load.@datenwolf @hzulla Such an attack is more feasible with a relatively small number of devices if you attack the links between larger electricity networks.
Here's an article from 2017 (German only)
https://www.heise.de/news/Botnetze-koennen-das-Stromnetz-sabotieren-3927886.html?seite=all -
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.
@hzulla When smartphones were relatively new, they would regularly cause issues on mobile networks, because they all checked for new email or other OOT messages at the same time. IIRC it wasn't event the data volume, it was the synchronized messaging traffic to open Mobile data connections.
I understand that issue has been fixed.
-
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.
@hzulla @maxleibman years ago it was recommended to me that a cron jobs schedule should be set to a prime number so that its distribution would be semi random throughout the day, avoids spikes.
I still follow that advice whenever I setup new jobs.
-
@hzulla I don't understand. How does simultaneous power checks dip the frequency (in original paper)? Like I understand that at every minute mark there is some job running, but shouldn't the computation/ power usage be cheap for this?
@closeted_unionist @hzulla If you add significant load to a large electricity grid, the frequency falls, (until the power plant ramps up).
-
@mattblaze @hzulla Even way back when, I generally offset my cron jobs by a few minutes, just to avoid CPU and RAM (“core storage”) conflicts with other cron jobs.
@SteveBellovin @mattblaze @hzulla In the late 1990s I worked at a place that had a hundred or so systems all using the same file server. We used a simple wrapper for cron jobs run by all systems to smear out the impact: extract low octet of IP address, sleep that many seconds before starting.
Nowadays I manage about 300 systems, but net and CPU and storage are fast enough that we don't get crowd-load effects. If we did I'd repeat the scheme but sleep N/10 or N/100 seconds.
There's something to be said for changing cron to insert small random delays. I don't think it often (if ever) matters if a job starts a fraction of a second, or even a few seconds, after the exact start of the minute.
-
It is such an obvious cause once you think about it, and yet before you hear about this, no software developer or maintainer ever considers the possible effects of e.g. a default Debian cron job setting on the global electricity grid.
@hzulla since I saw the effects of a "thundering herd", where ten thousands of nodes in a large SaltStack-driven infrastructure all acted at the very same millisecond gave us major headaches, I will always think twice before scheduling anything.
Luckily, many schedulers allow now for mitigating those kind of issues by defining some randomness for distributing the load across a defined timespan. -
It is such an obvious cause once you think about it, and yet before you hear about this, no software developer or maintainer ever considers the possible effects of e.g. a default Debian cron job setting on the global electricity grid.
@hzulla more for constraints on local compute capacity than the global power grid, but I can't be the only sysadmin who routinely staggers recurring jobs likely updates or backups to kick off at semi-random times like 02:17, 03:43, etc., based on exactly this sort of reasoning…
-
@hzulla new 500-mile email just dropped
-
@jak2k ‘defaults to 0’
-
@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.
-
@itgrrl @benjamineskola @jak2k Several have been rejected.
-
@benjamineskola @hzulla It wouldn't create a small spike at the minute mark. Most Linux distributions use SystemD and its timers have this randomization built-in and considered while timer scheduling: https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html#RandomizedDelaySec=
@jak2k @benjamineskola @hzulla Vixie cron supports jitter, but defaults to "none.'
Cronie supports it, and it picks a random jitter value on boot or whenever it restarts. I use it on my boxen, that's how I stumbled across it.
I've also found this technique useful: https://cronradar.com/blog/cron-midnight-load-spreading
-
@benjamineskola @funkylab @hzulla
Easily solved with anachron (usual default random delay is 0-45 minutes)
@johntimaeus @benjamineskola @funkylab @hzulla Ooh! Good mention!
-
-
it is for most outlets, but clothes dryer and oven will have special 240V outlets
-
@paul_ipv6 @mattblaze @hzulla My original load projection for Netnews, back when we were designing it in late 1979, as “1–2 messages a day, from 50-100 computers, mostly about Unix system internals”… I was off by far more than two orders of magnitude, of course, which is why I never went in for traffic forecasting.
@SteveBellovin @paul_ipv6 @mattblaze @hzulla Nor I. Early on I was asked to forecast how big a DDoS our link at the office could withstand before we were completely cut off. The next day the first gigabit DDoS attack was detected, easily three zeros above what the office DSL line could handle.
-
@SteveBellovin @mattblaze @hzulla brb writing a horror novel called “Children of the Cron.”
@20002ist @SteveBellovin @mattblaze @hzulla Sequel to _Crop Circles In the Korn Shell_?
-
@hzulla more for constraints on local compute capacity than the global power grid, but I can't be the only sysadmin who routinely staggers recurring jobs likely updates or backups to kick off at semi-random times like 02:17, 03:43, etc., based on exactly this sort of reasoning…
-
@hzulla Cron, of course, dates back to a world in which:
- computers were a significantly smaller part of the load on the power grid
- we didn't have tightly synchronized clocks everywhere (no NTP yet)
- we didn't have architectures in which power consumption was as tightly linked to computational loadSoftware often outlives all sorts of assumptions!
@mattblaze @hzulla i was thinking of this earlier after reading the news. Cron is now harming the grid because of course we didn’t think of that. Haha
