It works!

[Yellow_Horror]

I need to know if "refuse to die" mod works or not. If it not work indeed I remove it from CUDA MB.

So I need next info on this topic:

1) When CUDA MB processed task enters in "waiting to run" mode what tasks are in "running" mode ?
2) What access state of GPU_lock file (is it accessible or not)
3) Is any progress inside state.sah of task being in "waiting" state.
4) How many CUDA MB processes running in system at this time
5) temp of GPU (busy or idle).

It seems to be two different types of "wrong" behaviour on my system.

The first one is the app freezes at 3 seconds of CPU time with progress 0%. The GPU is idle (as shown by nVidia System Monitor by "GPU Usage" and "GPU Temp" parameters). Suspend/Resume the task don't help (no new task is started, no progress of the freezed task after resume). Stop/Restart BOINC help - the previously freezed task run normally and crunching continues... until next freeze. Sorry, no info about gpu_file_lock and state.sah at this moment. Will see at the next freeze.

The second variant is a task suddenly receive "waiting to run" state in the BOINC Manager. The GPU seems to be working, gpu_file_lock is locked, state.sah is renewed timely. Now i wait if such task will be ended in time.

[Yellow_Horror]

The "Waiting to run" task is ended (suddenly to BOINC) and reported.
http://setiathome.berkeley.edu/workunit.php?wuid=404255137
Claimed credits seems to be low

[Jason G]

...
Claimed credits seems to be low

Better than my lousy 1.94 credits, LoL

[Yellow_Horror]

Claimed credits seems to be low

Better than my lousy 1.94 credits, LoL

My task stuck at about 30%, your at 1.712%. Probable it makes sense.

[Yellow_Horror]

I notice another sign of strange behaviour:

26/02/2009 16:13:14   SETI@home   [task_debug] result 16ja09ab.7620.1708.12.8.217_2 checkpointed
26/02/2009 16:13:16   SETI@home   [cpu_sched] Preempting 16ja09ab.7620.1708.12.8.217_2 (removed from memory)
26/02/2009 16:13:16   SETI@home   [task_debug] task_state=QUIT_PENDING for 16ja09ab.7620.1708.12.8.217_2 from preempt
26/02/2009 16:13:17   SETI@home   [task_debug] Process for 16ja09ab.7620.1708.12.8.217_2 exited
26/02/2009 16:13:17   SETI@home   [task_debug] task_state=UNINITIALIZED for 16ja09ab.7620.1708.12.8.217_2 from handle_premature_exit
26/02/2009 16:13:17      [coproc_debug] freeing 1 of coproc CUDA
26/02/2009 16:13:17      [work_fetch_debug] Request work fetch: application exited
26/02/2009 16:13:17   SETI@home   [cpu_sched] Starting 16ja09ab.7620.1708.12.8.217_2(resume)
26/02/2009 16:13:17      [coproc_debug] reserving 1 of coproc CUDA
26/02/2009 16:13:17   SETI@home   [task_debug] task_state=EXECUTING for 16ja09ab.7620.1708.12.8.217_2 from start
26/02/2009 16:13:17   SETI@home   Restarting task 16ja09ab.7620.1708.12.8.217_2 using setiathome_enhanced version 608

This is repeated every few minutes, dropping overall performance.

I use BOINC 6.6.10. Is such behaviour normal or not? Must i report it to developers as a bug?

[Richard Haselgrove]

It probably depends what other projects you have the host attached to, and what resource share SETI has been given.

BOINC should only 'preempt' a SETI task (second line of log) if processing time is owed to another project, and it wants to start (or re-start) a task for that other project. Was any other project invoked, below the end of the log you've posted?

I haven't risked testing any of the v6.6.x line yet, but I see this quite regularly with v6.4.5 - particularly since I also run Astropulse (sometimes intensively testing AP optimisations), and AP counts towards SETI resource share. Although I haven't looked at task debug, what I've seen is entirely compatible with:

Another project needs a turn --> preempt CUDA --> start Einstein (or whatever) --> oops, CUDA is idle --> start CUDA: I end up with 5 running CPU tasks on a 4-core CPU.

