..... I have a couple showing version 6.61.

Ok, shall I kill my 2 "old" WUs in the queue?

.... Hmm - just watching my first 6.61 WU going thru - it is making more use of the CPU than the 6.55 WUs. About a 10% uplift.

P.

.... Hmm - just watching my first 6.61 WU going thru - it is making more use of the CPU than the 6.55 WUs. About a 10% uplift.

P.

Do you think the overall duration will be shorter?

The higher priority -> higher cpu usage should result in better GPU utilization, which would mean slightly shorter calculation times, especially with 2+1 / 4+1 on a dual or quad core, respectively. Is anyone already seeing higher GPU temps? I'm still working through my 6.55s.. or am letting my GPU do the dirty work for me ;)

MrS

---

Scanning for our furry friends since Jan 2002

The higher priority -> higher cpu usage should result in better GPU utilization, which would mean slightly shorter calculation times, especially with 2+1 / 4+1 on a dual or quad core, respectively. Is anyone already seeing higher GPU temps? I'm still working through my 6.55s.. or am letting my GPU do the dirty work for me ;)

Me too... I have 6.61 tasks queued but, none in work yet ...

Um, not to be difficult, but the goal for many of us was to REDUCE the CPU usage. With my 280 card I am fine with the processing time, but, am not so fine with the high CPU usage ... especially since it is to the best of my understanding mostly doing a polling loop, which might be necessary, but is hardly productive use of the CPU. Increasing the priority of the task and wasting more CPU time polling seems to me to be a step backwards.

It does help GPU Grid slightly, but at the cost of every other BOINC project I am running (or will be running) alongside the GPU tasks.

While on the subject. It occurs to me that the architecture of the GPU Grid application is not correct. There should be one polling thread that then dispatches to the service threads as needed. What I mean is this, if I have a 2 or more GPU system you will launch (based on earlier observations) two application instances both of which poll their individual GPU ... In that this is not really productive use of the CPU when I have two tasks doing nothing it gets ugly and when I have more than that it is REALLY bad.

With the dispatch scheme, the one thread is in the polling loop and it polls the GPUs one after the other checking to see if the GPU needs grooming, and if so, should wake the service thread to service the GPU ... less overhead in that only one thread is in idle poll mode ...

While on the subject, I have 1G cards for the most part and the memory load seems to run about 50% ... again, is is possible that this could be tailored to available memory so that those with more than 512M would have larger loads and thus lesser demands for re-fills?

These musing are from when I had two GPUs in the i7 system and there was so much usage of the CPU that the i7 was running in essentially 7 + 2 mode though it was trying to run as 8 + 2 ... I know GPU Grid wants to maximize the productivity for this project, but it should not do it at the expense of the other BOINC projects ... I am not sure what the CPU load is for SETI@Home (anyone out there running both projects?) but if it is minimal, perhaps we need to collaborate with them?

---

6.61 (CUDA) app uses 40% of my CPU (dualcore, so 80% of a single core) - even worse than 6.55!! We had a version with acceptable CPU usage (6.56), release that via app_info.xml (as has been requested numerous times). 40% CPU usage is not within an acceptable limit anymore for me, so until that is sorted, I'll only run it on my PS3.

The higher priority -> higher cpu usage should result in better GPU utilization, which would mean slightly shorter calculation times, especially with 2+1 / 4+1 on a dual or quad core, respectively. Is anyone already seeing higher GPU temps? I'm still working through my 6.55s.. or am letting my GPU do the dirty work for me ;)

MrS

More thoughts ...

I think I agree with Digi421 ... 6.55 was high on CPU, the next release lowered CPU usage and now we look like we are going to see a substantial increase ... though I am still doing my 6.55 tasks ...

Next question is why are we polling and not using the IRQ? If we used IRQ when the GPU was in need there would be no need for an idle poll loop.

Suggestion: An option to select "nice" or GPU performance.

I posted this on BOINC Dev:

