hi there!

i have set up a small machine to test gpu-computing. it's based on a slow sempron processor and old power-saving mainboard and has nothing more to do than keeping the G92 running.

unfortunately the used sempron has one core only and so this machine can't hold more than one WU. this sucks because if you have to upload a 28 megabyte result file the G92 is sleeping for some 30 minutes. buffering work for the case that your projekt sometimes may be down for maintenance is also impossible.

why is there a one-wu-per-cpu limit and why is it there when CPUs have nothing to do with GPUs. when i use two or more GPUs in one machine, a single-core-prozessor should always be strong enough to support at least two GPUs... so a per-cpu-limit of 1 makes no sense for me. in my opinion such a low limit should be GPU-based (not CPU) and set at least one more than the number of GPUs in the system.

greetings from berlin, germany.

a per-cpu-limit of 1 makes no sense for me

The project agrees but so far has not been able to tell the BOINC server software about this.

MrS

can't they set a per-cpu-limit of at least two WUs?

this won't fill the need for SLI-powered machines but should help a little. i'm planning to build a crunching machine using two G92 cards, but i don't want to spend a quad-core processor if the CPU load is nearly zero. such a machine will need three or four workunits to run uninterrupted even when uploading these huge result files (i had a over-50-meg-file Oo, if files this big are normal it needs some time to upload).

my suggestion is a try using a per-cpu-limit of two and a longer delay between scheduler requests when the client is not getting new work (because the limit has been reached). this delay is very short at this time, resulting in a high number of unnecessary scheduler requests and server/bandwith load.

Paul, would you like to suggest this to the alpha mailing list? :)

maybe someone has an phenom or intel quad for me... not really nice to keep such options "set-by-hardware", especially non-GPU-related hardware. what if someone has a GX2 graphics card and a single-core processor? don't know if yours can do, but many projects are using per-host limits. can't you set a per-host-limit of approx. 4-6 WUs? this should be enough (and not too much) for every machine except "over-the-top" machines running something like four GX2 cards...

rectilinear crossing numbers is using a per-host-limit for example.

unfortunaly one of your WUs crashed last night on my G92-test-machine while it wasn't connected to the internet. the GPU then did sleep until morning like all normal GPUkind because this machine can't maintain more than one WU... very *beep* if you wish to keep this thing crunching... would never had that sleep when a secound workunit had been waiting... :-)

don't have any further suggestions at this time. i'm writing my own boinc server for a project and this can handle timeout-after-limit settings even by now. when it's done maybe it can handle a small set of work-limit-settings for every single host which needs them (have to test how much server load can be used for such features). but it's (like almost every project) cpu-related, making work scheduling easier (until the boinc framework is GPU-ready).

I think they're wasting their time trying to debug 6.6.x. The system is fundamentally flawed, they need a clean differentiation between different co-processors. Otherwise all they can do is trying to catch strange errors which are "impossible". But whom am I telling that ;)

Well, factor the "1.0 CUDA, 0.03 CPU" in. Ignore the 0.x CPU regarding ressource share. In a project mixes tasks with high and low cpu usage it will be difficult to maintain the correct cache size.. but the current system would have no way of dealing with such a situation, either.

I understand the entire scheduling / ressource allocation / work fetch is much more complex. Still I'm convinced: it's better to build a complex structure on a solid foundation than trying to build it on something you already know is not adequate. It may seem like a pain to set up, but in the end may save you even more in debug time.