It works!

[Yellow_Horror]

I delete my cc_config.xml and feed the BOINC v.6.6.10 with such app_info.xml:

<app_info>

<app>
    <name>astropulse</name>
</app>
<file_info>
    <name>ap_5.00r103_SSE3.exe</name>
    <executable/>
</file_info>
<app_version>
    <app_name>astropulse</app_name>
    <version_num>500</version_num>
    <file_ref>
        <file_name>ap_5.00r103_SSE3.exe</file_name>
        <main_program/>
    </file_ref>
</app_version>

<app>
    <name>astropulse_v5</name>
</app>
<file_info>
    <name>ap_5.03r112_SSE3.exe</name>
    <executable/>
</file_info>
<app_version>
    <app_name>astropulse_v5</app_name>
    <version_num>503</version_num>
    <file_ref>
          <file_name>ap_5.03r112_SSE3.exe</file_name>
        <main_program/>
    </file_ref>
</app_version>

<app>
    <name>setiathome_enhanced</name>
</app>
<file_info>
    <name>MB_6.08_mod_CUDA_V9.exe</name>
    <executable/>
</file_info>
<file_info>
    <name>cudart.dll</name>
    <executable/>
</file_info>
<file_info>
    <name>cufft.dll</name>
    <executable/>
</file_info>
<file_info>
    <name>libfftw3f-3-1-1a_upx.dll</name>
    <executable/>
</file_info>
<file_info>
    <name>AK_v8_win_SSE3.exe</name>
    <executable/>
</file_info>

<app_version>
    <app_name>setiathome_enhanced</app_name>
    <version_num>603</version_num>
    <file_ref>
        <file_name>AK_v8_win_SSE3.exe</file_name>
        <main_program/>
    </file_ref>
</app_version>

<app_version>
    <app_name>setiathome_enhanced</app_name>
    <version_num>608</version_num>
    <plan_class>cuda</plan_class>
    <avg_ncpus>0.040000</avg_ncpus>
    <max_ncpus>0.040000</max_ncpus>
    <coproc>
        <type>CUDA</type>
   <count>1</count>
    </coproc>
    <file_ref>
   <file_name>MB_6.08_mod_CUDA_V9.exe</file_name>
   <main_program/>
    </file_ref>
    <file_ref>
   <file_name>cudart.dll</file_name>
    </file_ref>
    <file_ref>
   <file_name>cufft.dll</file_name>
    </file_ref>
    <file_ref>
   <file_name>libfftw3f-3-1-1a_upx.dll</file_name>
    </file_ref>
</app_version>

</app_info>