There is a little bit of a conundrum going on and I thought I would post the question here ...

The "ideal" situation with BOINC running tasks on the GPU is that the actual CPU load would be negligible. GPU Grid seems to be having issues with application versions where the CPU load fluctuates as they make point releases. For those dedicated to the single GPU only project the CPU load is not an issue. For those with mixed loads the impact on CPU class projects may be less than desirable if the CPU load imposed by GPU tasks is too high.

For example, I had two GPUs in my i7 box and with BOINC Manager 6.5.0 I was running 8 + 2 as expected, well, not quite, the 8th CPU task got 0 CPU because the two GPU tasks took up too much CPU time.

My first question is why do we need to use a polling loop instead of an IRQ?

Second question, if we HAVE to use a polling loop why are we not using a single poll loop to query all GPUs and then dispatch to support threads to service those GPUs in need of grooming?

Third, why can we not have an option in BOINC Manager to select "Nice" vs. GPU Performance? In "Nice" the stress would be to use the GPU but not at the expense of huge overhead of a polling loop that is doing essentially no useful work with the tradeoff that the GPU will sometimes be idle while waiting for service. This has the added advantage for those with stressed systems that the GPU would have time to "cool" while waiting for servicing. In performance, the GPU poll loop would be higher priority and the emphasis would be on keeping the GPU at 100% usage ... Default in BOINC Manager would be "Nice" (as in GPU projects play nice with CPU projects).

I have not yet done a comparison test with SETI@Home to see what the usage is, but, at GPU Grid while running their application 6.55 my CPU usage is:

Q9300, 4 cores, single GPU, 5-11%
i7, 4 cores, HT, 8 VIrtual CPUs, 3-6%

Another participant reports: "6.61 (CUDA) app uses 40% of my CPU (dualcore, so 80% of a single core)"

Though GPU processing can be faster, when you factor in the overhead of also consuming the CPU resources at the same time it may not be such a bargain.

---

I am currently crunching two 6.61 WU's, and they are using 20% and 23% of a cpu core on my quad. That equates to 80-92% of a single core each, as opposed to the 6.55 WU's that were anywhere from 40%-80% of a single core. So, from my experience the cpu-usage in the best case of 6.61 is about the worst case for 6.55.

I'll have to check the run times, credits / hr, etc. to determine what to make of it.

6.61 (CUDA) app uses 40% of my CPU (dualcore, so 80% of a single core) - even worse than 6.55!!

