The funny thing is, modern electrical codes already account for this phenomenon. In order to implement Net Metering (selling your power to the grid), modern standards implement two kinds of jitter:
- Sandia Frequency Shift: a minute shift in the power frequency generated by inverters. If the grid is connected, this is effectively eliminated; if the inverter is disconnected from the grid, it detects the frequency has shifted and disconnects the inverter from the grid.
- Slip-Mode Frequency Shift: basically the same thing, but phase shift (which I don't understand).
Both of these are used for anti-islanding (don't create an island of power). When the inverter detects it's isolated and stops outputting current, it then has to check every 5 minutes, with jitter, for whether the grid is restored or not. It has to add random jitter, because otherwise all the mini battery/solar installs will come online at the same time and swamp the grid, causing another outage.
* * * * * sleep 17 && …
That way I still maintain a per-job 60-second cadence consistently (which random would not), but don’t do it right on the top of the minute.
give it number and you will get random value up to that number, same every run for a given host, but different per host (basically, hashed host fqdn)
add a label and you will get different number but similarly consistent. Makes it real easy to randomize run across the fleet.
Would be easy script to make.
Also systemd timers have the randomization builtin, just need to specify time
RandomizedDelaySec=12hJournalctl with SQLite or a columnar embedded database would be amazing for sysadmins. Current format is entirely useless
If the answer to that is all-yes, then my compliments to you. Alas ... at least my experience says that's not how things are done.
OnCalendar=Sat *-*-08..14 00:00:00
RandomizedDelaySec=360min
The improved logic vs. cron is one of the features which makes my life easier, and so I started using systemd more often. IMHO some of the newer additions aren't quite as solid; but the basic units have proven to be very handy. Another example: The 'path' unit, which can trigger whenever a defined file is updated.
https://shoppress.dormanproducts.com/hunting-tooth-gearsets/
Obviously cron jobs are not all equal in terms of load and duration, and hours are not all equal in terms of usage, but that still helps prevent trivial spikes similar to the one mentioned in the article (disclaimer: I'm not aware of a recent counterfactual experiment proving this, but that seems a fair assumption).
Analog systems naturally have a dispersion to them, digital ones, especially with everybody on NTP, much less so
There was an post a couple of days ago about a telco debrief of an interesting outage that happened. Several things went wrong like the audible bell was manually silence from being heard as a step in routine working but was forgotten to put back into normal mode once work was complete. The actual loss in power triggered the automatic switch to the batteries, but something else seemingly benign happened at the same time so that when power was restored, the batteries had been depleted to the point the charging process could not start because of something similar to this. I wish I could remember the write up, as it was really well written about the cascades of failures that occurred.
The turbines/generators set the grid frequency itself.
Having the batteries disconnect/connect would cause the generators to slow down and then speed up (or vice versa) which makes the rest of the grid frequency fluctuate as well.
It may also trigger the FCAS part of the grid that is paid to keep the frequency within the required range which is +/- 10mHz-200mHz.
It's thousands of few kW's of load