Can't get CPU work

[Purple Rabbit]

Poor  (Host Potato) has a problem. He has been crunching right along, but I recently changed to BOINC 6.6 28 and the beta installer.  He's still crunching, but I can't get the short term debt to to stop increasing for GPU only or (in a another trial) to get the CPU to take over when the short term debt debt (it got over over 33,000 several times so far with no luck) might require it. I've been suspending the task to fix the the short term debt. I changed the SETI preferences to allow both CPU and GPU processing.

I originally set him up as a GPU only client with stock stuff. I then added the Beta installer. I've screwed up somewhere. I think I need help (or at least  therapy)   

I think I've read all the posts, but a relevant RTFM reference is appropriate .  I'm at a loss to explain this. I've done what I can.

Rick

[sunu]

What CPU work do you want to run? Astropulse, multibeam, both? Have you checked the corresponding boxes in the beta installer?

Seti has run out of astropulse wus, so you're not going to get these for some time.

Please read carefully these:
First post from raistmer here especially where he says "What should not be used".
First post from Jason G here, it's a small readme on the beta installer.

If you want to zero your debt, close all boinc and client apps and open your client_state.xml and client_state_prev.xml files found in your boinc directory with a text editor. Then make a search in these files for the word debt and change the corresponding values to 0.000000.

It would also help if you post your app_info.xml file here.

[Purple Rabbit]

Thanks sunu,

I'm just running multibeam (with other BOINC projects). Both the AK_vb8_win_SSSE3 and MB_608_mod_CUDA_V11_VLAR_refined were installed by the beta installer. The processor is a Q6600 and has run SSSE3 successfully before.

I've zeroed the debt a number of times. I've got the LTD stable at 0 (or close to it), but the STD continues to grow very large just running CUDA. I thought running some CPU units would knock that back some, but it never switched. I have checked (and checked) the preferences on the site and they seem to be correct.

I had been running v10_team for both CUDA and CPU under BOINC 6.4.6. These worked fine within their limitations. I can't get to the Jason G link (access denied). I do remember an admonition to get everything working with stock first. I didn't do that for the CPU. I'll go back to stock for everything (after I get through my current tasks) and try that next.

app_info.xml:

<app_info>
    <app>
        <name>setiathome_enhanced</name>
    </app>
    <file_info>
        <name>AK_v8b_win_SSSE3x.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>528</version_num>
        <file_ref>
            <file_name>AK_v8b_win_SSSE3x.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>603</version_num>
        <file_ref>
           <file_name>AK_v8b_win_SSSE3x.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
 
    <app>
        <name>setiathome_enhanced</name>
    </app>
    <file_info>
        <name>MB_6.08_mod_CUDA_V11_VLARKill_refined.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>

    <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_V11_VLARKill_refined.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>

[Jason G]

Hi there,
   app_info looks fine, as the bog standard generated one from beta should, now some ~730 downloads. 

I tend to stick to a single project these days, most of the time, so don't know the ins & outs of debt calculation.  I would expect it to be primarily related to Boinc internal calculations and resource shares, than anything to do with applications themselves (or app_infos).   I can imagine, though, that if the GPU is happily munching through Multibeam WU's, and these count toward Seti's resource share as they should, then if no other GPU enabled project is attached, then Seti work would tend to GPU, and other projects to CPU. 

I can imagine (guess at) three possible situations though, that might be induced by new boinc version changes combined with specific resource shares & project combinations:
1)  (Unlikely)  If the ratio of performance between the GPU(s) against combined CPUs (and associated applications for each), is roughly equivalent to the resource share per project allocations, then Boinc, since it asks for GPU work first, might be satisfying the seti share, leaving the CPU dry of that, and no debt would accumulate, everyone's happy, but no cpu work for seti.

2) (Could happen) If, looking at another angle, the CPU performance outstripped the GPU, then other projects would quickly consume their resource share and request Seti@home CPU (specific) work. 

3) (Likely?) The third scenario I can picture, which I think might be applicable here, is that GPU performance on seti is outstripping CPU performance, thus exceeding resource share by virtue of having no work from other gpu enabled projects. (And not requesting Seti@home CPU work accordingly)

If #3 'feels' the most likely situation, then a couple of  simple resolutions may be possible.  Either Increase seti's resource share to compensate for its performance boost obtained from its sole GPU ownership,  Or alternatively attach to another  project that has suitable GPU apps to help balance the debts out.


No idea if that will help, but a fun mental exercise. A simple test may be to temporarily set that machine to crunch only Seti, And see what happens.  If things settle and start requesting both GPU & CPU work, then IMO it's an indicator of lack of GPU apps for other projects, and suitable resource share adjustment, since Boinc will always try to keep the GPU busy, with whatever it can get .... Even if it's only one project that has already consumed resource share, so won't request cpu work.

Good luck with that, and I hope you get it sorted.

Jason

[Purple Rabbit]

Thanks a bunch Jason. #3 seems to apply. The GPU (8600GTS) tasks take about 40 to 60 minutes. CPU tasks were taking a bit over an hour (70 to 90 minutes). I've been reducing the SETI share to fix the problem. I'll try increasing them (I'll try anything!)

