This seems to confirm what I've been finding. It seems that the slow happens with a high CPU load (at least in Windows. It seems to not happen for me in Linux). The time is about what it should be with a low CPU load, and quite a bit higher if the CPU load is light. This is still a problem to fix though.

Matt, I believe the way to sort this would be to make sure that the CPU part of the MW app runs in normal priority, or at least higher priority than the CPU-only tasks. (After first having made certain that the GPU app releases the CPU for a sane amount of time while waiting for the GPU to report back, of course.)

Matt, you actually need to change this. Apparently, the CPU part of the MW GPU app now runs with normal priority in idle priority class (aka below normal). This doesn't cut it (something Cluster Physik found out a long time ago), the CPU part now suffers from having to compete with CPU-only tasks (even though these run with idle priority). It needs to run with normal priority in normal priority class (aka normal), which was the default with 0.23 and older apps.

---

... obviously the situation isn't ideal b/c i have to edit the cc_config.xml file and restart BOINC every time i want to switch from MW@H to S@H or vice versa ...

Did something related a while back switching cc_config back and forth for logging purposes. Can't find the files I used, but IIRC I wrote a couple of batch files that would suspend the projects, copy over the cc_config, force a re-read of cc_config, and resume the projects.

It went something like this: wrote two text files that were the cc_config files, called them something other than cc_config, wrote two batch files that would suspend, force copy the proper new cc_config, force a re-read, then resume. That way with a click of a shortcut on my desktop I could perform the switch.

I used, again IIRC, the boinccmd tool with the --project and the --read_cc_config operators. All the info is in the Boinc wiki. Good luck if you decide to try it.

http://boinc.berkeley.edu/wiki/Boinccmd_tool

that would be awesome! granted, it takes me less than a minute to performa all the necessary steps to switch from MW@H to S@H and vice versa. but a one-click operative would be killer! i have zero experience with creating and using batch files, so it may be some time before i try to tackle this, but i'll definitely have a look. thanks for the link.

@ Sunny129

Hmmmm,

I have an M4A78T-E which has the HD 3300 (RS780D), along with an HD 4850.

I'm running straight stock for MW but also crunch Collatz and I'm not having problems with trying to start MW tasks on the integrated since the update to 59.

On the earlier versions it would try and start one on the 3300 if I snoozed the GPUs and then re-enabled them though.

you bring up a good point. i should see if its even necessary to edit the cc_config and restart BOINC in order to switch from S@H to MW@H (or back again) now that i'm dealing with the new MW@H v0.59. i'll experiment with it over the next day or two and report back.

---

Looking forward to a new faster app. My little HD3850 was getting about 34,000 cs a day now I forecast it only getting about 19,000 cs a day. OUCH!

... obviously the situation isn't ideal b/c i have to edit the cc_config.xml file and restart BOINC every time i want to switch from MW@H to S@H or vice versa ...

Did something related a while back switching cc_config back and forth for logging purposes. Can't find the files I used, but IIRC I wrote a couple of batch files that would suspend the projects, copy over the cc_config, force a re-read of cc_config, and resume the projects.

It went something like this: wrote two text files that were the cc_config files, called them something other than cc_config, wrote two batch files that would suspend, force copy the proper new cc_config, force a re-read, then resume. That way with a click of a shortcut on my desktop I could perform the switch.

I used, again IIRC, the boinccmd tool with the --project and the --read_cc_config operators. All the info is in the Boinc wiki. Good luck if you decide to try it.

http://boinc.berkeley.edu/wiki/Boinccmd_tool

that would be awesome! granted, it takes me less than a minute to performa all the necessary steps to switch from MW@H to S@H and vice versa. but a one-click operative would be killer! i have zero experience with creating and using batch files, so it may be some time before i try to tackle this, but i'll definitely have a look. thanks for the link.

@ Sunny129

Hmmmm,

I have an M4A78T-E which has the HD 3300 (RS780D), along with an HD 4850.

I'm running straight stock for MW but also crunch Collatz and I'm not having problems with trying to start MW tasks on the integrated since the update to 59.

On the earlier versions it would try and start one on the 3300 if I snoozed the GPUs and then re-enabled them though.

you bring up a good point. i should see if its even necessary to edit the cc_config and restart BOINC in order to switch from S@H to MW@H (or back again) now that i'm dealing with the new MW@H v0.59. i'll experiment with it over the next day or two and report back.

One other factor to keep in mind is I have the CC set to keep the apps in memory when suspended (to avoid trashing work for apps that don't checkpoint, like Leiden trajou WU's and the current MW Sep app! ;-)).

That could possibly have an impact on how you want to set up.

From what I am seeing here on my tests of app 0.59 without playing with the responsibiliyfactor:

- System response is bad like before.
- system cpu use is 1 core
- cpu time of the app is low
- gpu usage is high

So I am wondering if the attempt to modify the shunk size is the real solution to the problem. The shunk size for sure will influence the responsiveness of the gpu. The main problem I see is the responsiveness of the system.
This looks like what the old "f" param did:

kernel frequency: f (default 30)
The application determines the size of the work packages sent to the GPU in a dynamic manner. It tries to get the number of executed packages per second above the value specified here by splitting them to smaller ones. The OS is completely blocked from accessing the graphics card for the duration of one package leading to a somewhat sluggish behaviour of the user interface.
Limiting the size and therefore reducing the execution time per package creates more opportunities for the OS to slip in between two work packages and to react to user input. The default value of 30 Hz is tuned for usability of the system. Reducing it could increase the throughput of the app slightly.

Example:
<cmdline>f10</cmdline>
The app will try to run 10 work packages per second (limits the execution time to 100ms or shorter).

For me it looks like modifying the way the cpu waits for the gpu to send back data is the point o look into. It looks like a core is blocked instead of released while is waits for the results from the gpu. Inceasing the prio while a tread waits (and blocks a core) for the gpu results makes it even worse.
Here the old param "w" (and "b") gave a chance to adapt the cpu responsiveness to the individual system:

Wait factor: w (default 1.0)
The app tries to release the CPU during the the GPU computations. It does so by predicting the runtime for the GPU calls and send the CPU thread to sleep for that time. One can manually correct the prediction of the application with this factor. When raising it, the CPU thread sleeps longer, decreasing the value will lead to some faster polling. Setting this value to 0.0 turns off the release of the CPU. Default is of course a value of 1.0.
If you see a low GPU load, you can try to decrease it (if you have a load of 80%, set it to 0.8). If you see a high CPU load, a slight increase of this value may help. Increase it too much and it will affect the crunching speed. You could use this for throttling of the GPU in case the high GPU load leads to a very sluggish behaviour of the user interface or even VPU recover events.
Setting w1.1 could improve the situation (see also the f, b, and p options).

Example:
<cmdline>w1.3</cmdline>
This would increase the sleep time by 30% in relation to the prediction.

Polling behavior for the GPU within the Brook runtime: b (default 0)
See the option w for starters. If that time has elapsed, the GPU polling starts. This can be done by continously checking if the task has finished (b-1), enabling the fastest runtimes, but potentially creating a high CPU load (a bit dependent on driver version). Second possibility is to release the time slice allotted by the OS, so other apps can run (b0). This is the default value. The catch is that there is some interaction with the priority. The time slice is only released to other tasks of the same priority. So raising the priority effectively disables the release and the behavior is virtually identical to setting this parameter to -1. If a raised priority and a low CPU time is wanted, one may set it at to 1. This suspends the task for at least 1 millisecond, enabling also tasks of lower priority to use the CPU in the meantime. This can also help to get a smoother system behaviour. One can use b2 or b3 if one wants reduce the polling frequency even more.
Possible values:
b-1: busy waiting
b0: release time slice to other tasks of same priority (default)
b1, b2 or b3: release time slice for at least 1, 2, or 3 milliseconds respectively See also options p and w.

Example:
<cmdline>b-1</cmdline>
Enable busy waiting (no release of the time slice during polling).

What I see with the 0.57/0.59 apps is like a "w0.0 b-1" on the old app 0.23.

The few seconds cpu time used at the end are some finishing calculations not ported to gpu (yet) Matt was talking about I believe. They don't have any representation in the process bar it looks like; not really missing it.

Hallo,

my English is not very good :) you're talking me crazy :)
I now have CPU usage of 0.05 ( what says Boinc client ) but the units takes longer than with 0.23 app.
Is it now better to run 2 units with app_info or not ?

( i have 6970 GPU )

Greetz

---

One other comment about the current state of affairs here at MW:

As I said before. I'm running straight stock for MW, and I am not seeing any unexpected CPU hogging from the GPU app with any of the last generation releases.

It grabs a little extra CPU time when a task first starts, and then a chunk at the end of the run when it's finishing up.

Overall, it's had a neglible effect on my CPU project crunching performance.

Hallo,

my English is not very good :) you're talking me crazy :)
I now have CPU usage of 0.05 ( what says Boinc client ) but the units takes longer than with 0.23 app.
Is it now better to run 2 units with app_info or not ?

( i have 6970 GPU )

Greetz

All I know is the stock settings split my 4850 into 2 devices by default, and the performance has been about what I expected given the current state of develeopment for the new generation.

Read that as not that much worse than it was when I was running Gipsel "Specials". ;-)

