Re: gpuenv-utils 0.1.4 uploaded: Powersaving / uptime management
Hi Cory,
On 2024-07-09 17:58, Cordell Bloor wrote:
> On 2024-07-08 12:09, Cordell Bloor wrote:
>> In the BIOS on bootes, there is an option to control the RTC alarm via
>> the operating system. In fact, it is the default. I wonder if it might
>> make sense to instead call rtcwake [1] to shut the system down and
>> check back in a few hours.
I wasn't aware of rtcwake. What a useful feature. And it's even part of
util-linux. Neat!
> Argo and Lyra are Dell Poweredge 4130 systems and they do not seem to
> have any option in their BIOS to configure an RTC alarm. However, I had
> success shutting down Lyra for ten minutes with:
>
> sudo rtcwake -m off -s 600
I tried this on my dev box and it worked on first try as well, without
touching the BIOS. Fantastic.
> I only tried a dry run (with "-n -v" suffixed to the command), but:
>
> sudo rtcwake -m off --date +6hour
>
> appears to work as expected.
>
> I could make use of the existing system by setting up a service that
> called rtcwake at boot to set up an alarm and refresh it on a timer
> at regular intervals, but it seems like it would be simpler to
> integrate the wakeup into your system by calling `rtcwake -m off`
> instead of `shutdown`.
Definitely. I think it would be best to add a --rtcwake <timespec>
option to the auto-uptime utility (so that it can be disabled if
necessary), to add the invocation with 6h to the .service file.
Does that sound OK to you?
On 2024-07-08 20:09, Cordell Bloor wrote:
> With that said, such a feature request will inevitably lead to more requests for configuration options. And the better solution is arguably to have a small, power-efficient server do the monitoring for new jobs and send wake-on-lan anyway.
I'm glad to hear feature requests, even if I may not be able to
implement them.
This time around, I spent most of the my effort on getting good test
coverage right from the start, and I deliberately skipped a number of
features because they need real-world testing and feedback first, for
example:
* No config file, just --options that are used by .service
* No state persistence (restarting the server forgets everything)
* No clever request queuing (so no deadlocks with multiple devices)
* Unix socket comm only ("render" group is all auth needed)
* Only GPUs (could also lock CPUs and/or RAM)
I think this will need to change eventually, but I wanted to wait for
the use case to materialize.
We had the same idea -- I also thought that at some point, we'll have
some RPi-like device driving boxes via wake-on-lan. In the
super-best-case, together with [2].
Best,
Christian
[2]: https://salsa.debian.org/rocm-team/debci/-/issues/14
Reply to: