Login
You're viewing the mastodonapp.uk public feed.
  • Nov 1, 2026, 10:14 AM

    @shaknais Synchronised extra work in the start of ANY minute, as fired off by EVERY cron on the planet, will add to *this* problem. Cron (as I have ever used) does not add jitter to its wakeup on the minute, whichever minute that is. (Picking random minutes does reduce *other* problems.)

    To be clear: 1/60Hz spikes are independent of 1/3600Hz spikes etc: they should both be dealt with, but have to dealt with separately.

    💬 1🔄 0⭐ 0

Replies

  • Nov 1, 2026, 10:22 AM

    @DamonHD How would spreading the start time of processes, across 60 new units, instead of 1, suddenly increase load?

    How do you get _more_ from _less_? You're distributing.

    If what you're saying is true, then PFR wouldn't be working in Australia, because that only spreads across 4-seconds for the 1/50Hz. But it is working.

    💬 1🔄 0⭐ 0
  • Nov 1, 2026, 10:27 AM

    @shaknais Independent frequency components are independent. I don't know how to say this in other ways.

    Spreading the start time from the start of minute 0 to the start of minute X where X is randomly 0, 1, 2, ... 59 (in each case a whole number) still results in average extra load across the hour of the same amount in the start of an average minute.

    💬 1🔄 0⭐ 0
  • Nov 1, 2026, 10:28 AM

    @DamonHD Okay... So what the article says Australia is doing and working for dealing with the problem, isn't dealing with the problem. Got it.

    💬 1🔄 0⭐ 0
  • Nov 1, 2026, 10:30 AM

    @shaknais They are containing the problem by making the rest of the system work harder to suppress it, but not removing it at source.

    Did you look at the linked to Nature paper? It's moderately readable, and explains this better than I am.

    "These developments demonstrate that the recurrent 1-min oscillation already has operational relevance, even though current mitigation strategies primarily address amplification rather than the underlying source."

    💬 0🔄 0⭐ 0