I'm running straight stock for MW, and I am not seeing any unexpected CPU hogging from the GPU app with any of the last generation releases.

I am not seeing it on the cpu process itself too, but I see it for the system while the app is running.

I'm running straight stock for MW, and I am not seeing any unexpected CPU hogging from the GPU app with any of the last generation releases.

I am not seeing it on the cpu process itself too, but I see it for the system while the app is running.

Hmmmm, interesting.

If I monitor with Process Explorer I see the GPU app grab a few tenths to about 1.5 percent of a CPU now and then. However, the older generation Gipsel apps did that too.

for a majority of folks so far, this certainly seems to be the general consensus. however, keep in mind that the ability of a rig to crunch CPU tasks and MW@H GPU tasks simultaneously (and do so without devoting excessive CPU resources to the GPU and crippling GPU task run times) depends on several variables...hence the reason so many different platforms are acting so differently. for instance, as i mentioned several posts above, i experience a ~20% decrease in MW@H task efficiency while running Einstein@Home on all 6 CPU cores. and yet i do not need to suspend E@H altogether in order to achieve "normal" MW@H task run times. rather i simply have to tell BOINC to only use 85% of the CPU, leaving one CPU core free to handle the uploading and offloading of MW@H data to and from the GPU (and to handle any other multitasking instructions that may occur while i browse the web or whatever). granted, this is made possible by the fact that my "CPU utilization per GPU task" is the normal 5% (0.05 CPUs + 1.00 ATI GPUs) and not excessive like so many others are experiencing.

Hi,

I did the same, but last year already when I got the pc. I run E@H on 6 cores, 1 core is then for MW@H with the 2 ATI's and the remaining core for me, to type, browse and watch NASA-TV.
However currently with no changes, only the new Matt-ATI-app it is using a full load of the cores. So ther is no spate, always 100% cpu load in the resorce Monitor.

So waiting is for a new update from Matt.

---

Greetings from,
TJ

I'm running straight stock for MW, and I am not seeing any unexpected CPU hogging from the GPU app with any of the last generation releases.

I am not seeing it on the cpu process itself too, but I see it for the system while the app is running.

Hmmmm, interesting.

If I monitor with Process Explorer I see the GPU app grab a few tenths to about 1.5 percent of a CPU now and then. However, the older generation Gipsel apps did that too.

Yep, thats what I see on the app too. At the same time the app is running, the system cpu use jumps to the equivalent of a full core. That's why I think it looks like some sort of busy-wait instead of sleep if the cpu thread waits for the gpu

Hey Matt,

thanks for quick hot-fix! By now it's working almost perfectly for me.

Running "stock": reserved 1 CPU core on my C2Q, 3 others are CPU-crunching. Normal CPU usage of MW is ~0% and performance is up to 0.23 levels.

Tweaking: running 2 WUs concurrently (thanks cedricdd!) the idle GPU time between tasks is masked well. Give it a few minutes to settle in and there's no longer a break of a few seconds between WUs. Zydor, that's how running 2 WUs in parallel speeds things up! That's far more than 1-2% (of course depending on CPU & GPU speed).

I also added

<cmdline>-r2</cmdline>

which makes the Win 7 UI noticeably more responsive - very nice.

What's left to do?
1. I don't think you'll want to make running 2 WUs in parallel the default option (too risky, any strange driver problems could occur). Then it would be nice to reduce the idle GPU time between WUs, as this will improve throughput for anyone running "stock". I see the following possibilities:

• Do more of the final calculations on the GPU. This is what Gipsel / Cluster Physik did. Not sure how easy this is, though.
  
• I don't kow what exactly is being done in this final step, but I'm guessing the fitness value is generated from the previous calculation results. I suppose it would be possible to split these calculations, so whenever you got new results back from the GPU (and told it what to do next) you could perform / update these calculations on the CPU as far as you already can, given the current results. Integral CPU time would ideally be almost constant, but since the load was distributed the idle GPU time would be reduced.
  

2. I don't think you want people to have to either donate a full core for MW or to suffer from reduced performance. As Brickhead already said, this is a fundamental problem any GPU app has and which some of them solved well by now. The problem is this: in 0.59 and under windwos you're running at priority "below normal", whereas BOINC cpu tasks run at "lowest". You estimate how long the GPU will be busy, set your CPU thread to wake up by that time (minus some safety margin). Now you should theoretically be fine, since anyone else occupying the CPU (other BOINC tasks) has a lower priority than your app. But this just doesn't happen.. or doesn't work very well. You're getting the CPU time too late and thus GPU performance suffers.

• Working at priority "normal" should help.
  
