The corresponding concept in gears is to avoid meshing two gears unless the number of teeth are co-prime, because this will cause uneven wear patterns. If the tooth counts are coprime, then each tooth will contact every tooth on the other gear the same number of times, effectively "wear leveling" the teeth.<p>In this instance, one fix is to fire the timer every 59.XXX seconds, so it will naturally drift out of phase with the minute hand of the clock.<p>If work needs to be done exactly every 60 seconds, this is fixed by having a WAIT(RAND(60e6)) microseconds during the first timer initialization, so if 10,000 units start simultaneously they don't try all at once. This is good practice in most (all?) systems. Hint: test power and infra outage/reconnect, which can unintentionally sync timers.<p>This is why many software will do automated updates every 17 hours: 17 is coprime with 24.<p>Classic "thundering herd" mitigation tactics.<p>Edit: Tempting to blame IoT, but (since this is news) I don't think anyone knew there was something to fix here. We have the tools however.
I get a disturbing amount of equipment that does not take into account the inrush current of starting many loads at the same time. While each individual device is protected by a breaker that can handle the inrush of it's load the main breaker for the equipment is not sized to handle every load starting at the same time. The fix is to include logic that starts things up one at a time but convincing engineers, project managers, and machine owners that they didn't think of everything is an uphill battle.
We used to have a turbopump that would trip the breakers every time you turned it on from cold. The pump seemingly attempted to spin up to max RPM before settling down to a more sustainable load. The only way to get the thing to stay on was to turn it on once, let it warm itself up on the initial attempt, trip the breakers, and try it another cycle now that it had some momentum and would pull slightly fewer amps. Sometimes took a few attempts to get that rolling start working.
I assume you are talking beyond what (in the DIN rail world) type B/C/D breakers are meant to handle?<p>It's sort of a solved problem - the ones I'm aware of are things like LynTec sequenced panels built exactly for this, and Siemens' SENTRON semiconductor CBs where you can control then curve to your spec.<p>Convincing stakeholders though, is almost a job of its own.
what? Inrush current is well known in electronics engineering.
59 seconds will still have second alignment. Maybe it needs to be prime milliseconds or microseconds.
But seconds are 60X higher frequency than minutes. This is almost 6 octaves higher. The grid will low-pass-filter that out much better than the minute period. (You can see that trend in the diagrams given in the article: the amplitudes all get lower with decreasing period to the left, where the 60 second blip is a an outlier.)<p>Secondly, the amplitude drops. Events that were concentrated on the xx:xx:00 times are now distributed into xx:xx:xx times. If the overall number of events is the same, each :xx time slot now receives 1/60th of the events that were concentrated on the :00 time. If power decibels are relevant here (20 log 10 x), that's a 35 dB reduction in amplitude of the driving signal.<p>35 dB less amplitude, shifted to a 6 octave higher frequency that the grid doesn't react to very well can be expected to basically make the problem vanish.<p>This is much like the situation of soldiers avoiding rythmic marching when crossing a bridge to randomize their footstrikes.
It depends on a lot of factors, but even second granularity gives you a 60x reduction in the thundering herd. Whether more is needed or even possible often depends on the specific problem domain. For example, if your task takes 20ms, us granularity doesn’t help. Indeed it makes it worse if you’re using randomization because there’s a lot more microseconds than seconds so you can end up with a lot of work that ends up in practice still getting scheduled together due to other delays.<p>You want your jitter to be significantly >> than the time your task takes as otherwise you get non intuitive degradation that can reintroduce the problem you’re trying to solve. It’s a balancing act picking the jitter that drops off the thundering herd enough and one that is still greater than the time your work takes.
Small nit: Wait(50+rand(10)) is probably closer to what you want to get about a minute between executions. As stated your proposed execution has an average about 30s execution interval with a variance of about 17s. If you’re talking about a random sleep on a 1 minute interval, this actually results in a possibility of 120s between tasks, also not what you want.<p>But yeah, as soon as you start using Rand most people make all sorts of mistakes. And if you’re using C Rand, don’t. It has other statistical problems.
Coprime meaning "no common factors".
I'm skeptical that this one minute jitter period is solely attributable to one minute timers in power inverter equipment. It's likely the net scale effect of all cron-like scheduling of actions in everything with a microprocessor. All the long-term scheduling that is done with minute precision (i.e. seconds field is implicitly :00) regardless of its individual period. Like if one device is scheduling at x:17 and x:47 every hour, another one is doing x:06, x:09, x:12, x:15, ... and numerous other combinations, at scale, the common divisor will be one minute. If wall clock time is used, all the devices that are synchronized to a network time will have cron-like scheduling events firing at xx:xx:00 for all values of x.<p>This type of scheduling should be randomized at the seconds level, perhaps. Unfortunately, it would require a massively coordinated effort across numerous operating system and application stacks.
Maybe too many things are started from crontab. Public NTP servers observe large spikes in traffic on minute marks due to admins putting ntpdate in crontab instead of running a proper NTP service.
I know my older APC UPSes do weekly self tests, but I guess newer equipment does more frequent self testing? And of course they're all internet-connected meaning clocks are within a few hundred ms of each other.<p>It also made me think about how many GitHub Actions I have that kick off on Sunday morning at a specific time. I try to vary the time/day for those jobs but I'm guessing there are enough things that kick off at specific time intervals to make an impact at the top of an hour, or at :15, :30, :45...
This is why systemd gives you the RandomizedDelaySec option. (Other cron-like facilities may have similar features, I'm not discussing them here). Set that to N and each time the timer reaches its trigger (say, once per day), its <i>actual</i> start will be up to N seconds after the trigger. E.g. if a once-per-day trigger is at midnight but you have RandomizedDelaySec=300 set, then it will run sometime between 0:00:00 and 0:05:00, with a different actual start time each day.<p>If enough people used that, with a high enough value of N (say 1800 for jobs that really don't have to start at any particular time), it would greatly spread out the spikes in accidentally-coordinated usage.
Cool, I thought grid stability attacks would rely on large numbers of IoT devices but it looks like computing infrastructure is the better target.<p>Whether it's by buying and using a trillion tokens strategically or by inserting synchronized malicious jobs it should be possible to find some resonant frequencies in the line frequency control system. By loading and unloading multi-megawatts of draw you could get the local supply throttling up and down enough desynchronize from the larger grid. If you could get real time measurements of the line frequency you could use that to tune your malicious load and do the whole 'pushing a kid at the peak of their swing' thing.<p>To mitigate you would have to put dummy loads or some kind of minute-scale power storage onsite or nearby to compute loads.
Multiple MW is noise level, even to a single moderately sized power production facility, let alone the whole grid region. This is not a viable attack. I can have an entire aluminum smelter trip off or start up and it won't phase my supply, a data center is going to be trivial unless you can spend enough to control <i>all the data centers</i> in which case youve just made the least efficient grid attack in history.<p>Further, there is no single resonant frequency, only the particular resonance of that exact moment in time. The grid is composed of many generating units, many transmission lines, many transformers. The resonant frequency of the grid is changing moment to moment as those things come online, get loaded partially, go offline, heat up, etc.<p>This is not a child on a swing set problem.
Ones and twos of MW are indeed tiny loads, there is a 1MW motor where I work that gets flicked on and off like a light switch, but hyperscale canters are in the >100MW range, that's >1% of even the largest generating stations in the USA.<p>And you're not aiming for some physical resonant frequency of the entire grid, just the controller on your local generator, getting it to ramp up and down chasing just behind your changing load.<p>I live in Ontario and in the past week the difference between our highest and lowest demand was ~4.5GW, but those changes take place over hours. If you can ramp up and down a 0.1GW load over minutes there is going to be a point where some control loop can't keep up. Generators have physical inertia but compute loads do not.<p>I agree that it's not trivial, not cheap, and not efficient but with the state of the world it would not be a surprise if some nation thought it would be useful to burn resources in order to disrupt an important event, maybe elections?
I'm not sure I agree with the conclusion that this is merely caused by UPS system control logic. That is an extreme amount of coordination across a lot of makes, models and configurations.<p>The FFT indicates this is a periodic signal, not a once a day or week thing. It's happening continuously all day every day. I don't know of any UPS systems that perform tests with this kind of regularity.<p>In any case, I refuse to believe an external sync signal is causing this. The more likely explanation is that the active elements are pulling each other to a common mode due to being physically coupled on the same grid. This is like how clocks on the same beam will synchronize.<p><a href="https://en.wikipedia.org/wiki/Injection_locking" rel="nofollow">https://en.wikipedia.org/wiki/Injection_locking</a>
The external sync here is NTP. Synchronized clocks + timer-scheduled actions → globally synchronized behavior<p>From the article:<p>> The origin of these current peaks was independently confirmed by the manufacturer to be periodic self-tests executed by the battery EMS, confirming our interpretation. Similar minute-scale diagnostic routines are also documented for other commercial UPS systems (cf. Supplementary Note 8).<p><a href="https://www.snaptec.com.au/akkutec-4801-din-user-manual.pdf" rel="nofollow">https://www.snaptec.com.au/akkutec-4801-din-user-manual.pdf</a><p>> battery circuit testing 1 x per minute for 1 sec<p><a href="https://adelsystem.com/hubfs/PDF%20DC-UPS/Instruction%20Manual%2073_4-M.pdf?hsLang=en" rel="nofollow">https://adelsystem.com/hubfs/PDF%20DC-UPS/Instruction%20Manu...</a><p>> The battery testing is carried out automatically every 60 sec.
So, the two devices you refer to have no time-of-day clock, no network connection, no TCP/IP stack, and certainly no NTP clients.<p>Their testing on the enterprise-class equipment shows the difference that NTP makes, and with enterprise-class equipment comes wider deployment and more powerful models.<p>But most of the consumer units would not have this stuff. Surely, the manuals would describe how to set it up.
A very interesting article, but it is disappointingly vague about what these UPS self tests are, and exactly how they cause disruption to the power grid. Figure 5b shows that their building's UPS has 20-amp spikes exactly every minute, which is a pretty big spike. My guess is that a UPS performs a self test by switching from line power to battery power. If most of the UPS units in a country do that exactly every minute, synchronized by NNTP [edit: NTP], yeah I can see that it would mess up the grid having all that load dumped at once. (Although the observed frequency disturbance of 1.5 mHz is extremely small, 3/1000 of a percent.) Now that the problem is identified, it should be trivial for UPS manufacturers to eliminate it.<p>(By the way, the article is in Nature Energy, not Nature which the URL suggests.)
> If most of the UPS units in a country do that exactly every minute, synchronized by NNTP,<p>Thankfully, usenet usage is way down, so we won't need to worry about this. ;p