Opened 12 years ago

Last modified 12 years ago

#1215 new Defect

boinc_client does not notice (or does not care) that "computer is in use"

Reported by: Bluefin Tuna Owned by:
Priority: Undetermined Milestone: Undetermined
Component: Undetermined Version: 7.0.28
Keywords: Cc:

Description

On Linux (Fedora 17 KDE spin), boinc_client (7.0.28 x86_64-pc-linux-gnu) is running as user "boinc", a user not used for anything else.

Settings as per "Computing Preferences (apply to all BOINC projects in which you participate)" are for Processor Usage:

Suspend work while computer is on battery power?    yes
Matters only for portable computers 	            yes
Suspend work while computer is in use?	            yes
Suspend GPU work while computer is in use?          yes
'In use' means mouse/keyboard activity in last	    5 minutes
Suspend work if no mouse/keyboard activity in last  --- minutes
Suspend work if CPU usage is above                  50%
Do work only between the hours of                   ---
Leave tasks in memory while suspended?              no
Switch between tasks every                          120 minutes
On multiprocessors, use at most	                    --- processors
On multiprocessors, use at most                     100% of the processors
Use at most                                         75% of CPU time 

The machine has 2 non-threaded CPUs. As per lscpu:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             1

It also has a CUDA-capable graphics card, which is being used for BOINC projects.

Scenario:

  • boinc runs while user is absent
  • once the user activates the machine, boinc notices this and tunes down (the log shows nothing though, I think it should ... is there a "verbose" option?) ps then shows only the "boinc_client" running, not the tasks themselves
  • however, after a quarter of an hour or so, the tasks start up again; computer interactivity slows noticeably. More amazing, there are actually 3 tasks running [e.g. 2 x einstein@home + 1 x seti] even though the machine has just 2 CPUs (maybe it's done differently on CUDA machines); here too logging the decision logic would be informative
  • boinc knows the machine is in use though, the log says "Suspending network activity - computer is in use"
  • to get the machine in hand, one has to "kill boinc"

Change History (5)

comment:1 Changed 12 years ago by Christian Beer

Are you using a Fedora Package Manager installation or did you install BOINC after downloading from the official site? Packaged versions are not really supported by the official project because we don't know what the package maintainer changed and if this has some side-effects we don't know about.

To your question of a more verbose output you should look at the user wiki (http://boinc.berkeley.edu/wiki/Client_configuration) where you can find log_flags that are helpful in this case. The flags suspend_debug and task_debug may be helpful in your case.

Next question is about re-enabling computation after 45 minutes. If the user is still using the computer (mouse/keyboard activity) than this clearly is a bug. If the user is just watching a movie and not doing anything the System thinks that the computer is unused. This should be identified by the log messages. What shouldn't happen is that the computer is slowed down by the science apps. The regular BOINC client sets the process priority to lowest when starting any science application and therefore this shouldn't interfere with normal operations. Please refer to what I wrote about packaged versions of BOINC.

As GPU computing is allowed and a capable GPU is found you will always see three science processes started. One for each CPU and one for the GPU.

comment:2 Changed 12 years ago by Ageless

Also know that there was this fix in 7.0.29:

  • Fix for linux idle detection bug with USB mice.

For logs on what may or may not be fixed already, see the BOINC 7 Change Log thread on the BOINC forums.

comment:3 Changed 12 years ago by Bluefin Tuna

Hi,

The boinc executable has been compiled from the 7.0.28 source directly.

I will add some log flags as described in the link, thank you.

In this case, I am using the computer [e.g. for editing work] while boinc is running. This makes the slowdown very noticeable (actually, things become unacceptably slow). I don't think I saw that behaviour before I enabled the GPU, so there may be some DMA or contention problem with the graphics driver/hardware (Btw, I am using the 'nvidia' driver instead of the Fedora 'nouveau' - unsure whether I should). Will test what happens with GPU disabled.

Will also try 7.0.31, this is going to take a bit...

comment:4 Changed 12 years ago by Bluefin Tuna

Update:

1) Looks like (USB) mouse mouvement is indeed not recognized. It's typing that triggers "computer in use" state.

2) The high-inertia effect is either due to the GPU or to einstein@home. Running "--no_gpus" (and thus only seti@home) triggers instant shutdown when "computer in use" is detected. If einstein@home is using the GPU, then shutdown is "rather slow" (will have to time) and for some reason response times of applications suffer a lot.

comment:5 Changed 12 years ago by Bluefin Tuna

Update:

Without GPU

  • Responsiveness of PC does not suffer, irrespective of whether boinc is running or not.
  • Computer is recognized "to be in use":
    • The first time only by typing into any terminal window (not necessarily the terminal window belonging to the user who is running boinc). At that point boinc shutdown is rather instantaneous. Typing in a text editor, typing in firefox or mouse movement/clicking around is not' recognized.
    • The second time (i.e. once boinc reactivated again because of computer idling), only by typing into a terminal window that was already running when boinc reactivated. A window opened after that is apparently not considered.

With GPU

  • As above, but responsiveness of PC does suffer; einstein@home must be fighting with X for GPU usage.
Note: See TracTickets for help on using tickets.