• I don't know your polling behaviour. I'd probably go for the old "b-1" style, which means that once the CPU thread is woken up it starts to continously poll the GPU for results, until it gets them. This worked reasonably well without excessive CPU load since the GPU time to complete single steps can be estimated fairly accurately. It did lead to choppy screen updates, though, probably because there was not always enough time for the GPU to finish its screen refresh between MW steps. That's why I used "f60" along with "b-1" to get maximum performance and 30+ fps. And that's why "b0" was the default polling behaviour. It allowed for more responsive systems at the cost of reduced performance if all CPU cores were loaded otherwise.
  

Good luck with the further development!
MrS

Edit@Len: what you are talking about is what I called "final calculations" in my post.

Edit2: Sadly I have no idea why 0.59 is using a full core on some systems and practically no cpu time on others. I don't even know where to start investigating this..

---

Scanning for our furry friends since Jan 2002

WOW.....

Whatever they just did here triggered a major malfunction on my big gun battlecruiser!!

Not only did it trash all the MW when I restarted BOINC, but the whole load went down the drain!!

OUCH!! :-D

<edit> All I did was stop BOINC to go do a race in iRacing. When I restarted BOINC after the race, all hell broke loose!

<edit2> That's NEVER happened before!

WOW.....

Whatever they just did here triggered a major malfuntion on my big gun battlecruiser!!

Not only did it trash all the MW when I restarted BOINC, but the whole load went down the drain!!

OUCH!! :-D

<edit> All I did was stop BOINC to go do a race in iRacing. When I restarted BOINC after the race, all hell broke loose!

If that one -> http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=88232 is your "battlecruiser", then it 's fairly obvious.

<core_client_version>6.10.60</core_client_version>
<![CDATA[
<message>
Incorrect function. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
<search_application> milkywayathome_client separation 0.57 Windows x86 double CAL++ </search_application>
Found 3 CAL devices
Chose device 0

Device target: CAL_TARGET_610
Revision: 19
CAL Version: 1.4.1332
Compute shader: CAL_FALSE
Engine clock: 650 Mhz
Memory clock: 1000 Mhz
GPU RAM: 341
Wavefront size: 64
Double precision: CAL_FALSE
Compute shader: CAL_FALSE
Number SIMD: 2
Number shader engines: 1
Pitch alignment: 256
Surface alignment: 256
Max size 2D: { 8192, 8192 }

Device does not support double precision
Device failed capability check
Failed to setup CAL
22:22:17 (4536): called boinc_finish

</stderr_txt>

There are plenty of other like that tasks as well.

---

Join Support science! Joinc Team BOINC United now!

LOL....


Yep, I just noticed that...

They don't work too good when you try and start them on a single precision GPU! ;-)

Apparently, it's not as fixed as it was looking earlier! :-D

<edit> BTW, it would look to me like this has got to be a CC problem rather than anything from MW, since all indications are that BOINC knows about the single precision GPU but goes ahead and stupidly tries to start the DP task on it regardless!

<edit2> It might be a good idea to put in a error handler to deal with this kind of CC stupidity to avoid needlessly trashing work and have to recyle it through the mill, maybe yes? Of course, the optimum is to not have stupidity at all! :-D

<edit> BTW, it would look to me like this has got to be a CC problem rather than anything from MW, since all indications are that BOINC knows about the single precision GPU but goes ahead and stupidly tries to start the DP task on it regardless!

yup! that's the same crap i had to deal with while trying to figure out how to use my mobo's integrated GPU solely for display purposes and my 5870 GPU solely for crunching at the same time. at the end of the day, it was impossible to accomplish without a cc_config file (that directed BOINC to ignore one GPU or the other depending on the app i wanted to run) and a restart of BOINC. what a PITA...

---

<edit> BTW, it would look to me like this has got to be a CC problem rather than anything from MW, since all indications are that BOINC knows about the single precision GPU but goes ahead and stupidly tries to start the DP task on it regardless!

yup! that's the same crap i had to deal with while trying to figure out how to use my mobo's integrated GPU solely for display purposes and my 5870 GPU solely for crunching at the same time. at the end of the day, it was impossible to accomplish without a cc_config file (that directed BOINC to ignore one GPU or the other depending on the app i wanted to run) and a restart of BOINC. what a PITA...

LOL...


Well, that would seem to be a no brainer feature, so what were they thinking when they wrote the last CC code? :-D

well in all fairness, the BOINC developers couldn't have accounted for all the various nVidia and ATI GPU applications that would eventually pop up as faster, more efficient alternatives to classic project apps. though with the advent of the multi-GPU crunching machine, you'd think that all these recent revisions of the BOINC client would allow it to play nice with all the anonymous GPU apps out there...

---

Why no update that MW is down?