Question:

I have a machine running SETI with a 960/950 combo. I'm running the Lunatics apps, no CPU tasks.

I have another system with an AMD 7970 in it, doing Einstein GPU work only.

If I were to reverse the assigned projects, on E@H the RAC would be a small loss. Would the swap be worthwhile on the SETI side?

---

Question:

I have a machine running SETI with a 960/950 combo. I'm running the Lunatics apps, no CPU tasks.

I have another system with an AMD 7970 in it, doing Einstein GPU work only.

If I were to reverse the assigned projects, on E@H the RAC would be a small loss. Would the swap be worthwhile on the SETI side?

I think you are asking the wrong question. IF RAC was really linear to science done, yes you could look at RAC (per project) to ask that question ('what's more effective') For E@H, with their fixed credits, that's indeed the case. Here, were RAC isn't a direct measurement of throughput, you get a less clear answer.

Being a scientist, I'd just run the experiment ;) Probably the AMD will be better here as the NV cards aren't (currently) that good at processing the VLAR we are getting. But unless somebody can give you an approximate figure on your 7970, I'd just swap and see what I get. And remember RAC takes a looong time to stabilise going up.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

I have a recent Windows 10 PC with a Geforce GTX 750 OC running Einstein@home GPU tasks with CUDA55. On this older Linux box I have a AMD/ATI HD 7770 running SETI@home and SETI Beta GPU tasks with OpenCl 1.2,with good results.
Tullio

---

re:

a solution to allow GUPPI VLAR GPU work units to be refused in the Project Prefs. is being worked on...

Since I posted this, I've been more and more mystified by one facet of it:

It was indicated that this was tried on Beta and the result was no GPU work at all, which is why it isn't already implemented here. However, the code to do this here was already in place and was working properly before (as we had no GUPPI work on NVidia for weeks)... it just needs to be put back to the way it was, with one added check for the participant's profile setting added.

---

re:

a solution to allow GUPPI VLAR GPU work units to be refused in the Project Prefs. is being worked on...

Since I posted this, I've been more and more mystified by one facet of it:

It was indicated that this was tried on Beta and the result was no GPU work at all, which is why it isn't already implemented here. However, the code to do this here was already in place and was working properly before (as we had no GUPPI work on NVidia for weeks)... it just needs to be put back to the way it was, with one added check for the participant's profile setting added.

. . But is that option to refuse all GPU based Guppi WU's? It would be effective but a little drastic.

. . But is that option to refuse all GPU based Guppi WU's? It would be effective but a little drastic.

That may be, but it would offer an alternative to those who are aborting GUPPI work units by the thousands, which is far more drastic. And since the SAH team is apparently working on it, it's "approved".

---

My 7990 can do 2 guppies in effectively 7-8 minutes each when running 2 at a time. Should be much more efficient than running them on your 960/950...

Chris

Question:

I have a machine running SETI with a 960/950 combo. I'm running the Lunatics apps, no CPU tasks.

I have another system with an AMD 7970 in it, doing Einstein GPU work only.

If I were to reverse the assigned projects, on E@H the RAC would be a small loss. Would the swap be worthwhile on the SETI side?

I think you are asking the wrong question. IF RAC was really linear to science done, yes you could look at RAC (per project) to ask that question ('what's more effective') For E@H, with their fixed credits, that's indeed the case. Here, were RAC isn't a direct measurement of throughput, you get a less clear answer.

Being a scientist, I'd just run the experiment ;) Probably the AMD will be better here as the NV cards aren't (currently) that good at processing the VLAR we are getting. But unless somebody can give you an approximate figure on your 7970, I'd just swap and see what I get. And remember RAC takes a looong time to stabilise going up.

---

My 7990 can do 2 guppies in effectively 7-8 minutes each when running 2 at a time. Should be much more efficient than running them on your 960/950...

Chris

Wow, I am going to take it that this is an AMD thing then? I have heard that there is something about the Nvidia design that makes these cards choke on those WU's, and I think it is an architectural issue, not so much a driver one? If that is true (may not be remembering that 100% correctly, please anyone chime in to correct me), then that is a bummer for all us NV owners, esp since Guppies are going to be much more prevalent in the near future as a % of work, from what I've gathered reading around here.

---

Al,

I think you are counting out the Nvidia cards too early

Al,

I think you are counting out the Nvidia cards too early

Have to agree in part. It has to be realised that we developers have different focus and strengths, which constantly change. Try to assess either on now (which looks dismal all around since the new work) or on future expectations. So many unknowns means either an exciting adventure or gruelling drudge, depending on your personal perspective. None of these brands are thinking about you personally or Seti@home, so it becomes a matter of dismissing fanboyism, and going the hard yards by ourselves.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

So, out of sheer ignorance, I might have done the right thing in assigning Einstein@home GPU tasks to a nVidia/CUDA55 GPU board on a Windows 10 PC with a fast CPU and SETI/SETI Beta tasks to an AMD/ATI 7770 board with OpenCl 1.2 and a slower CPU on a Linux host.
Tullio

---

So, out of sheer ignorance, I might have done the right thing in assigning Einstein@home GPU tasks to a nVidia/CUDA55 GPU board on a Windows 10 PC with a fast CPU and SETI/SETI Beta tasks to an AMD/ATI 7770 board with OpenCl 1.2 and a slower CPU on a Linux host.
Tullio

sounds good to me (obviously sans actual metrics)

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Well, for the most part I consider myself fairly optimistic, at least try to be, but I guess the thing that got me down a little was the possible fact that the issues appear to be hardware and not driver related. Drivers (i.e. software) are (relatively) easy to fix if there are serious issues. Hardware, on the other had, requires a new revision of the GPU, and we all know how likely that is to happen.

But, maybe things aren't as dismal as I'm assuming, and I am going to let the people with fabulous skills, who actually find fixing these kinds of issues enjoyable (God Bless Them!) have at it, and then try to follow the words of wisdom one Mr. Bob Marley said; "Dontcha worry, 'bout a thing, cause Every Little Thing, is gonna be alright!" Keep up the great work, guys, you are respected and appreciated. Hope you don't forget that!

---

Well, for the most part I consider myself fairly optimistic, at least try to be, but I guess the thing that got me down a little was the possible fact that the issues appear to be hardware and not driver related. Drivers (i.e. software) are (relatively) easy to fix if there are serious issues. Hardware, on the other had, requires a new revision of the GPU, and we all know how likely that is to happen.

But, maybe things aren't as dismal as I'm assuming, and I am going to let the people with fabulous skills, who actually find fixing these kinds of issues enjoyable (God Bless Them!) have at it, and then try to follow the words of wisdom one Mr. Bob Marley said; "Dontcha worry, 'bout a thing, cause Every Little Thing, is gonna be alright!" Keep up the great work, guys, you are respected and appreciated. Hope you don't forget that!

Interesting Al. It's usually the software, firmware and drivers that frustrate me. Could be an interesting future debate :D

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Thanks for the info. I just remembered I have a free AMD 7750 whose performance relative to the 7970 I am familiar with. I'm going to run some SETI tasks on that as a test while I wait for E@H units on the 7970 to complete.

---

Well, for the most part I consider myself fairly optimistic, at least try to be, but I guess the thing that got me down a little was the possible fact that the issues appear to be hardware and not driver related. Drivers (i.e. software) are (relatively) easy to fix if there are serious issues. Hardware, on the other had, requires a new revision of the GPU, and we all know how likely that is to happen.

But, maybe things aren't as dismal as I'm assuming, and I am going to let the people with fabulous skills, who actually find fixing these kinds of issues enjoyable (God Bless Them!) have at it, and then try to follow the words of wisdom one Mr. Bob Marley said; "Dontcha worry, 'bout a thing, cause Every Little Thing, is gonna be alright!" Keep up the great work, guys, you are respected and appreciated. Hope you don't forget that!

Interesting Al. It's usually the software, firmware and drivers that frustrate me. Could be an interesting future debate :D

Oh, believe me, Jason, I am more than certain that all 3 items are exceedingly frustrating to work with, absolutely! My thought though is that bits and bytes can eventually be fixed with enough effort and dedication, but issues with the hardware itself are permanent, and if the software can't find a way around them, then whatever hard earned cash that has been spent on said card, has at least in part been wasted, because the only thing you can do at that point to fix it is to buy the latest, and (hopefully) fixed one. That's kind of where I was coming from. Not saying at all that SW issues aren't a bugger, I know they are. They are just a lot more repairable than hardware ones are.

---

I had a look at 30-40 AMD GPU machines' tasks, and as far as I can tell, it looks as though new AMDs are similarly affected. I was unable to find any that didn't take 2-4x as long to complete a GUPPI VLAR work unit. This includes with and without SoG. Maybe I just didn't look in the right place, so if anyone has any URLs otherwise they would be welcome.

Old AMDs I saw were very slow but they were consistently very slow with the VLARs, and this would reinforce that it's an issue with the VLAR results exceeding cache size, as the old cards would have hardly any cache so both VLAR and non-VLAR work would exceed it so have about the same runtimes.

If correct, this would seem to imply that the only resolution for this is going to be a workaround redesign of the pulsefinding algorithm, if this is even possible.

---

1 Credit or 1,000,000 RAC. Wat's Da Bigggeee?

I Wasted a lot of time and money tryin' to get Classic WUs.

For What? If ET is IN THERE SOMEWHERE, I'll Be Long Dead by Time Found.

More Likely ET will Park on WH Lawn and Say Hi, before A 'Signal' will be Discovered.

A Billion Plus Total Credit or 4.3 Million. Why Would Any Amount give me A GOoD Feeling?

All Da Same.

Yappin' at ET. No Response.

---

May we All have a METAMORPHOSIS. REASON. GOoD JUDGEMENT and LOVE and ORDER!!!!!

If correct, this would seem to imply that the only resolution for this is going to be a workaround redesign of the pulsefinding algorithm, if this is even possible.

Correct. Most definitely possible (even likely), but we're talking Manhattan Project, as opposed to Archimedes running down the street in the nude.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Now theres a visual I could do without...

---