[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: