[hexbinencoded]

Maybe use an embedded micropower system with C or Rust and interrupt-based processing approach rather than CPU-eating polling in something dynamic like Python, Ruby, or Node without ever going into standby mode.

[akritrime]

Sounds interesting. Can you point me to some resources that compares the two or how `embedded micropower system` and `interrupt-based approach` works?

[archi42]

Try programming an Arduino with interrupt handlers, sending the main loop into deep sleep.

Of course this won't work for every program. And with current tech you're unlikely to drive FB with a warehouse full of arduinos ;)

First DDG hit, only skimmed it, but it seems to cover the idea pretty well: https://circuitdigest.com/microcontroller-projects/arduino-s...

For my Tasmota based devices, increasing the sleep time in the main loop to 250ms decreases power draw by 40%. They now might miss button presses (seems Tasmota polls?), but that's a non-issue for pure actors.

[akritrime]

Hmm, if I am understanding correctly, it's not just about changing the runtime model of the eventloop for languages like NodeJs but also we need fundamental change in our hardware interacts with software.

[archi42]

It's used in embedded. For a server you have other consumers which are a pain yo power down. And then you need to get some interrupt.

My home server can WoL on unicast packets, so that could be used as an "interrupt" to wake the machine from standby. But then you need a suitable workload that allows for substantial sleep time (e.g. wake up for 3s every 30s). Or you could schedule minutes precision polling by waking up via RTC.

Saving power when serving even a few https requests peer second with a sub 10ms response time - as I said, forget about it, at least with x86 hardware as we have today.

[a9h74j]

IIRC, when USB was first introduced one form of comment was that it forced reliance on more central CPU resources [for polling?]. I.e., conveniently for Intel in terms of need for CPU "power".