Indeed...
Just started my first 6.61 WU and am bitterly disappointed.
My system (AMD X2 5200 and 9600GT) uses almost a complete core (about 90%!)for crunching on the GPUGrid task and becomes even more sluggish than before. :-(
I think I stop crunching here 'til a new version comes out, it's not worth it.

---

Member of BOINC@Heidelberg and ATA!

6.61 (CUDA) app uses 40% of my CPU (dualcore, so 80% of a single core) - even worse than 6.55!!

Indeed...
Just started my first 6.61 WU and am bitterly disappointed.
My system (AMD X2 5200 and 9600GT) uses almost a complete core (about 90%!)for crunching on the GPUGrid task and becomes even more sluggish than before. :-(
I think I stop crunching here 'til a new version comes out, it's not worth it.

Yes, this way goes in the wrong direction, we need an app thats using only a little bit of a cpu core.

Yes, this way goes in the wrong direction, we need an app thats using only a little bit of a cpu core.

Actually we need the choice ... I prefer to run a mix of CPU / GPU tasks with the emphasis on CPU tasks as that is my current weight ... but some that are GPU Grid exclusive may want to have this mode of operation that gets the most out of the GPU card. I can make an argument for either direction which is why there should be the option.

Personally I would give up GPU performance for less load on the CPU ... a real elegant solution would actually have three or four levels of performance ... anyway, though it is early days I still see lots of room for improvement and I think I need to make some tests with SaH's application to see how theirs loads the system ... with the thought of course, if they can have a light load, why cannot we have the same here?

The answer is likely to be "because" ... but ... this is one reason why I can hardly wait for other projects to start to provide GPU applications so we can start to have some CHOICE ... and vote with our feet ... of course, I have yet to see a project that really takes the desires of participants to heart ... I mean I asked CPDN to have an option to only DL one task per computer so I would not have the things hanging around for years ... their answer was to abort them ... sigh ... waste ...

---

Oops. GDF - it looks like we need 6.55 back or preferably 6.56 - or even 6.next if you can fix 6.56 for all....

I'm looking for the GPU task to use less than 50% of a CPU so that I can run 3+2 on my box.

Just noticed a new app (6.59) running on my Linux install. That has also increased CPU usage, from ~10-12% CPU, to ~50%. Does this mean that I'm going to have to go back to running GPU 3 + 1, even on Linux? Ah well, I may as well go back to Windoze...at least I know what I'm doing there.

I have checked my latest result with 6.61 and there is no speed increase, one bad issue is that the system getting sluggerish.

New Linux App (6.59)
On Q6600 ~3GHz with GTX280 Gpu, cpu usage reach 12% (9% with Linux app version 6.58).
On Celeron 420 ~1,6 GHz with 8800GTS512 Gpu, cpu usage go to 32%.

These figures aren't very good especially for my low end computer.

As said in this thread the Windows low cpu version will come in a few days.
For Linux there should be no changes at all.

gdf

...
For Linux there should be no changes at all.

gdf

Actually the change with the Linux CPU usage started with the new WU types...
Some of them need more CPU than the old GPUTEST WUs, and some less or the same as the GPUTEST ones.

---

pixelicious.at - my little photoblog

As said in this thread the Windows low cpu version will come in a few days.
For Linux there should be no changes at all.

gdf

Well, the change caught us off guard and I missed the note that we would get a high CPU usage version to test the changes on all systems (though it seems that there are still problems with 64-Bit windows XP at least, see PoorBoy's other thread).

Going WAYYYYY back I did find the little teensy tiny note you wrote ...

When ETA announced with glee the high CPU use version, well, the glee seemed to be for the wrong reason ... or at least it struck me as such. I want to support GPU Grid, but not at the cost of one CPU per GPU ... that said, did you see my other questions below?

I am running my first 6.61 version tasks (on the i7) and the CPU use is up, not as bad as I feared, though up from 3-6% to solid 6 with occasional 7% load.

I have a 295 card arriving tomorrow and I was going to try it in a Linux box that I started up for some other reasons to see what the load is there ... (if I can get it to work at all, as someone else mentioned, my linux skills are, ahem, sub-par) ...

---

On a GTX280 in 3+1 I get this times for a 6.61 WU with 2478 credits in relation to a 6.55 WU with 2435 credits

6.61 # Approximate elapsed time for entire WU: 22036.278 s
6.55 # Approximate elapsed time for entire WU: 19793.840 s

From this point of view there is no advantage for the 6.61.

---

On a GTX280 in 3+1 I get this times for a 6.61 WU with 2478 credits in relation to a 6.55 WU with 2435 credits

6.61 # Approximate elapsed time for entire WU: 22036.278 s
6.55 # Approximate elapsed time for entire WU: 19793.840 s

From this point of view there is no advantage for the 6.61.

ON my first task completed with 6.61 I have similar results ...

{edit - add}
CPU usage on the Q9300 has doubled.

Now it takes almost the full core. An interesting question... does CUDA work best on systems using HT because the CPU core can make more rational decisions on use of the CPU's capacities?

On the Q9300 of course, there is no HT so it is more all or nothing on the use of the core on the chip ...

Not sure what to make of this yet ... but it is an interesting side note...

I am still curious as to the load that exists on Linux with a 695 card with two GPU cores ... on the i7 it would take a full core to support the two GPU cores with the current application. The older application there would have been at least a few percentage "free" that another task could still run.

---