This still begs the question of running SETI GPU only without CPU tasks. (OK, I'm changing the question...sigh). I'm guessing this is a BOINC 6.6.xx question. I'll be happy with anything that I don't have to nursemaid tho 

I'll be back 

[Jason G]

This still begs the question of running SETI GPU only without CPU tasks. (OK, I'm changing the question...sigh). I'm guessing this is a BOINC 6.6.xx question. I'll be happy with anything that I don't have to nursemaid tho 

That one's simple then  , Boinc would always keep the GPU busy with seti@home work, and the other projects accumulate debt (unless they had GPU apps too) (Unless they've managed to jimmy in some resource share compensation, which I doubt)

This issue is properly called load balancing in parallel terminology, which is a huge area of research in itself. IMO to keep resource share balanced across all projects, would require heterogeneous compute nodes (A single integrated system made of different parts, they're currently treated independently and don't work cooperatively), using graph colouring algorithms for scheduling (Otherwise known as Richard's back of the envelope calculations  )

Since the applications & hardware involved are not heterogeneous , then there are tradeoffs and workarounds needed.  We can do that so some extent manually, by carefully choosing the project combination and resource shares to be compatible with available resources.  (Doing what Boinc should be doing  )

Jason

[Purple Rabbit]

Ah, but my problem (originally before sub-problems 1 and 2!) was that the STD kept increasing forever with only SETI GPU work. This  affected the other projects STD.

You've been very helpful (I think, it'll take a bit of time to know for sure  ). I'll settle for any stable solution and you have given me a clue to something 

Again, thanks a bunch.

EDIT: You eloquently added more info. I need to go ponder now . I'm an engineer and not a programmer so please forgive me

EDIT2: Crap! You keep giving me more good stuff--Stop it  I think you're saying that BOINC is as BOINC does. I can Grok that!

[Jason G]

No worries Purple Rabbit.  If you can get a handle on the real circumstances that would be good, as we like nothing better than throwing fixes to Boinc developers they don't understand    I'm both computer scientist and Electronic Engineer, (I.e. completely mad) and can completely relate to not being able to understand things that don't work properly or make sense 

[Purple Rabbit]

Real circumstances? I was giving "fake" circumstances? OK, I'm pulling your leg  All I said was what I tried. I guess I may have compressed it a little (perhaps to incomprehensibility?).

I never understood computer scientists, but if you're also an engineer I guess you're OK. Some of my best friends are computer scientists 

I'll report back on my successes and failures. What else should I report (if anything)?

Rick

[Jason G]

LoL.  Real circumstances on what Boinc is doing, because none of us really have any idea 

[Jason G]

Now, it seems the powers that be have promoted you, and that you should now be able to visit the beta threads (Now that we know It's all Boinc's fault )

[Purple Rabbit]

Woo Hoo!

Oops! (collecting himself for proper presentation)

I mean thanks. I can indeed acquire previously forbidden knowledge and will use it for the benefit of the project. I hope that I can be worthy of this honor.

Rick

[Purple Rabbit]

It's been almost a month since my last post and I promised to get back with you. I'm still not able to balance the CPU/GPU load within BOINC 6.6.28...sigh. I've tried 6.6.36--Gag! It's even worse than before with the other projects. Maybe I didn't have enough patience? I figured a week would be enough. I'm back to BOINC 6.6.28 (although perhaps not back far enough?)

The Raimaster/Marius scripts have helped a lot, but they still require babysitting. Marius 1.2 still works the best for me, but I'm manually running Marius 1.6 at the moment on a Q6600 with an 8600GTS on Win Vista. As I said before the GPU card is slow (a bit faster than the CPU tho-I consider it an extra processor), but geez, BOINC should know better...sigh.

My "experiment"  allowed the STD to get above 50,000 several times. This didn't get me very many (I got one or two) CPU units. At these points I lost patience with BOINC and used the script. 

My current  procedure  when I get up in the morning is to check the STD. If it's humongous (like over 20,000), then suspend the SETI task. SETI STD goes to zero. I then run the script (whatever version I think is best at the time), watch to see if there are changes (sometimes not, so try again with different settings),  and resume.

I'm not asking for help anymore. BOINC is as BOINC does...sigh.  Any miraculous solutions would be appreciated, however

Rick

[Richard Haselgrove]

During a recent SETI outage, I joined another project (AQUA) to get CUDA work (and only CUDA work - I explicitly rejected CPU work).

Everything is running fine. CUDA tasks are running FIFO as expected (v6.6.36), CPU tasks are swapping around under Resource Share control. Only thing is, the CUDA-only project has jumped up to STD 77,919, and the CPU tasks are nudging each other up and down around a median of -25,000 ish. Doesn't matter, it all works, but it looks a bit ugly.

Since the CUDA apps don't seems to respect resource share, but it does affect debt, I've now set AQUA to a RS of 1 (others are 100/200/300). Debt seems to be heading back towards neutrality - slowly, but I can wait, since it makes no difference anyway.

[Purple Rabbit]

Hmmm, that's a thought. I've been running SETI (my only GPU project) with a various  resource of between 10 and 35 on this computer (the other projects (7 of them) are 25, my standard share).

All this started when I wanted to only run a GPU SETI on this computer . The STD got out of hand for SETI and affected the other projects. I never tried 1.  VLAR/VHAR kind of complicates matters for SETI, but I really don't mind killing a few tasks as long as there aren't not to many of them (unfortunately I've had a bunch recently...sigh)

My other problem would be as the time to completion approaches 3 minutes (CPU time for the GPU-normally 40 to 50 minutes wall clock time for the GPU and 75 to 90 minutes wall clock time for the CPU) I tend to get a tremendous number of tasks running the GPU only...sigh. It looks like I have to run a CPU task at least occasionally to keep the number up.  Again, this requires baby sitting the tasks.