Excellent news. That should blow the cobwebs off the server :)

What effect will this have on card temperatures?

Sounds good. Is this 60% improvement estimate an average across numerous card types, or should only a subset of users experience this?

Just for those interested, can you give some detailed on what are the changes -- how you got this improvement, did you take advantage of cuda differently, etc.

I hope it will be a fantastic step to reduce CPU occupation.
I am ready to test it on my Linux computers.

How can recognise if its one of the new units when its downloaded?

And yes will it support GTX260-192 65nm GPUs? I have these sat idle these days when they could be useful so it would be great if they will work.
____________

From what was said in other threads,
It will be about 60% better for Compute Capable 1.3 and slightly lower for CC1.1.

I would expect some rise in temperatures for many cards, so keep an eye on that.

Interesting. Thanks for the information.

Hi,

We've improved the application by making several algorithmic and implemention changes, which the effect that it now requires less computation to calculate the same results as before. Just to clarify GDF's statement about the performance: the new app will complete WUs in ~60% the time of the current version.

I'd expect the overall GPU utilisation to remain around the same level as before, maybe a little higher (though I don't know exactly what GPU-Z is measuring to derive that figure). Similarly, I'd not expect any significant change to GPU operating temperatures with the new app.

The difference between 1.1 and 1.3, incidentally, is not an issue of floating point precision (we hardly use d.p. at all) but rather one of compiler efficieny. When we compile for 1.1 -- which is necessary for producing a binary that will run on both G80 and G200 hardware -- the compiler produces slightly less efficient code than if it is targetting 1.3, persumably as there are some G200-specific optimisations it is unable to apply.

Lastly a word about the FFT bug on the 260s: For now we are still using CuFFT but, because of the extensive changes we've made to the code which uses the FFTs, it may be that the problem will no longer occur. Unfortunately we won't know for sure until we have some beta WUs out because we don't have the equipment to reproduce the bug in our lab.

Matt

I thought CC1.0 applied to the now obsolete G80, CC1.1 is G92, 1.3 is G200, and the CC1.2 cards use G215 and G216 cores

Hi, i have nvidia 9800gt 512mb, will it be able to crunch new wu?
(is it cc1.1, cc1.3...?).

One more question: in "Maximum CPU % for graphics 0 ... 100", which parameter i should write? And what does it change by changing this %, in computing the wu?

thank you

One more question: in "Maximum CPU % for graphics 0 ... 100", which parameter i should write? And what does it change by changing this %, in computing the wu?

Does that mean the Windows version now works well?

L15-TONI_TEST2901-0-10-RND2988 (state: In progress)

i7-860 / GTX295 / Vista 64



Elapsed Time (wall clock time: 3:43:58)

CPU Time: 3:42:32 !

CPU Eff.: 99,365% !



EDIT: completed

L15-TONI_TEST2901-0-10-RND2988_0
Workunit 1127719
Created 29 Jan 2010 16:04:07 UTC
Sent 29 Jan 2010 16:08:46 UTC
Received 29 Jan 2010 21:32:36 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 53295
Report deadline 3 Feb 2010 16:08:46 UTC
Run time 16040.183401
CPU time 15938.39
stderr out

<core_client_version>6.10.17</core_client_version>
<![CDATA[
<stderr_txt>
# There are 2 devices supporting CUDA
# Device 0: "GeForce GTX 295"
# Clock rate: 1.51 GHz
# Total amount of global memory: 939524096 bytes
# Number of multiprocessors: 30
# Number of cores: 240
# Device 1: "GeForce GTX 295"
# Clock rate: 1.51 GHz
# Total amount of global memory: 939524096 bytes
# Number of multiprocessors: 30
# Number of cores: 240
MDIO ERROR: cannot open file "restart.coor"
# Time per step: 25.659 ms
# Approximate elapsed time for entire WU: 16036.845 s
called boinc_finish

</stderr_txt>
]]>

Validate state Valid
Claimed credit 4503.73958333333
Granted credit 6080.0484375
application version ACEMD beta version v6.05 (cuda)

