Since there are gpu apps for everything, why does bonic request work for cpu and gpu individually amymor? let the client distribute the work as needed.

I have a old rig with four logical cpu's and two gpu's, when crunching astropulse no cpu work is done because each AP work unit needs a whole CPU thread. I end up having to abort cpu work to keep the gpu's working, the cpu work eventually starts to go critical and the gpu's will sit idle.

---

Since there are gpu apps for everything, why does bonic request work for cpu and gpu individually amymor? let the client distribute the work as needed.

I have a old rig with four logical cpu's and two gpu's, when crunching astropulse no cpu work is done because each AP work unit needs a whole CPU thread. I end up having to abort cpu work to keep the gpu's working, the cpu work eventually starts to go critical and the gpu's will sit idle.

[Edit:] did you try increasing the ncpus fields for the GPU AP app already? will that accomplish what you need ?

While there are a lot of Boinc design issues preventing moving tasks around, i.e. moving tasks where they'll best run out of the way of one another automatically, mostly client and server estimate related, I am planning to embed this capability within x42 as a testbed for some further technologies.

Failing the ncpus edits:
Technically (the adapting to task and hardware needs part) is called 'dynamic heterogeneous capability', and will eventually involve a lot of optional configuration to suit your needs, along with special tools to work out what runs best where, as well as special pipelining and multithreading modes later on.

In the medium term, that's going to require a fair amount of telling the server and client what they expect to hear, since I see no plans to support multi-threading properly, nor any kindof dynamic resource management, planned in Boinc documentation.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

OP only crunch GPU work, CPU isn't worth it for most setups. As you know AP GPU WU need a lot of CPU.

---

what is the best way to block cpu work?

jason, i'm not say most efficiently, just download the work let the client assign to gpu or cpu. like you could do with boinc reschedule...

---

Why not just assign it a separate Preference Location (work, school, home) and disable CPU work through http://setiathome.berkeley.edu/prefs.php?subset=project?

Cheers.

jason, i'm not say most efficiently, just download the work let the client assign to gpu or cpu. like you could do with boinc reschedule...

Yeah. When I polled the GPU Users group members some time back, looking for issues to address for x42's design, It was a slow start with few issues raised directly for x41zc Cuda as it stood. Once I clarified that I'm looking for *any* issues, like a wishlist, the floodgates opened, mostly with requests for more flexibility in how Tasks get managed and processed etc. That includes dynamic allocation, such as rescheduling 'on the fly' etc.

While efficiency was certainly always considered important on all sides (though perhaps in different ways), it became apparent that what was more sought after is (much) more flexibility, and adaptability to different situations, than Boinc allows in current form.

So that's where x42's headed in the medium term, initially adding some CPU/multithreading, optional configuration, monitoring and management, support for other than Cuda only, as well as later AP, and local dynamic clustering in preparation for the possibly huge GBT data & applications that may come.

There are a number of Boinc server and client design issues, that are blocking simple rescheduling type behaviour, that are also blocking a number of other development streams.

Fortunately unravelling intertwined CreditNew and BoincApi issues has provided some direction and useful insights, whether or not those eventually get addressed by Boinc. It'll be quite possible to pull some of the technologies forward, while leaving Boinc broken and working around it if necessary.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Jason, Thanks for such a great overview of the direction the project is moving. If not for you and the others we see every day in this forum, we'd be totally in the dark. Great job!

John

---