Yes, I think this should be reported to the developers, but I've been holding off while they've been wrestling with the comprehensive re-write of all the work-fetch issues. But I've seen signs that they might be about to make the v6.6 range 'recommended' - should we push them into reviewing task switching first, or wait for v6.8?

One simple but, I suspect, possibly overlooked point: if your resource share is less than your CUDA hardware proportion, BOINC is always going to have a work allocation dilemma. For a quad plus one GPU, resource share needs to be at least 20%: duo plus 2 GPU, 50%: and so on.

[Yellow_Horror]

It probably depends what other projects you have the host attached to, and what resource share SETI has been given.

BOINC should only 'preempt' a SETI task (second line of log) if processing time is owed to another project, and it wants to start (or re-start) a task for that other project. Was any other project invoked, below the end of the log you've posted?

There is no other projects on this host.

[Richard Haselgrove]

It probably depends what other projects you have the host attached to, and what resource share SETI has been given.

BOINC should only 'preempt' a SETI task (second line of log) if processing time is owed to another project, and it wants to start (or re-start) a task for that other project. Was any other project invoked, below the end of the log you've posted?

There is no other projects on this host.

The only other reason I can think of for a pre-empt is to start a task in 'High Priority' because it might be in deadline trouble. I have a box at the moment which is alternating: it does a VLAR task, which drives up TDCF - runs 3 or 4 shorties in EDF, which drives it back down - goes back for another VLAR - panics and does a couple of shorties - etc. etc. Anything like that on your system?

If it's preempting with no discernable reason, that should certainly be reported to the developers, with extended logs (four or five full cycles) attached.

[Yellow_Horror]

I don't know if it correspond with previous problem or not, but i notice one more strange thing: this morning my BOINC download some new WUs that have typical Seti MB names. But these tasks have empty "application" field in the BOINC "Tasks" panel. If i suspend all other tasks, one of this "no-app" tasks starts to be crunched with V9 CUDA application, but its "application" field remains empty.

Maybe i miss something critical in my app_info.xml (it remains unchanged from the time i start this topic)?

[Leopoldo]

But these tasks have empty "application" field in the BOINC "Tasks" panel.

Each downloaded workunit is registered in file client_state.xml at BOINC-data folder. Record there contains info about application name and version.

[Yellow_Horror]

There is the part of client_state.xml corresponding to one of the "app-empty" tasks.
Nothing weird as far as i can see:

<workunit>
    <name>11ja09af.31819.74374.10.8.178</name>
    <app_name>setiathome_enhanced</app_name>
    <version_num>608</version_num>
    <rsc_fpops_est>78918495483347.094000</rsc_fpops_est>
    <rsc_fpops_bound>789184954833471.000000</rsc_fpops_bound>
    <rsc_memory_bound>33554432.000000</rsc_memory_bound>
    <rsc_disk_bound>33554432.000000</rsc_disk_bound>
    <file_ref>
        <file_name>11ja09af.31819.74374.10.8.178</file_name>
        <open_name>work_unit.sah</open_name>
    </file_ref>
</workunit>

[Jason G]

Probably cosmetics related to the juggling in process to get the app scheduling 'right' .  I think they might have quite some playing to do to get the mechanism to work with app_info file the way we'd all like to see, so I'm expecting some related things to break and change, then be fixed again afterwards.

[Yellow_Horror]

As far as i can see at Seti@Home message board, randomly stop/resume a task is a bug of 6.6.10. Will see if it is fixed in 6.6.11... or downgrade to 6.6.9.

Can someone tell me the exactly address of BOINC "wishlist"? I wish an option to suspend CUDA while a fullscreen application (other than screensaver of course) is executed. IMHO, it is the simplest way to solve "laggy DVD-player" issue.

[Richard Haselgrove]

The official route is to make out a trac ticket.

You could add a comment to reinforce http://boinc.berkeley.edu/trac/ticket/842, which has just been postponed from 'v6.6' to 'Undetermined' (i.e. 'far future')

[Richard Haselgrove]

Sorry, that seems to have backfired. David Anderson has replied, following Yellow_Horror's addition:

resolution set to wontfix.

Currently, there's a preference to not do GPU computing while the computer is in use, and a config option to not do any computing while particular applications are running. That's about it for now; I don't know of a way to find out if another graphics-intensive app is running.