gtx260 OC 696/1500/999 Boinc 6:10:25 XP64

All four Bxx - TONI units completed successfully after only two minutes.
One Lxx - TONI unit has just finished normally after only 4h:18m. Excellent performance increase.
Temperatures look normal, however the cpu utilisation of 100% is going to be an issue for me and others running cpu projects alongside GPUgrid.

I have two of these WU's running on my Windows 7 64 bit Pro', i7 920 with two GTX260 (216 core 55nm) GPU's. After they were about 66% completed I noticed that they were each using 100% of one of the eight multi-threaded cores. I closed down Boinc manager and switched off multithreading. On restarting Boinc manager, each WU was now running 100% of one of the four,non multithreaded cores. The elapsed timer on Boinc manager started again at the point at which it had previously stopped (3.5 hours). The time to completion looks to be about the same as when previously using hyperthreading (approximately 5 hours). I will forward details when completed.

The result of one of the WU's which completed after approximately five hours and seven minutes. The other is similar. Temperatures normal.

Name L18-TONI_TEST2901-0-10-RND0675_0
Workunit 1127722
Created 29 Jan 2010 16:04:17 UTC
Sent 29 Jan 2010 20:14:35 UTC
Received 30 Jan 2010 1:47:32 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 55059
Report deadline 3 Feb 2010 20:14:35 UTC
Run time 18451.701774
CPU time 18065.93
stderr out <core_client_version>6.10.25</core_client_version>
<![CDATA[
<stderr_txt>
# There are 2 devices supporting CUDA
# Device 0: "GeForce GTX 260"
# Clock rate: 1.47 GHz
# Total amount of global memory: 939524096 bytes
# Number of multiprocessors: 27
# Number of cores: 216
# Device 1: "GeForce GTX 260"
# Clock rate: 1.47 GHz
# Total amount of global memory: 939524096 bytes
# Number of multiprocessors: 27
# Number of cores: 216
MDIO ERROR: cannot open file "restart.coor"
# There are 2 devices supporting CUDA
# Device 0: "GeForce GTX 260"
# Clock rate: 1.47 GHz
# Total amount of global memory: 939524096 bytes
# Number of multiprocessors: 27
# Number of cores: 216
# Device 1: "GeForce GTX 260"
# Clock rate: 1.47 GHz
# Total amount of global memory: 939524096 bytes
# Number of multiprocessors: 27
# Number of cores: 216
called boinc_finish

</stderr_txt>
]]>


Validate state Valid
Claimed credit 4503.73958333333
Granted credit 6080.0484375
application version ACEMD beta version v6.05 (cuda)

--------------------------------------------------------------------------------

GTX285, XP32/ i7-920 HT ON @4.0 GHz.
100% cpu utilization and I did see the estimated 60% runtime improvement.

GTX295 Vista 64 Ultimate/ i7-920 HT OFF @ 4.4 GHz.

On my 295 when I did not suspend other projects to make a full core available for each GPUGrid beta (meaning they had to share) they ran 7.5 hours which is not substantively better than normal, certainly not in the 60% range. I did also get a couple of the real shorties and their CPU utilization was also close to 100%.
It looks like on the i7 there may be an issue with how the processor is handling the instruction set if HT is OFF. Maybe internally the CPU is turning HT on??? Observing task manager if I made sure 2 cores were free then each of the two WUs would use 25% but when I ran 4 CPU WUs from other projects the GPUGrid betas were using 11-13% which is just what a CPU WU looks like when I have HT on. The 7.5 hour runtimes I mentioned above were processed with HT off.


____________
Thanks - Steve

Kaboom, in the middle of the night.

