If and when the get it arranged so both the Cuda card AND the CPU could crunch Seti at the same time, you might bring down a lotta rigs....

Especially some that do not get regular attention such at cleaning the dust out....now all of a sudden you've got a full CPU load PLUS the vid card churning away full bore. Extra heat in the case that may not be handled properly and start pushing things over the edge. CPU and GPU alike....

We're already doing CUDA and opti AP and I run Einstein in there as well. Adding cpu tasks hasn't caused any additionl heat on my system. I'd think that anyone running an opti cpu task would be more likely to have problems with temps because of poor pc maintenance, than from the gpu.

---

I'm going to agree that CUDA should be opt-in, but AP should not.

My reasons for taking this stance is that if you are part of SETI@Home, you are willing to donate your CPU to crunch needed data, and in my opinion, it shouldn't matter if its an app called SETI or AstroPulse, and it shouldn't matter as to the length of the workunit.

But CUDA is different. Many video cards are built by third parties and many do not have sufficient cooling, or are sold pre-overclocked. Machines are already overheating with faster CPUs and now GPUs too. Some video cards are also designed to be "dual slotters" (a wide card with the cooling taking up the slot next to the video card slot) just to get the proper cooling! It can be dangerous, and overheating the graphics card is much more likely than the CPU, especially since the CPUs have been built for the last 5+ years with overheat protection built-in, a feature GPUs do not have as of yet. Because of this, potentially destroying a participant's component can't be good PR for the project and can/will result in many complaints. I think a warning should also be included indicating the potential problems that may arise from using one's video card to do crunching so that people are better informed.


I'm sure many will disagree with me, but I don't think the name of the app should matter at all, but what part of the computer a participant is willing to donate does matter.

---

My reasons for taking this stance is that if you are part of SETI@Home, you are willing to donate your CPU to crunch needed data, and in my opinion, it shouldn't matter if its an app called SETI or AstroPulse, and it shouldn't matter as to the length of the workunit.

That I basically agree with, but my opposition to AP being defaulted to yes is because of the short deadline.

I have two hosts that complete 45cr MB in ~45-50hrs, an AP on these would probably take 1100-1200hrs(45-50days) There is no possible way they could finish an AP within the time allowed, so they would probably have wasted all that crunch time.

If the deadline was 3 months instead of 1 month my opinion would change.

A set and forget user might have a passively cooled CUDA card (the only one I have is) and not notice until it's too late that the CUDA app has over-heated it...

-Dave

If the system is cooled correctly, a user shouldn't have to notice the card is overheating. All GPUs come with a VBIOS that checks the GPU's temperature. The drivers in combination with the VBIOS know what is the best temperature for this sort of GPU to run on, knows its minimum and maximum. If the maximum is reached, the GPU will change the fan speed (on active cooling) or clock down its clocks/voltage (on passive cooling) fully automatically.

Not everyone has adequate cooling and venting in the rest of the computer. That's something you really need when using passively cooled cards.

Now when comparing Folding@Home with Seti's use of the GPU, FAH does calculations in bursts. It'll use the GPU for a couple of minutes, then back off and use the CPU. SAH will use the GPU continuously at full load. The work does come in bursts, but the time between the bursts is very short, not enough to cool the GPU down.

---

A set and forget user might have a passively cooled CUDA card (the only one I have is) and not notice until it's too late that the CUDA app has over-heated it...

-Dave

If the system is cooled correctly, a user shouldn't have to notice the card is overheating. All GPUs come with a VBIOS that checks the GPU's temperature. The drivers in combination with the VBIOS know what is the best temperature for this sort of GPU to run on, knows its minimum and maximum. If the maximum is reached, the GPU will change the fan speed (on active cooling) or clock down its clocks/voltage (on passive cooling) fully automatically.

Not everyone has adequate cooling and venting in the rest of the computer. That's something you really need when using passively cooled cards.

Now when comparing Folding@Home with Seti's use of the GPU, FAH does calculations in bursts. It'll use the GPU for a couple of minutes, then back off and use the CPU. SAH will use the GPU continuously at full load. The work does come in bursts, but the time between the bursts is very short, not enough to cool the GPU down.

