[conspire] idle computer

Rick Moen rick at linuxmafia.com
Tue Jul 12 20:14:56 PDT 2011


Quoting Paul Zander (paulz at ieee.org):

> Situation 1:
> I will agree the classic SETI and the newer BOINC appear to sense
> keyboard and mouse activity.  Unless someone can provide alternate
> information, I conclude that these are not compatible with a computer
> that sometimes needs to run another activity unattended.

Bearing in mind that these are proprietary programs that I don't run:  
I gather that they merely (in their default operating mode) kick in 
via hooks to the screensaver.  (There appears to be some sort of mode
where it loads via an init script.  I'm not sure if that's the same
thing.)

If the problem is that they are grabbing too many CPU cycles, then
either (1) disable the screensaver when you're crunching something for a
long time in background, or (2) adjust the operation of SETI at Home
Classic or BOINC to reduce its runtime priority using 'nice' as a 
prefix on the program's invocation.

That is, if there's a startup script that says

  nohup ./seti &

...then change that to

  nohup nice ./seti &

The 'nice' utility, part of GNU coreutils, accepts numerical values for
additional niceness (reduced runtime priority) to assign to tasks at the
time they start up.  I would guess this information is passed in some
fashion as a request to the kernel's scheduler.

'nice' defaults to a +10 adjustment, i.e., just 'nice' is the same as 
'nice -n 10'.



> Situtation 2:
> This happened during an install of LMDE from DVD onto a laptop.  Once
> it started copying the files from the DVD, I walked away and expected
> that it would complete on its own.  Instead when I returned, the
> screen was black.  I touched ?? on the keyboard and the screen light
> up and it showed that files were copying.  At this point, the DVD and
> HD lights were blinking.  
> 
> I repeated this process of walking away and coming back several times.
> After a couple iterations, I realized that the disk lights were NOT
> active when I approached the machine, but were on after the display
> was also back on.

At a guess, sounds like something in userspace that was giving the ACPI
chip its marching orders decided to either put the CPU into powered on
but inactive mode, or decided to initiate sleep aka suspend-to-RAM, in
either case via ACPI directives.

You might be able to find out more by looking in the acpid logs, if
there are any, or in other logs under /var/log if there aren't.

You could also have a look at the /sys/power/* files directly, or via
some of the lightweight commodity tools I mentioned.  Or using whatever
heavyweight tool GNOME provides.  (Aside:  LMDE has both GNOME and Xfce
editions.)

> I am guessing that maybe power settings that had been previously made 
> with Windows were saved in hardware outside of either OS and that 
> the settings caused the computer to go to an "idle" state.

As I've mentioned upthread, my own reading about how ACPI works suggests
this doesn't seem likely.  However, you can certainly test your
hypothesis:  Go into MS-Windows and set the power settings to something
very distinctive.  Then, hardboot to LMDE/GNOME and see if those
settings persist.

Personally, I like to learn how things work at a more fundamental level
than just via GNOME graphical widgets, for a variety of reasons
including not being reduced to helplessness if I'm suddenly using a
machine where those widgets aren't available.





More information about the conspire mailing list