Name L38-TONI_TEST2901-0-10-RND1295_0
Workunit 1127742
Created 29 Jan 2010 16:05:13 UTC
Sent 29 Jan 2010 16:13:31 UTC
Received 30 Jan 2010 12:20:21 UTC
Server state Over
Outcome Client error
Client state Compute error
Exit status 3 (0x3)
Computer ID 6133
Report deadline 3 Feb 2010 16:13:31 UTC
Run time 10312.796875
CPU time 5985.359
stderr out <core_client_version>6.10.17</core_client_version>
<![CDATA[
<message>
The system cannot find the path specified. (0x3) - exit code 3 (0x3)
</message>
<stderr_txt>
# There is 1 device supporting CUDA
# Device 0: "GeForce 8800 GT"
# Clock rate: 1.62 GHz
# Total amount of global memory: 536543232 bytes
# Number of multiprocessors: 14
# Number of cores: 112
MDIO ERROR: cannot open file "restart.coor"
SWAN : FATAL : Failure executing kernel sync [frc_sum_kernel] [700]
Assertion failed: 0, file ../swan/swanlib_nv.cpp, line 203

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

</stderr_txt>
]]>


Validate state Invalid
Claimed credit 4503.73958333333
Granted credit 0
application version ACEMD beta version v6.05 (cuda)

9800 GT, 607MHz/1517MHz/900MHz (512MB) driver: 19062 / QX9650 @3.66GHz / Vista64

B28-TONI_TEST2901-0-5-RND4647_0
Run time 357.2244
CPU time 348.1474
Validate state Valid

B47-TONI_TEST2901-0-5-RND7649_1
Run time 357.2556
CPU time 349.2238
Validate state Valid

B42-TONI_TEST2901-0-5-RND0199_2
Run time 356.179199
CPU time 348.943
Validate state Valid


GTX 295, 701MHz/1509MHz/1086MHz (896MB) driver: 19062 / i7-860 HT @3.8 GHz/ Vista64

L14-TONI_TEST2901-0-10-RND7593_0
Run time 15980.329535
CPU time 15870.54
Validate state Valid

L15-TONI_TEST2901-0-10-RND2988_0
Run time 16040.183401
CPU time 15938.39
Validate state Valid

gtx260 OC 696/1500/999 Boinc 6:10:25 XP64

the cpu utilisation of 100% is going to be an issue for me and others running cpu projects alongside GPUgrid.

GTX 295, 701MHz/1509MHz/1086MHz (896MB) driver: 19062 / i7-860 HT @3.8 GHz/ Vista64

L13-TONI_TEST2901-1-10-RND4450_0

Aborted by myself - Run time 2726: 100% CPU-load, no GPU-utilization shown by GPU-Z, no progress.

(Dump by BOINC Windows Runtime Debugger)

9800GTX Stock no o/c Phenom2 o/c 3.2Ghz 8Gb RAM Vista64

Also running Aqua and Freehal concurrently.

L36_TONI_TEST2901-1-10-RND9113_0

Saw the Beta running, so came back to give it a go, I had been blown away by too many errors on the old apps. Grabbed two about 20 mins ago, early days but the speed is impressive.

CPU utilisation is out of wack as noted by others, its using a complete core on the Phenom2 Quad (Task Manager reports cpu utilisation as "23". That needs addressing as its a showstopper because its draining from cpu based Projects (in my case Aqua - has no effect on Freehal).

It managed to muscle out Aqua from one core - quite a feat as the Aqua app is somewhat territorial grabbing all cores usually kicking off others :) Temps are ok.

If the cpu utilisation is resolved its looking like I'll be back again, which is a relief - I have serious GPUGRID withdrawal symptoms :)

Regards
Zy

Looks like this ACEMD beta 6.05 workunit has a severe underestimate of how much CPU time it uses:

1/30/2010 5:28:36 AM GPUGRID Starting L25-TONI_TEST2901-0-10-RND7574_3
1/30/2010 5:28:36 AM GPUGRID Starting task L25-TONI_TEST2901-0-10-RND7574_3 using acemdbeta version 605

It claims to be using 0.18 CPUs + 1.00 NVIDIA GPUs, but it's actually making full use of the CPU core.

Suspending the workunit, then resuming, does not help.

BOINC 6.10.18
64-bit Windows Vista SP2

Processor: 4 GenuineIntel Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz [Intel64 Family 6 Model 23 Stepping 10]