The thing that is easy to overlook here is where the heat goes. I have 2 8800 GTS cards running Folding@Home and it keeps one card @ 81C and the other (with the partially blocked air intake) @ 89C. The problem is all the heat is not being blown out the back, everything inside the case heated up until I cooked 2 sticks of ram. (This unit is now running again with new ram and the case open and on it's side so the heat goes up into the air instead of up into the ram).

Moral of the story- Keep an eye on the case temp along with the GPU temps.

That being said, I agree that the GPU option should default to "OFF". The system needs to be checked and monitored after turning it on.

---

Boinc Button Abuser In Training >My Shrubbers<

The thing that is easy to overlook here is where the heat goes.

I agree with that. Any obstructions, such as other cards, RAM, cables, the CPU, heck even the case siding itself, should be checked. The (very very very long!) Nvidia card my girlfriend has in her PC blew directly on her hard drives. That's a good way to get the strangest of BSODs. ;-)

They're trying to make everything smaller these days, but for these cards, it seems. So the you have a medium sized case, with a mini-ATX board and you need to put in a card that's about the length that your case is wide... Unless you saw part of the case out so the card can blow its exhaust directly out the front, this is never going to work. (Nothing said about how to put the molex connectors in ;-))

Then there are cards that blow the hot air out the back, through a hole in the backplate. Give it enough time and it'll melt the VGA connector in place. ;-)

So don't wonder why I have no sides on my PC. It's the bare-bone inner casing holding the mobo and PSU, but that's all.

---

My reasons for taking this stance is that if you are part of SETI@Home, you are willing to donate your CPU to crunch needed data, and in my opinion, it shouldn't matter if its an app called SETI or AstroPulse, and it shouldn't matter as to the length of the workunit.

That I basically agree with, but my opposition to AP being defaulted to yes is because of the short deadline.

I have two hosts that complete 45cr MB in ~45-50hrs, an AP on these would probably take 1100-1200hrs(45-50days) There is no possible way they could finish an AP within the time allowed, so they would probably have wasted all that crunch time.

If the deadline was 3 months instead of 1 month my opinion would change.

Theoretically, computers that do not meet the minimum specs for AP should not receive AP workunits. I believe the minimum specs is a 1.6GHz processor, so your 500MHz and your 533MHz machines should not get getting AP at all. As to why they are receiving AP in the first place, I don't know why.

---

If the system is cooled correctly, a user shouldn't have to notice the card is overheating. All GPUs come with a VBIOS that checks the GPU's temperature. The drivers in combination with the VBIOS know what is the best temperature for this sort of GPU to run on, knows its minimum and maximum. If the maximum is reached, the GPU will change the fan speed (on active cooling) or clock down its clocks/voltage (on passive cooling) fully automatically.

Not everyone has adequate cooling and venting in the rest of the computer. That's something you really need when using passively cooled cards.

Yes, but I'm not talking about the active Seti participant who frequents the boards here and knows all about the CUDA app, I'm talking about the set and forget type who may NOT have a properly cooled system and doesn't know that the CUDA app has suddenly started overheating the whole thing. Maybe the system IS adequately cooled for what that person normally does, but that doesn't include running a GPU based science application. That's why it should be opt-in, IMO.

-Dave

---

I'm talking about the set and forget type

Technically, the set it and forget it type won't have a problem as they never updated to a BOINC version that can do CUDA.

They'll still be on a version 4.45 that get complaints for other reasons. ;-)

To get the warning that there's a newer recommended BOINC out, you'd need in the least 5.10.45 and read your messages every once in a while.

To update to 6.4.5, which does do CUDA, you'd have to see the warning about it on the download page, or see trouble arising when you installed it. It'll also only work correctly if you have the right drivers for the GPU installed.

So tell me, when you're a set it and forget it type, do you do all the above without noticing anything strange about your system? But in all honesty... even if they managed to do all that and set it to forget it, they'd be airheads to just install a new BOINC version and not check the running of it every once in a while for probable problems. ;-)

Although you probably have a number of these people around, I'm thinking their number is negligible.

---

I'm talking about the set and forget type

Technically, the set it and forget it type won't have a problem as they never updated to a BOINC version that can do CUDA.

They'll still be on a version 4.45 that get complaints for other reasons. ;-)

To get the warning that there's a newer recommended BOINC out, you'd need in the least 5.10.45 and read your messages every once in a while.

To update to 6.4.5, which does do CUDA, you'd have to see the warning about it on the download page, or see trouble arising when you installed it. It'll also only work correctly if you have the right drivers for the GPU installed.

So tell me, when you're a set it and forget it type, do you do all the above without noticing anything strange about your system? Aren't you an air-head then? :-)

Actually, I think all the 5.10.x's will tell you about available upgrades. Most of mine are 5.10.13, and are always reminding me that there are newer versions available and I should hurry over and get them (which I choose to ignore). ;-)

As far as whether it is wise to treat any computer as a 'set and forget' appliance like a toaster, can opener, or refrigerator (if they even are) isn't really the point. :-)

As Ozz said, enabling AP to run by default is at least tolerable, since the work being done by it is within the well known scope of the project.

Enabling CUDA by default is 'squatting' on hardware they haven't asked permission to use first.

Please note that they didn't bother updating the Rules and Policies before rolling it out to reflect the fact that the software is going to use the GPU if available. This makes the default on setting completely unsat.

You want to talk about a nightmare scenario. Consider the great PR the project will get if (heaven forbid) someone does experience a catastrophic system failure from this ill advised policy.

Alinator

Let's hold the poll then:

David Anderson wrote:

This will be fixed by the latest version of the app, which falls back to CPU execution if GPU memory allocation fails.

This version has been in beta for a while, but for some reason wasn't put in sah.
I asked Jeff to do it; he says he'll do it Monday.

This does raise the questions:

- Should "use GPU?" be a global (rather than per-project) preference?
- Should it default to No?

I have already answered that by my knowledge the only projects using applications for both GPU and CPU are Seti and Seti Beta. GPUGrid only uses a GPU app. Einstein hasn't released its application yet. I know some others have one in development, but how far are they? So No on the first question, for now.

Yes on the second. :-)

---

Let's hold the poll then:

David Anderson wrote:

This will be fixed by the latest version of the app, which falls back to CPU execution if GPU memory allocation fails.

This version has been in beta for a while, but for some reason wasn't put in sah.
I asked Jeff to do it; he says he'll do it Monday.

This does raise the questions:

- Should "use GPU?" be a global (rather than per-project) preference?
- Should it default to No?

I have already answered that by my knowledge the only projects using applications for both GPU and CPU are Seti and Seti Beta. GPUGrid only uses a GPU app. Einstein hasn't released its application yet. I know some others have one in development, but how far are they? So No on the first question, for now.

Yes on the second. :-)

Agreed.

#1 No, but I don't think it should ever be more than a project only preference.

#2 Yes.

Alinator

Theoretically, computers that do not meet the minimum specs for AP should not receive AP workunits. I believe the minimum specs is a 1.6GHz processor, so your 500MHz and your 533MHz machines should not get getting AP at all. As to why they are receiving AP in the first place, I don't know why.

They dont, I chose a poor way of explaining.

But my machines DO run 24/7 @ 100% CPU. A min spec machine that effectively runs less than 16 hrs/day @ 100% or 24/7 @ less than 65% would still be pushing to meet the deadline.

The crux of my point is that machines that are issued AP's are expected to use about 20x the crunching power to meet deadline as for MB (ie a 2000% increase in output).

The ratio of Crunching hrs to Allocated time should not have changed or the change should be opt-in only.

[Edit to correct figures]

Theoretically, computers that do not meet the minimum specs for AP should not receive AP workunits. I believe the minimum specs is a 1.6GHz processor, so your 500MHz and your 533MHz machines should not get getting AP at all. As to why they are receiving AP in the first place, I don't know why.

They dont, I chose a poor way of explaining.

But my machines DO run 24/7 @ 100% CPU. A min spec machine that effectively runs less than 16 hrs/day @ 100% or 24/7 @ less than 65% would still be pushing to meet the deadline.

The crux of my point is that machines that are issued AP's are expected to use about 3x the crunching power to meet deadline as for MB (ie a 300% increase in output).

The ratio of Crunching hrs to Allocated time should not have changed.

Having larger workunits is a good thing though. Again I refer to the original SETI tasks that took a week or more for people to crunch just a single WU, and the servers weren't as overloaded with work requests as they are now. Having larger workunits allows for hosts to stay busy longer without returning for work as often. If anything, a longer deadline would be necessary, but then people complain about long deadlines and they have to wait forever to get their credit, especially if several people don't return them on time - it could be a couple months before they see their credit!

What messes everything up is that most computers can do SETI MB rather efficiently, and the Task Duration Correction Factor is geared toward MB. Then you have AP come along that takes much longer, and the TDCF (or DCF for short) is suddenly out of whack. So a computer for which the BOINC scheduler thinks it can complete a AP task within the time allowed downloads a workunit only to find that it probably can't finish, but the work was downloaded and BOINC will try to finish it anyway.

If it were possible, there should have been a separate DCF for MB and AP so that BOINC's scheduler doesn't think the computer is more efficient than it really is.

