Hello,

This issue due to be installed already, why not put an option in the preferences to select sub-projects in CPU version? This avoids the need to make a file or abandon app_info CPU units that we do not want to ....!

thank you to the admins for your answers ....

Sincerely,

---

Team Alliance francophone, boinc: 7.0.18

GA-P55-UD5, i7 860, Win 7 64 bits, 8g DDR3, GTX 470

Hello,

This issue due to be installed already, why not put an option in the preferences to select sub-projects in CPU version? This avoids the need to make a file or abandon app_info CPU units that we do not want to ....!

thank you to the admins for your answers ....

Sincerely,

I think Travis asked about this on the BOINC dev list a few months ago and the answer was there wasn't really a good way to do it now. There are a bunch of things like this in BOINC that I'd like to fix but can never find the time to do it.

Yet the project PrimeGrid I think they have found a way to choose between the application in cuda, ati or cpu in our preferences on their site?!

---

Team Alliance francophone, boinc: 7.0.18

GA-P55-UD5, i7 860, Win 7 64 bits, 8g DDR3, GTX 470

still no response?

---

Team Alliance francophone, boinc: 7.0.18

GA-P55-UD5, i7 860, Win 7 64 bits, 8g DDR3, GTX 470

I'll try looking into this at some point.

thanks you

---

Team Alliance francophone, boinc: 7.0.18

GA-P55-UD5, i7 860, Win 7 64 bits, 8g DDR3, GTX 470

Hi,

Maybe this request have been already answered but could you think it is possible having WU application for CPU Milkyway@Home and Milkyway@Home (SSE2) like N_body (mt) : 1 WU for multiple cores ?

Have a nice day and thanks for your reply and for research.

loranger

Personally I think we've got enough ATIs slicing through the classic MW WUs so that the CPUs should all be doing n-body work. They'll be valueable there.

MrS

---

Scanning for our furry friends since Jan 2002

Personally I think we've got enough ATIs slicing through the classic MW WUs so that the CPUs should all be doing n-body work. They'll be valueable there.

MrS

+1

i wish the account settings were similar to SETI@Home's, where you can check the specific apps you want to run, in opposition to MW@H's account settings in which one has to choose whether to use the CPU, the GPU, or both. there's just something about having to watch separation tasks run on the CPU and wait for an n-body task to come along, all while my GPU is devouring separation tasks one after another.

---

Personally I think we've got enough ATIs slicing through the classic MW WUs so that the CPUs should all be doing n-body work. They'll be valueable there.

MrS

+1, but the ATI have al of error currently...

---

Greetings from,
TJ

I think most of the recent errors are due to the application update. It made the server much more stable, but broke compatibility with the old apps. Some people don't realize this and just keep crunching through the WUs for nothing.

MrS

---

Scanning for our furry friends since Jan 2002

I would like to see this done. I want to be able to process Nbody WUs, but processing anything on my CPU that can be processed on GPUs instead is inefficient usage of resources.

ttt^


...any progress on this?

---

ttt^


...any progress on this?

Since the server update you should be able to select between running N-body or separation at all, but not for a type of device.

Since the server update you should be able to select between running N-body or separation at all, but not for a type of device.

excellent...been waiting for this for quite some time!

a few more questions though...i now see a frequency/Hertz/fps field now, the default value for which is 30. does this pertain to either separation tasks or n-body tasks, or both? will this frequency parameter have an effect on separation tasks regardless of whether they're crunched on the CPU or a GPU? is this something we'll just have to play around with until we find the optimal value for our own machines?

TIA,
Eric

---

a few more questions though...i now see a frequency/Hertz/fps field now, the default value for which is 30. does this pertain to either separation tasks or n-body tasks, or both? will this frequency parameter have an effect on separation tasks regardless of whether they're crunched on the CPU or a GPU? is this something we'll just have to play around with until we find the optimal value for our own machines?

It's the same thing as the --gpu_target_frequency argument people have used app_info before to use (an app_info command line argument will override this). It will only effect separation with GPU.

Because GPUs aren't currently preemptible compute tasks can prevent the GPU from redrawing the display. The amount of work the GPU is given at at time needs to be limited to allow drawing; this parameter controls the time estimate used to determine the size of work packets to send at a time.

For example with the default of 30, it will try to keep the sizes so that individual kernel executions take about than (1000ms / 30) = 33.3ms so that the GPU has an opportunity to draw the display ~30 times per second.

There's some overhead to breaking work up into many kernel calls. Using a smaller number will tend to consume the GPU entirely for long periods and be very laggy. On slower Nvidia cards a full iteration will typically take about 1 full second and is pretty much unusable. A higher number will have more overhead but give the GPU more opportunities for drawing be be less laggy.

Also I don't think the current clients will use it; it won't do anything until I update them again which should be soon.

It's the same thing as the --gpu_target_frequency argument people have used app_info before to use (an app_info command line argument will override this). It will only effect separation with GPU.

Because GPUs aren't currently preemptible compute tasks can prevent the GPU from redrawing the display. The amount of work the GPU is given at at time needs to be limited to allow drawing; this parameter controls the time estimate used to determine the size of work packets to send at a time.

For example with the default of 30, it will try to keep the sizes so that individual kernel executions take about than (1000ms / 30) = 33.3ms so that the GPU has an opportunity to draw the display ~30 times per second.

There's some overhead to breaking work up into many kernel calls. Using a smaller number will tend to consume the GPU entirely for long periods and be very laggy. On slower Nvidia cards a full iteration will typically take about 1 full second and is pretty much unusable. A higher number will have more overhead but give the GPU more opportunities for drawing be be less laggy.

oh ok, i'm not too familiar with that issue even though it was a prevalent one on the forums not too long ago (i use my HD 5870 GPU exclusively for MW@H while the motherboard's integrated HD 4290 GPU is dedicated to the display, so i've never had to worry about GUI lag and the parameter that helps control it). that being said, does my 5870 GPU stand to benefit by setting that parameter lower than the default value of 30 even though its not actually running a display? if so, and it allows me to use the lowest possible theoretical value, what would that value be? will the 5870 GPU still try to draw a display either b/c my desktop has been extended to it or b/c it has a dummy plug plugged into it (and fooling it into thinking that its connected to an actual display)?

TIA,
Eric

---

does my 5870 GPU stand to benefit by setting that parameter lower than the default value of 30 even though its not actually running a display

A little bit. There's the --non-responsive argument which ignores any requirement (You could also set it to something very low (~ 1) which should end up doing the same thing). These options tend to be more significant on Nvidia stuff since it's slower. At best you might get a few percent faster (< 5%ish). I also wish I had a way to detect if a GPU was being used for display. I'm also hoping this entire issue goes away which I think it might with the Radeon 7970/ GCN's multitasking features but I'm not sure.

A little bit. There's the --non-responsive argument which ignores any requirement (You could also set it to something very low (~ 1) which should end up doing the same thing). These options tend to be more significant on Nvidia stuff since it's slower. At best you might get a few percent faster (< 5%ish). I also wish I had a way to detect if a GPU was being used for display. I'm also hoping this entire issue goes away which I think it might with the Radeon 7970/ GCN's multitasking features but I'm not sure.

thanks for the help Matt. i'll just set the parameter to 1 for now and see what happens...

---