Now it crunch 2 Seti MB 6.03 on the CPU and one Seti MB 6.08 on CUDA. I even can use "Use GPU while computer is in use" switch! This is a workaround i needed for all time since CUDA version of Seti first appears (because i don't like video lags while i work or play games). The only trouble remains is to suspend CUDA while i watch DVD video, so BOINC detect no "user activity".

Any suggestions about how to fix this issue (and any other suggestions) are welcome.

P.S. Still hope to see non-laggy CUDA app in the future, even if it will be not so fast.

[Jason G]

Now it crunch 2 Seti MB 6.03 on the CPU and one Seti MB 6.08 on CUDA. I even can use "Use GPU while computer is in use" switch! This is a workaround i needed for all time since CUDA version of Seti first appears (because i don't like video lags while i work or play games). The only trouble remains is to suspend CUDA while i watch DVD video, so BOINC detect no "user activity".

Any suggestions about how to fix this issue (and any other suggestions) are welcome.

P.S. Still hope to see non-laggy CUDA app in the future, even if it will be not so fast.

Hi Yellow_Horror,
   Can you confirm that it now, when downloads new work, isn't constrained to marking the highest version only with optimised app info you show?  Will give it a try shortly to see for myself,  but definite progress.

My suggestion for lagging during video, would be to add your media player programs, and games, to the exclusive apps entries in cc_config, though that would of course stop processing on CPUs too.

Jason

[Yellow_Horror]

   Can you confirm that it now, when downloads new work, isn't constrained to marking the highest version only with optimised app info you show?  Will give it a try shortly to see for myself,  but definite progress.

Sorry, can't check it now because now i have lot of WUs downloaded by stock apps when i first run new BOINC. Maybe few hours later i can answer the question.

Thank you for your suggestion also, but i never wish to suspend Seti CPU applications. They always are user-gentle since i enter the project at june 2003.

[Jason G]

Yeah, tough new growing pains! ... Now I have it set up similar to yours, but with no multibeams in cache, so I'll find out when I can get some new cuda work, exactly what it does.

Jason

[Edit:]
Just checked the Boinc logs, and no mentions of anonymous platform behaviour changes, so my suspicion is the operation will be the same as 6.6.9 and earlier, which had stock separate CPU & GPU work fetches working properly, but when switching to app_info will mark all [newly fetched] work as 6.08  (but I'll wait and see)

The one major change that IS helpful was applied in 6.6.9 .  When tasks marked with an older revision run out, it no longer deletes the old app, if it is marked with a different plan_class .  That is good, because for my own use it enabled me to manually give my cpu app a new application name in app_info,  then modify client_state to allocate chosen tasks to CPU to work on simualtaneously with cuda ones.  Works very well for me, but not for the beginner or faint of heart! 

[Yellow_Horror]

I notice that in my new config the CUDA app freeze sometimes at the beginning of a WU. The CPU time stops at 3 second and the GPU is totally idle. Suspending the freezed task don't help - no new CUDA task starts. Stop and restart BOINC help - until next freeze. I don't have such trouble with "V8a team" mod on BOINC 6.4.5 but remember something like with the early stock CUDA apps (but IIRC suspending a task helps with stock).

What may be the cause?

[Jason G]

What may be the cause?

Not sure, but I've seen some kindof doscussion about DLL's, maybe that's it.  I'm not sure which ones I'm running anymore, but as I updated to v9 recently, I may get the same issue.  Will see.

Jason

[Yellow_Horror]

When tasks marked with an older revision run out, it no longer deletes the old app, if it is marked with a different plan_class .  That is good, because for my own use it enabled me to manually give my cpu app a new application name in app_info,  then modify client_state to allocate chosen tasks to CPU to work on simualtaneously with cuda ones.  Works very well for me, but not for the beginner or faint of heart! 

It isn't an option for me, because while i like an idea to share my free CPU/GPU cycles to SETI science, i really hate an idea to constantly do the same with my own free time. I already spend some time to play with CUDA versions and options because it was an interesting innovation, but i grade to get tired from it. The SETI CUDA application was not beta-tested enough from the beginning (maybe nVidia pushed public release before the New Year due to advertising interests?), it is still wery user-annoying when running, and the BOINC user options to manage CUDA work are still (after 2 months!) deficient even in development versions... Where are the "Run And Forget" spirit of the old good distributed computing projects like original SETI@home?

[Jason G]

It isn't an option for me, because while i like an idea to share my free CPU/GPU cycles to SETI science, i really hate an idea to constantly do the same with my own free time. I already spend some time to play with CUDA versions and options because it was an interesting innovation, but i grade to get tired from it. The SETI CUDA application was not beta-tested enough from the beginning (maybe nVidia pushed public release before the New Year due to advertising interests?), it is still wery user-annoying when running, and the BOINC user options to manage CUDA work are still (after 2 months!) deficient even in development versions... Where are the "Run And Forget" spirit of the old good distributed computing projects like original SETI@home?

Oh all agreed! Having to mess with workarounds and settings and special configs is annoying and error prone.  Hopefully the gradual movement in Boinc code will fix the scheduling issues so that anonymous platform will work 'out of the box' . There seems to be downsides to any particular workaround  approach at the moment, which I hope will be resolved.  We shall see.

Jason

[Jason G]

Any Ideas what's stopping this from asking for Cuda work ?

2/24/2009 11:55:25 PM      [wfd] ------- start work fetch state -------
2/24/2009 11:55:25 PM      [wfd] CPU: shortfall 0.00 nidle 0.00 est. delay 376335.23 RS fetchable 100.00 runnable 100.00
2/24/2009 11:55:25 PM   SETI@home   [wfd] CPU: runshare 1.00 debt 0.00 backoff dt 0.00 int 0.00
2/24/2009 11:55:25 PM      [wfd] CUDA: shortfall 371520.00 nidle 1.00 est. delay 0.00 RS fetchable 0.00 runnable 0.00
2/24/2009 11:55:25 PM   SETI@home   [wfd] CUDA: runshare 0.00 debt 0.00 backoff dt 81174.41 int 86400.00
2/24/2009 11:55:25 PM   SETI@home   [wfd] overall_debt 0
2/24/2009 11:55:25 PM      [wfd] ------- end work fetch state -------
2/24/2009 11:55:25 PM      No project chosen for work fetch

Both 6.6.9 & 6.6.10 seem to be doing this for me, and I don't quite know what it means.

[Yellow_Horror]

it no longer deletes the old app, if it is marked with a different plan_class

Is there any clues how to define plan_class for CPU version of Seti MB app?

P.S. I switch to V7 CUDA app to see if the CUDA freezes still persist (to diff-diag the trouble between the new BOINC and the new app).

[Yellow_Horror]

No one freeze with V7 until now. Think, the V9 app from the multi-GPU package is the one thing to blame.

[Raistmer]

No one freeze with V7 until now. Think, the V9 app from the multi-GPU package is the one thing to blame.

Replace DLLs to older versions.

[Yellow_Horror]

Replace DLLs to older versions.

Got a freeze with the same symptoms using MB_6.08_mod_CUDA_V9.exe with old DLLs.

[Jason G]

Yeah.  I've confirmed this behaviour now on my machine also (v9 with old DLL's).  At about 6.4% it decided to spontaneously pause & ran for an hour at full GPU use (by temperature) with no progess, marked as 'Waiting to Run' (Normally finishes <30mins or so).  Increasing ncpus by 1 (&reread config file) started up another astropulse instead    so I reset ncpus, restarted boinc and it resumed normally, but similarly stuck on the next task.   No obvious complaints in stderr, and angle ranges were both ~0.44.

I've switched back to v7vlarkill to check everything else is OK, and all is running normally, (2xAPs + 1xCuda, with Maik's script monitoring the show (modified to restart boinc in case of stuck WU., instead of terminating the process)

Important note: I am using a development Boinc 6.6.9 at this time (after getting the same response from 6.6.10), which I had 'work_fetch_debug' turned on and I believe some mechanism in these new versions may be causing the waiting.  I get the impression it may be some 'twiddling' of the scheduling operations going on behind the scenes interacting with the app trying to get things 'right' for the normal user, but don't know for sure, partly as I don't know what some of the more detailed log messages mean.

Jason

[Raistmer]

Yeah.  I've confirmed this behaviour now on my machine also (v9 with old DLL's).  At about 6.4% it decided to spontaneously pause & ran for an hour at full GPU use (by temperature) with no progess, marked as 'Waiting to Run' (Normally finishes <30mins or so).  Increasing ncpus by 1 (&reread config file) started up another astropulse instead    so I reset ncpus, restarted boinc and it resumed normally, but similarly stuck on the next task.   No obvious complaints in stderr, and angle ranges were both ~0.44.

Waiting to run - it's BOINC mark. App refused to wait and continue crunching. Pity that you didn't look at state.sah for that task - did it progress or not...