... but I would gather that this is an exception and not the rule, so in my opinion, I still don't think allowing AP by default is wrong. Even in the worse case scenario, where a computer doesn't finish on time, the task will simply be sent to another machine so no science is lost. BOINC has this fail safe built in, so it isn't as big an issue as it would seem.

Even in the worse case scenario, where a computer doesn't finish on time, the task will simply be sent to another machine so no science is lost. BOINC has this fail safe built in, so it isn't as big an issue as it would seem.

You are correct that it is not a big issue for the project (As you point out - no science is lost).

However I beleive it IS a big issue for the cruncher, who has just spent a whole month donating his crunchtime, just to have it tipped down the drain because your machine is capable of doing this amount of work even if you dont wish to donate that much.

BTW Did you notice the correction to the figures of my last post. According to my calcs AP requires 20-30 x work/time depending on host.

What messes everything up is that most computers can do SETI MB rather efficiently, and the Task Duration Correction Factor is geared toward MB. Then you have AP come along that takes much longer, and the TDCF (or DCF for short) is suddenly out of whack. So a computer for which the BOINC scheduler thinks it can complete a AP task within the time allowed downloads a workunit only to find that it probably can't finish, but the work was downloaded and BOINC will try to finish it anyway.

If it were possible, there should have been a separate DCF for MB and AP so that BOINC's scheduler doesn't think the computer is more efficient than it really is.

I understand Einstein are also looking at a 2nd app (PALFA search, something along the lines of AP), so even more reason why BOINC should maintain a seperate DCF for each app within a project. It would also help in the case of CUDA and non-CUDA apps on the same box. Eg if I had Seti MB 6.03 (cpu), Seti MB 6.05 (gpu) and Seti AP 5.00 (cpu). I'll go have a look and see if anyone has raise a Trak ticket regarding this.

---

BOINC blog

Ageless wrote:

...
To update to 6.4.5, which does do CUDA, you'd have to see the warning about it on the download page...

There is no warning on the download page. There is this:

Note: if your computer is equipped with an NVIDIA Graphics Processing Unit (GPU), you may be able to use it to compute faster.

A skeptical user may be able to see a warning in that, most won't.

                                                                 Joe

I'll go have a look and see if anyone has raise a Trak ticket regarding this.

Doesn't look like anyone has asked for it so I have raise Trak ticket 812.

---

BOINC blog

Even in the worse case scenario, where a computer doesn't finish on time, the task will simply be sent to another machine so no science is lost. BOINC has this fail safe built in, so it isn't as big an issue as it would seem.

You are correct that it is not a big issue for the project (As you point out - no science is lost).

However I beleive it IS a big issue for the cruncher, who has just spent a whole month donating his crunchtime, just to have it tipped down the drain because your machine is capable of doing this amount of work even if you dont wish to donate that much.

Well, its not necessarily down the drain. As long as the host returns the WU before the other person does (with a new one month deadline - not that it will necessarily be a month before they turn it in), then the cruncher still gets credit for it.

But I get what you're saying. However, wasn't that the same case for SETI Classic? When I first joined up with Classic, I did not realize how long it was going to take for one of my machines, an AMD K6 166 to finish a single workunit, so I started leaving it on all the time. Though there was no deadline for the workunit, for all I knew the workunit could have already been crunched and I was providing busy work for the project because they could have ran dry during certain periods, all to increase my stats. This would be just as wasteful of electricity.

Its great that so many people are trying to be more "green" these days, but I can't quite seem to fathom the (IMO) excessive concern over infrequent and unfortunate events. Surely there have been far greater wastes of resources in our entire human history that we shouldn't get too upset over something like this?

But that's just my viewpoint on the subject.

BTW Did you notice the correction to the figures of my last post. According to my calcs AP requires 20-30 x work/time depending on host.

Yes, I did.

I'll go have a look and see if anyone has raise a Trak ticket regarding this.

Doesn't look like anyone has asked for it so I have raise Trak ticket 812.

I see there is a response to your requset:

12/27/08 19:17:03 changed by Nicolas ¶

I agree. But note David Anderson wrote in a different ticket:

DCF is a kludge to compensate for bad FLOP estimates by projects. I don't want to make the kludge even more complicated.

Which makes me wonder if Dr.A is actually on this planet.
When testing AP on Beta site before its release here, I noticed that Pappa's X2 6000+ and my Q6600 had similar benchmarks. From that Dr. A would assume that performance on AP tasks was similar, when it fact my computer was over twice as fast as Pappa's. Therefore with Dr.A's totally meaningless benchmarks in the BOINC client, the DCF is not a kludge but an absolute necessity.