NVIDIA GPU 0: GeForce 9800 GT (driver version 19038, CUDA version 2030, compute capability 1.1, 1024MB, 336 GFLOPS peak)

L36_TONI_TEST2901-1-10-RND9113_0

Been running for 4hrs 55 mins. The last 50 mins the counter has been at zero.

Abort or keep it going ?

Its on a 9800GTX

Regards
Zy

............ If it is a lot slower what if we also credit for the usage of the CPU? In such case, we would ask for 1 CPU and 1 GPU of course.

I have just uploaded acemdbeta6.06 that should use less CPU as before.
It would be interesting to see how much slower it is.
If it is a lot slower what if we also credit for the usage of the CPU? In such case, we would ask for 1 CPU and 1 GPU of course.

Let me know if there are problems, as I cannot test it from home.

gdf

Anyone done a L36_TONI_TEST2901 app? Mine been running for 7hrs 36mins countdown clock not working, showing 0% for ages - have a feeling its a bust but dont want to sell it short if in fact its likely to run through.

Its running on a 9800GTX

EDIT
Must be a bust - aborted at 8hrs 15mins

Regards
Zy

Just started L42-TONI_TEST2901-3-10-RND1170_0 acemdbeta version 606 on a 9800GTX, it'll run overnight

CPU utilisation is reported as "2" in Task manager - which is fine, so looks like that problem goes away. Too early to say about likely total completion time.

Countdown percentage clock not working

Regards
Zy

All my Beta tests show 0% until they're finished. I'm going through my 4th & 5th ones if I'm not mistaken.
____________

Just had a 6.05 WU that refused to start. Instead the machine downloaded a new WU and left the 6.05 WU sitting "ready to start". I aborted it and it was immediately sent back out as a 6.06 WU. Hopefully 6.06 is better. IMO the old app (6.71) was far preferable to 6.05. The CPU usage really needs to be improved before this gets released. Think what will happen when the beta in it's current form hits a single core machine.

That is quite logical. But some people will value their cpu projects much higher than GPU-Grid and are thus not fine with that sacrifice.

MrS

Let me get this right ... a GIANNI_BIND use to take 8 hours on my GPU and I get 6118 points ... times 3 per day and I get 18354. Now if I throw in a CPU I can run the same WU in 4.8 hours. So that means I can do 5 WUs per day for 30590 points and you guys are bi^&chin about using 1 CPU core to get the additional 12236???
>10000 is too many points for a CPU per day as it is.
While this conversation is important and we need GPUGrid to be clear on what they are doing and how they are determining how many points a WU is worth, unless they are way off the mark then the ony people who are going to leave because they don't think they are getting enough are the point whores ... yes, I said it! And they will leave anyway when it comes time to hop on a project that has crazy points simply to get attention, not because they have a great piece of science or optimized software.
GDF and team ... from my perspective, I really only care that my system remain in some reasonable state of usefulness while running your WUs. If it take 1 GPU + 1 CPU that's OK by me but I think you should use the CPU as a set resource (like Einstein does) instead of stealing cycles from other processes.
____________
Thanks - Steve

Wow, I'm on almost 20 hours with L6-TONI_TEST2901-1-10-RND2222_0 & 18 hours with L13-TONI_TEST2901-1-10-RND4450_1

It's as if it went dormate, b4 BoincTasks activated it.

Is someone being funny?
____________

Mixed results with 6.06. Had two long units complete with the 60% improvement in performance and even less cpu utilisation than a 6.71 unit. Both were awarded 6000 or so points.
However, another 6.06 long unit L37 is performing poorly, as the poster LIVEONC above states. Temperature was as to be expected but it was going to take 21hrs to complete, so I aborted it after 4hrs.
The successful ones were on 260's while the slow one was on a 275, though I doubt that is relevant.

Hi
If you want to run CPU projects then run them.
If you want to run GPU projects then run them.
If runing GPU efficiently involves using 100% CPU then do it.
The projects come first and the points are a separate issue.

GDF ... you and your team are the best !!!
____________
Thanks - Steve

OK, I had this all nice but then lost it all as I had timed out :-(

While my GTX285 only provides a small sample, the differences between runs of the same version were very minor so I think the following may be helpful

This GTX285 normally processes a GIANNI_BIND WU in 21600 seconds.

Version 6.05
(over three WUs with less than .05% between each of them)
runtime was 13172 seconds.

Version 6.06
(over two WUs with less than .07% between each of them)
runtime was 14006 seconds.

The difference between 6.05 and 6.06 was -6% which really is quite minor in comparison to the overall estimate you provided of 60% reduction originally.

To round out the numbers, the average CPU time on the 6.06 was 680 seconds which is about half of what the old v6.71 uses for a GIANNI_BIND. The only similar CPU usage on 6.71 is the KASHIF_HIVPR which on average come in at about 550 seconds of CPU usage.
____________
Thanks - Steve

Any guesstimates available for how long a L42-TONI_TEST2901-3-10-RND1170_0 acemdbeta version 606 on a 9800GTX would run? Its been going for 19hrs 26mins so far

Regards
Zy

ETA ... read up a few posts ... GDF fixed it !!!
CPU usage is back down very low again. While at this moment it appears at the expense of a few percentage points of the overall improvement (so we might be looking at 55% reduction instead of 60%), I think this is excellent news and look forward to seeing 6.06 in production.
____________
Thanks - Steve

Zydor ... I find that the beta is taking about 65% of the time it takes me to process a GIANNI_BIND. Not sure what a 9800 takes but there have not be reports of these betas crashing (in fact they appear to be remarkably stable). I would suggest that if it is version 6.05 that you abort because we have already moved on to 6.06 which uses much less CPU time. If you want the points just let it run.
____________
Thanks - Steve

This one ran for 28 hours on a 8800GT with v6.05, went to 100% and then was back to 17% when I aborted it. CPU time was also > 26 hours:

http://www.gpugrid.net/workunit.php?wuid=1129962

So far haven't had any long v6.06 WUs. As you can see this client was very reliable with the v6.71 client:

http://www.gpugrid.net/results.php?hostid=55324

Could you guys check if 6.06 is slower? For some reason the appox elapsed time does not get printed.

gdf

I have a L7-TONI_TEST WU here. (6.06)
To see after nearly 7 hours no progress bar. Cancel?

GPU: GTX260

Running L42-TONI_TEST2901-3-10-RND1170_0 acemdbeta version 606 on a 9800GTX - no progress bar or % counter. Its up to 19hrs 55mins run time at present.

Four cores loaded with Aqua, and 25 x Freehal WUs also running concurrently.

EDIT:
With the speed improvements, this should have completed by now - Aborted at 20hrs 17mins

One odd thing I have noted is that all WUs irrespective of type, length Beta or current Production are coming at the same predicted time of 03:54:45. The predicted time will vary machine to machine of course - vageries of BOINC - but its strange all GPUGRID WUs irrespective of type have the same initial "time to completion". That time to completion will count down to zero - then show as "---" with the Betas, for the duration of the remaining processing time.

Regards
Zy

You have to compare speed between 6.05 and 6.06 which are all run on a TONI- workunit (there are two types, one short and one long). What I would like to know is the speed on a fully CPU loaded host, with all cores busy.

AS far as I know the progress bar should work. Does it?

gdf

This being confirmed, we will default to 1CPU+1GPU usage.

gdf

If the hit on the GPU app is so high, then it does not make any sense to have less than 0.1 CPU driving the GPU. You might lose up 100% of performance of 256 GPU cores to save 1 CPU core!
We might go to 0.6 CPU so that two GPUs can share the same CPU. This should be enough and more similar to the reality of the usage. As a matter of fact, many of our calculations do use some CPU anyway for calculations.
Comments?

gdf

I think that we have a big hit on the previous application as well.
We just did not realize it because on Linux is fine and it's fine on windows if the processor is not fully subscribed.

gdf

On a long term prognosis I would agree re 6 cores etc etc - however the transition to multi core niavana has a bear trap.

There are still vast numbers of single core crunchers, they are diminishing quickly of course as machines are replaced, and they cant run the newer cards anyway. However, they are there in large numbers out in BOINC Land, it would be a bad move to cut them off totally, much better in a reputation sense to let them wither on the vine.

Dual Core will be with us in large numbers for years, cutting off one of two cpus would be a bad move.

Aqua debated this recently, and decided that the heavyweight Apps (and there are some real real heavyweight ones there due to the guargantuan amount of data being crunched simulating parts of Quantum Computers) would be restricted to Quad Core only. In fact it was only recently they introduced a light weight App supporting the main app, that they opened the smaller apps to single core.

It was done via Preferences, and in that maybe a way forward here ? The lower gpu useage (say 0.6) could be via one app with an attendent estimate of time to crunch, and second or more app(s) could be there using one cpu and one gpu. Place a test on the faster app to allow access to Dual and Quad core only, and denying download to single core. That way the Dual Core user decides whats right for them, and still leaves the door open for single core/single gpu without arguments spinning round for years.

That will all depend on how the app is put together and how CPU access is granted in the code, obviously I dont know how easy or hard it will be to make such changes without complete rewrites, but I would have thought it would not be too hard to produce two versions around such a premis.

Regards
Zy

There's lots of speculation and AFAIK few machines that have run many v6.05 & v6.06 WUs. Well here's one:

http://www.gpugrid.net/results.php?hostid=56900&offset=0&show_names=1&state=0

A recap:

v6.05 (GPU then CPU time):

13,190.28 --- 13,184.89
13,136.48 --- 13,131.83


v6.06 (GPU then CPU time):

13,962.64 --- 670.80
14,049.59 --- 689.72

So for around an increase of 15 minutes more GPU time, v6.06 saves over 3.5 hours of CPU time.
This is for a GTX 285. The difference is even more extreme for slower cards. Here's a GT 240:

v6.05 (GPU then CPU time):

41,658.85 --- 40,742.34


v6.06 (GPU then CPU time):

45,470.80 --- 4,785.85

In this case we see an increase of 1:04 of GPU time and a whopping saving of 10:00 hours of CPU time with v6.06.

I certainly prefer v6.06. I can help a lot of projects with that CPU time and will have a more responsive system to work with (especially dual core or slower systems).

Our tests shows that under full load (all CPUs used), the application is very slow.

Snow Crash, that was your GTX 285 I used for the comparison above. Hope that's OK.
It looks like v6.06 was running well, even better than the current v6.71 app.

[Within 2 months 6core systems with 12 threads will be available. You will even be able to get dual socket versions.
Look to the future, it has dense core populations with multithreading being the norm.]
Hi
to add to this debate. I have 2 i7 920 boxes with a ATI 5970 each plus running WCGrid on 8 threads each as well. Whatever is planned, my view is that the app should be able to run the GPU apps with a CPU app running as well, without any micro management.
I will be running 6 core CPUs in a couple of months hopefully with a new nivida GPU card.
I agree with the use of preferences to fine tune how the box manages its resources.
My future is to 2 gulftowns per MB and 2 double GPUs per box.
Cheers
Ross, New Zealand
____________

Snow Crash, that was your GTX 285 I used for the comparison above. Hope that's OK.

Hi GDF,

For the examples below: The GTX 285 belongs to Snow Crash and the GT 240 belongs to SKGiven. In my brief search those were the only machines I came up with that had run long WUs for both v6.05 and v6.06. Maybe they can supply more details about what else was running at the time.

As for my 5 GPUGRID boxes: only 1 of 5 received any long beta WUs, both of which were of the v6.05 variety (even though all are setup to receive test apps). Of those 2 v6.05 WUs: 1 ran for an enormous amount of time, went to 100% and then back to 17% before I aborted it. The other refused to start, something I have never seen before.

Also as I stated somewhere above, with the non-BOINC Wieferich project running on both cores of the dual core machine that got v6.05 WUs: with the normal 2 Wieferich CPU WUs running, 1 stalled and the machine became 95% unresponsive. When I killed 1 instance of Wieferich and let v6.05 have the whole core, the machine became usable but of course I lost 1/2 of the Wieferich production. No other GPU app causes this problem, not v6.71, not Collatz, not MilkyWay, not PrimeGrid, not RC5-72, not SETI. You see the problem some of us have with v6.05...

Regards/Beyond

Beyond,
if this was the situation, it would be fine.
In our tests, loading the CPU with some work, it double the length of the GPU simulation.
So what where you running while you have these sims in progress?

gdf

There's lots of speculation and AFAIK few machines that have run many v6.05 & v6.06 WUs. Well here's one:

http://www.gpugrid.net/results.php?hostid=56900&offset=0&show_names=1&state=0

A recap:

v6.05 (GPU then CPU time):

13,190.28 --- 13,184.89
13,136.48 --- 13,131.83


v6.06 (GPU then CPU time):

13,962.64 --- 670.80
14,049.59 --- 689.72

So for around an increase of 15 minutes more GPU time, v6.06 saves over 3.5 hours of CPU time.
This is for a GTX 285. The difference is even more extreme for slower cards. Here's a GT 240:

v6.05 (GPU then CPU time):

41,658.85 --- 40,742.34


v6.06 (GPU then CPU time):

45,470.80 --- 4,785.85

In this case we see an increase of 1:04 of GPU time and a whopping saving of 10:00 hours of CPU time with v6.06.

I certainly prefer v6.06. I can help a lot of projects with that CPU time and will have a more responsive system to work with (especially dual core or slower systems).

I own the GTX285 that I posted results for.

It is an i7-920 with hyperthreading turned on, running Windows XP Pro 32 bit with BOINCManager version 6.2.28 (WCG Edition)

I was executing 8 World Community Grid WUs, specifically their Help Fight Childhood Cancer subproject, the entire time that the 6.05 and 6.06 GPUGrid betas were executing.
http://www.gpugrid.net/show_host_detail.php?hostid=56900
http://www.gpugrid.net/results.php?hostid=56900


I also have another i7-920 which has hyperthreading turned on, running Windows Vista Ultimate 64 bit with BOINCManager 64 bit 6.10.29. This machine has a GTX295.
http://www.gpugrid.net/show_host_detail.php?hostid=31780
http://www.gpugrid.net/results.php?hostid=31780

I only have valid results for two of the small betas on v6.06 which do show a higher usage of CPU than the results on my GTX285.
GTX285 CPU usage is 6% of CPU usage
GTX295 CPU usage is 16% of CPU usage
I was running a combination of Einstein and ClmiatePrediction on the machine with the GTX295 while the short betas were executing.

I have attached this second PC to SETI and am running 8 of their WUs along with two of GPUGrid's 6.06 betas.
Yes, I aborted a couple of GPUGrid 6.71 WUs so we could get this test started.

I am seeing low CPU usage for the GPUGrid 6.06 betas with between 2-3 percent each as viewed in Task Manager.

The "Status" column reports the WU is running and using 0.28 CPU + 1.00 NVIDIA GPU

The progressbar/ percent complete indicator does not appear to be updating at all.

The Time to Complete is updating.

I have been running for 30 minutes and if the time to complete is accurate then I am not seeing any improvement on runtime at all. I will let this continue and we can follow up with final results when it finishes.

Let's start listing things to test ...
At first blush it looks like it has something to do with the OS?
Perhaps we could test different versions / bits of BOINCManager?

____________
Thanks - Steve

If the hit on the GPU app is so high, then it does not make any sense to have less than 0.1 CPU driving the GPU. You might lose up 100% of performance of 256 GPU cores to save 1 CPU core!
We might go to 0.6 CPU so that two GPUs can share the same CPU. This should be enough and more similar to the reality of the usage. As a matter of fact, many of our calculations do use some CPU anyway for calculations.
Comments?

gdf