Actually It's in the apps Raistmer makes(but not all), It's not in any version of Boinc.

Don't bother Fred W, Yer blocked.

He does have a point. The application is intentionally throwing errors, and what BOINC does on an error was known beforehand.

The effort to "fix" this could/should go into the application itself to find out why the CUDA card does these slowly and address it there, not by returning work because it doesn't pay well enough.

I understand Nvidia did the port, and they'd likely be the best ones to fix it.

pay, smay, It just takes too damn long, Sure It should be done in the app, So far no one knows how to fix this I've read, Not a clue, So reassign the dumb things and allow the WU to be aborted by the app in question, Seti has already had a lot of users depart for various reasons, Do they need more to depart forever? Before something positive on the subject is done?

I've got an AP work unit which has 266 hours on it so far. I think it'll finish sometime tomorrow.

It's not a problem, it is the perception of a problem.

My question is: is there a problem, or are people leaving because of the constant complaining?

I don't do AP, AP is and has been set for a good while to OFF.

Yer tryin to do an Apples to Oranges comparison, AP is not true Seti, Only Seti is Seti.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

As it happens, I had an email today from the nVidia developer who did a major part of the port. He said:

I am aware of the VLAR sluggishness and have spent some time trying different way to resolve it given the current pulse detection algorithm with not much luck. The bottom line is that when using CUDA on the same GPU that also used as the graphical display, it is difficult to prioritize one type of GPU client over another on the current HW architecture. SETI@home is not alone, this issue can affect any CUDA application that demands high amounts of time from CUDA.

That adds an interesting question: is there a way to reduce the "graphics" demand on the card if the owner is mostly interested in crunching.

Setting the display to the minimum resolution and the minimum color depth might make a difference -- and would be an interesting experiment.

I wonder if some of the same kind optimizations (rearranging execution order) that help the CPU apps would help the GPU apps.

---

As it happens, I had an email today from the nVidia developer who did a major part of the port. He said:

I am aware of the VLAR sluggishness and have spent some time trying different way to resolve it given the current pulse detection algorithm with not much luck. The bottom line is that when using CUDA on the same GPU that also used as the graphical display, it is difficult to prioritize one type of GPU client over another on the current HW architecture. SETI@home is not alone, this issue can affect any CUDA application that demands high amounts of time from CUDA.

That adds an interesting question: is there a way to reduce the "graphics" demand on the card if the owner is mostly interested in crunching.

Setting the display to the minimum resolution and the minimum color depth might make a difference -- and would be an interesting experiment.

I wonder if some of the same kind optimizations (rearranging execution order) that help the CPU apps would help the GPU apps.

So far I think their trying to limit the amount of ram the app can use to about 220MB, But I don't know how effective they are at that yet, Oh and each half of My 295 is 896MB or 1792MB, I use the computer nearly constantly as I'm around a lot, So If I used the stock(sic) cuda app I'd have to discontinue It as I wouldn't be able to post here as the apps and the VLARs can use a lot more than 220MB of DDR3 ram. Either find a way to limit the ram usage or reallocate the WU to the cpu where It won't be noticed, Otherwise Why should I crunch for anybody?

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

As it happens, I had an email today from the nVidia developer who did a major part of the port. He said:

I am aware of the VLAR sluggishness and have spent some time trying different way to resolve it given the current pulse detection algorithm with not much luck. The bottom line is that when using CUDA on the same GPU that also used as the graphical display, it is difficult to prioritize one type of GPU client over another on the current HW architecture. SETI@home is not alone, this issue can affect any CUDA application that demands high amounts of time from CUDA.

That adds an interesting question: is there a way to reduce the "graphics" demand on the card if the owner is mostly interested in crunching.

Setting the display to the minimum resolution and the minimum color depth might make a difference -- and would be an interesting experiment.

I wonder if some of the same kind optimizations (rearranging execution order) that help the CPU apps would help the GPU apps.

Reminds me of hybrid sli.

Actually It's in the apps Raistmer makes(but not all), It's not in any version of Boinc.

Don't bother Fred W, Yer blocked.

He does have a point. The application is intentionally throwing errors, and what BOINC does on an error was known beforehand.

The effort to "fix" this could/should go into the application itself to find out why the CUDA card does these slowly and address it there, not by returning work because it doesn't pay well enough.

I understand Nvidia did the port, and they'd likely be the best ones to fix it.

pay, smay, It just takes too damn long, Sure It should be done in the app, So far no one knows how to fix this I've read, Not a clue, So reassign the dumb things and allow the WU to be aborted by the app in question, Seti has already had a lot of users depart for various reasons, Do they need more to depart forever? Before something positive on the subject is done?

I've got an AP work unit which has 266 hours on it so far. I think it'll finish sometime tomorrow.

It's not a problem, it is the perception of a problem.

My question is: is there a problem, or are people leaving because of the constant complaining?

I don't do AP, AP is and has been set for a good while to OFF.

Yer tryin to do an Apples to Oranges comparison, AP is not true Seti, Only Seti is Seti.

No, I'm comparing minutes to minutes.

As far as I can tell, your complaint is that some CUDA takes longer than others. If you don't care about credit, then it's just runtime.

---

As it happens, I had an email today from the nVidia developer who did a major part of the port. He said:

I am aware of the VLAR sluggishness and have spent some time trying different way to resolve it given the current pulse detection algorithm with not much luck. The bottom line is that when using CUDA on the same GPU that also used as the graphical display, it is difficult to prioritize one type of GPU client over another on the current HW architecture. SETI@home is not alone, this issue can affect any CUDA application that demands high amounts of time from CUDA.

That adds an interesting question: is there a way to reduce the "graphics" demand on the card if the owner is mostly interested in crunching.

Setting the display to the minimum resolution and the minimum color depth might make a difference -- and would be an interesting experiment.

I wonder if some of the same kind optimizations (rearranging execution order) that help the CPU apps would help the GPU apps.

Reminds me of hybrid sli.

From what I've read Hybrid SLI has been discontinued by Nvidia.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

My question is: is there a problem, or are people leaving because of the constant complaining?

I doubt people are leaving just because of the complaining.

I would have sympathy with people who leave because they are confused by the plethora of threads, acronyms, in-jokes, technical jargon and conflicting advice - such as skildude's absurd suggestion earlier in this thread that "BOINC 6.6.20 already has the VLAR killer in it". No it doesn't, and never will do: BOINC versions don't have project-specific workrounds in them.

I would also have sympathy with a new user who leaves after receiving the stock AP application and an AP task as their first experience of SETI. Without calm, clear advice that the initial estimate is overstated by roughly 2.5 times - AP on a Core2 class processor is deliberated designed for a target TDCF of 0.4 [there, I'm doing the technical jargon already] - and that the new user should at least watch the 'To completion' estimate for an hour or so before clicking the 'abort' button, my reaction might be the same.

My understanding is that the next version of Astropulse - currently in testing at Beta - will be deployed here in a way which ensures that AP will not be issued as the first task to a newly-joined host or user. That should help.

Actually It's in the apps Raistmer makes(but not all), It's not in any version of Boinc.

Don't bother Fred W, Yer blocked.

He does have a point. The application is intentionally throwing errors, and what BOINC does on an error was known beforehand.

The effort to "fix" this could/should go into the application itself to find out why the CUDA card does these slowly and address it there, not by returning work because it doesn't pay well enough.

I understand Nvidia did the port, and they'd likely be the best ones to fix it.

pay, smay, It just takes too damn long, Sure It should be done in the app, So far no one knows how to fix this I've read, Not a clue, So reassign the dumb things and allow the WU to be aborted by the app in question, Seti has already had a lot of users depart for various reasons, Do they need more to depart forever? Before something positive on the subject is done?

I've got an AP work unit which has 266 hours on it so far. I think it'll finish sometime tomorrow.

It's not a problem, it is the perception of a problem.

My question is: is there a problem, or are people leaving because of the constant complaining?

I don't do AP, AP is and has been set for a good while to OFF.

Yer tryin to do an Apples to Oranges comparison, AP is not true Seti, Only Seti is Seti.

No, I'm comparing minutes to minutes.

As far as I can tell, your complaint is that some CUDA takes longer than others. If you don't care about credit, then it's just runtime.

If It were not something that would interfere with normal video output or even lockup the PC and that would happen in the background like on a cpu, Then fine I don't care, But It does happen, Besides If the WU gets rejected cause there is no other official way to solve the problem then why exactly should the user be penalized???? And for that matter then Why should I waste My electricity and Money($$$) on Seti@Home If I'm going to be punished? If so then fine return My donation in full, Immediately or as soon as possible. As I will not make another donation ever again until this problem is fixed.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

My question is: is there a problem, or are people leaving because of the constant complaining?

I doubt people are leaving just because of the complaining.

I would have sympathy with people who leave because they are confused by the plethora of threads, acronyms, in-jokes, technical jargon and conflicting advice - such as skildude's absurd suggestion earlier in this thread that "BOINC 6.6.20 already has the VLAR killer in it". No it doesn't, and never will do: BOINC versions don't have project-specific workrounds in them.

I would also have sympathy with a new user who leaves after receiving the stock AP application and an AP task as their first experience of SETI. Without calm, clear advice that the initial estimate is overstated by roughly 2.5 times - AP on a Core2 class processor is deliberated designed for a target TDCF of 0.4 [there, I'm doing the technical jargon already] - and that the new user should at least watch the 'To completion' estimate for an hour or so before clicking the 'abort' button, my reaction might be the same.

My understanding is that the next version of Astropulse - currently in testing at Beta - will be deployed here in a way which ensures that AP will not be issued as the first task to a newly-joined host or user. That should help.

The part that bothers me most is the fact that people seem to have such wild expectations.

The project discloses a number of things right off the bat, like the fact that they will be out of work at times. We then see people complaining loudly that the project is out of work.

They build machines that crunch incredibly fast (and spend real money on them) and then complain that the project can't keep their cache full.

I understand the complaints, but the project is not to blame for the project doing what it said it would do.

I think it's all about expectations. If people see what they expect, they'll stay. If people come in with unreasonable expectations, they'll be disappointed and they'll leave.

I crunch beta (AP & MB) using their stock apps. AP 5.05 is a lot faster.

---

As it happens, I had an email today from the nVidia developer who did a major part of the port. He said:

I am aware of the VLAR sluggishness and have spent some time trying different way to resolve it given the current pulse detection algorithm with not much luck. The bottom line is that when using CUDA on the same GPU that also used as the graphical display, it is difficult to prioritize one type of GPU client over another on the current HW architecture. SETI@home is not alone, this issue can affect any CUDA application that demands high amounts of time from CUDA.

That adds an interesting question: is there a way to reduce the "graphics" demand on the card if the owner is mostly interested in crunching.

Setting the display to the minimum resolution and the minimum color depth might make a difference -- and would be an interesting experiment.

I wonder if some of the same kind optimizations (rearranging execution order) that help the CPU apps would help the GPU apps.

There are two problems with the VLAR tasks.

1) They take absolutely ages

2) If they are running on the GUI GPU, they cause sluggishness and lagging on the display and other applications using that display.

SJ's problem is with (1). I have every sympathy. I don't do VLAR on CUDA either - it's not worth it. But I use a more sophisticated workround - one developed, as it happens, by Fred W, who is too modest by half. SJ, you should learn who your friends are, and reconsider your decision not to listen to Fred W. You might learn something to your advantage.

Problem (1) is the hard one, and nobody seems to have a solution. Jason Gee is working on it - he found a reference today which may help: "WooHoo, Found it in Bailey's paper. "FFTs in External or Hierarchical Memory", David H. Bailey December 30, 1989. Ref: Journal of Supercomputing, vol. 4, no. 1 (March 1990), p. 23{35". But don't hold your breath.

The nVidia developer's concern - today - was with problem (2), the screen lag. He had a useful suggestion - make the new "don't use GPU while computer is in use" option in BOINC v6.6.20 apply only to GPU cards driving the user interface display - which I have forwarded to Eric and David. Watch this space, as they say.

From what I've read Hybrid SLI has been discontinued by Nvidia.

Realy? bummer.. was planing to get one when it's more developed.
Anyways, an additional $20 non CUDA-GPU might help?
Sadly, if someone has a system setup like that without having performance problems won't post here to verify my theory, right? =)
But buying another card would not be the best workaround.

And I don't know why people leave. What I know is that people seem to join when the movie "Contact" plays on tv. ^^ (maybe this is the case only in Germany)

---

During browsing berkeley's homepage I came along this statement that makes me say:
"ME!, ME!, ME!, wants to know, what patch was used and is it available for windows?"

If so then fine return My donation in full, Immediately or as soon as possible. As I will not make another donation ever again until this problem is fixed.

From a practical standpoint, the only way for the project to return your donation is probably for Eric or Dan to reach into their own pockets, and send you $20.

I'm sure this will be fixed "as soon as possible" but this is a very good follow-on to my earlier post.

"As soon as possible" can take a lot longer than some people expect.

---

My question is: is there a problem, or are people leaving because of the constant complaining?

I doubt people are leaving just because of the complaining.

I would have sympathy with people who leave because they are confused by the plethora of threads, acronyms, in-jokes, technical jargon and conflicting advice - such as skildude's absurd suggestion earlier in this thread that "BOINC 6.6.20 already has the VLAR killer in it". No it doesn't, and never will do: BOINC versions don't have project-specific workrounds in them.

I would also have sympathy with a new user who leaves after receiving the stock AP application and an AP task as their first experience of SETI. Without calm, clear advice that the initial estimate is overstated by roughly 2.5 times - AP on a Core2 class processor is deliberated designed for a target TDCF of 0.4 [there, I'm doing the technical jargon already] - and that the new user should at least watch the 'To completion' estimate for an hour or so before clicking the 'abort' button, my reaction might be the same.

My understanding is that the next version of Astropulse - currently in testing at Beta - will be deployed here in a way which ensures that AP will not be issued as the first task to a newly-joined host or user. That should help.

The part that bothers me most is the fact that people seem to have such wild expectations.

The project discloses a number of things right off the bat, like the fact that they will be out of work at times. We then see people complaining loudly that the project is out of work.

They build machines that crunch incredibly fast (and spend real money on them) and then complain that the project can't keep their cache full.

I understand the complaints, but the project is not to blame for the project doing what it said it would do.

I think it's all about expectations. If people see what they expect, they'll stay. If people come in with unreasonable expectations, they'll be disappointed and they'll leave.

I crunch beta (AP & MB) using their stock apps. AP 5.05 is a lot faster.

I don't complain about My cache, Right now I've got that rather useless setting set at 3 days and the PC on NNT as I have too much I think as Boinc will add more work to feed the gtx295(9 days becomes 14 and then that goes down to 10 as an example, But continue to go down to 3? Nope, Boinc doesn't even report stuff consistently with 6.6.20 and above, I thought 6.6.22 did, turns out It's no different). So I have manually update that and I don't really like that idea, Boinc may fix that in some future version I'd hope, But that's also a separate issue and since the main Boinc devs don't normally cruise around where I post, I digress.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Talking about "as soon as possible", the problem about VLARs running slow has been documented since my Beta report on 15 January - some three hours after v6.08 - the first to compute VLARs at all - was released for Beta download. If it could be fixed easily, it would have been done by now.

What makes it so important today?

As it happens, I had an email today from the nVidia developer who did a major part of the port. He said:

I am aware of the VLAR sluggishness and have spent some time trying different way to resolve it given the current pulse detection algorithm with not much luck. The bottom line is that when using CUDA on the same GPU that also used as the graphical display, it is difficult to prioritize one type of GPU client over another on the current HW architecture. SETI@home is not alone, this issue can affect any CUDA application that demands high amounts of time from CUDA.

That adds an interesting question: is there a way to reduce the "graphics" demand on the card if the owner is mostly interested in crunching.

Setting the display to the minimum resolution and the minimum color depth might make a difference -- and would be an interesting experiment.

I wonder if some of the same kind optimizations (rearranging execution order) that help the CPU apps would help the GPU apps.

There are two problems with the VLAR tasks.

1) They take absolutely ages

2) If they are running on the GUI GPU, they cause sluggishness and lagging on the display and other applications using that display.

SJ's problem is with (1). I have every sympathy. I don't do VLAR on CUDA either - it's not worth it. But I use a more sophisticated workround - one developed, as it happens, by Fred W, who is too modest by half. SJ, you should learn who your friends are, and reconsider your decision not to listen to Fred W. You might learn something to your advantage.

Problem (1) is the hard one, and nobody seems to have a solution. Jason Gee is working on it - he found a reference today which may help: "WooHoo, Found it in Bailey's paper. "FFTs in External or Hierarchical Memory", David H. Bailey December 30, 1989. Ref: Journal of Supercomputing, vol. 4, no. 1 (March 1990), p. 23{35". But don't hold your breath.

The nVidia developer's concern - today - was with problem (2), the screen lag. He had a useful suggestion - make the new "don't use GPU while computer is in use" option in BOINC v6.6.20 apply only to GPU cards driving the user interface display - which I have forwarded to Eric and David. Watch this space, as they say.

I think the solution is right in front of them and that idea is the right one(at least until a better one is implemented in code) and that not crunching on the gpu that does the screen will mean a lot of people with a single gpu on a card as their only gpu will be suddenly told sorry no crunching for You, We had a solution albeit temporary and rejected It out of hand as It isn't what We the project deems acceptable as We like stupid ideas just to piss people off. And that can be a lot of these cards:

GTX285
GTX275
GTX260
GTS250
9xxx
8xxx

As It would not stop a 295 card as It(the 295 would be only limited to 1 gpu out of 2 and that only includes the 1st card) is the only Nvidia card currently to have 2 gpus in a PCI-E slot(Even If It does take up two slots as do all GTX2xx series cards).

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Wow
So Much Heartache and Grief!

If I beat the dead horse it only has one more mile to run.... Then I am home...

Many of you have made valid points! It has been pointed to Admins and Nvidia...

Several of the users "here" are members of the Boinc Community (Alpha and Dev) and see things that are happening that they tell you about. They are also a prime source to get information into the group doing the developement. You are also allowed to if nothing else monitor those specific Email Lists. If you feel strongly enough about it you can Join. Then your voice is "one of those in the know." It just takes a bit of time reading.

ELSE; you have to rely on those "here" that look and do there. It is also one of the ways you can recieve the Volunteer Tester thing under your name.

Regards

Pappa

PPS: here I thought that my many years of Donations Threads was what was driving users away. After many hours of conversation with Eric on the subject, Users come and go. The hard part is that the reasons they come and go are not always obvious. Summer is coming and many will shutoff machines until fall (some will not come back)... That will surely mess with everyones Pending Credits (Oops you want me to return these?)....

---

Please consider a Donation to the Seti Project.

Clarification of My last post Only: So not crunching on the gpu that does the video is not a practical idea(It's a stupid idea really) I'd think as GTX295 cards are an expensive minority of CUDA capable cards, In which case only GTX295 Cards or those people with more than one CUDA capable card would crunch, The rest would just do video and no CUDA.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Clarification of My last post Only: So not crunching on the gpu that does the video is not a practical idea(It's a stupid idea really) I'd think as GTX295 cards are an expensive minority of CUDA capable cards, In which case only GTX295 Cards or those people with more than one CUDA capable card would crunch, The rest would just do video and no CUDA.

The option would be when the user is active. If the user is not active, then the system video slow downs would not be a problem.

---

BOINC WIKI

If You can't do this then return the $20 donation to Me.

You don't get to hold the project administrators hostage with your donation, period.

---

me@rescam.org

Clarification of My last post Only: So not crunching on the gpu that does the video is not a practical idea(It's a stupid idea really) I'd think as GTX295 cards are an expensive minority of CUDA capable cards, In which case only GTX295 Cards or those people with more than one CUDA capable card would crunch, The rest would just do video and no CUDA.

The option would be when the user is active. If the user is not active, then the system video slow downs would not be a problem.

It is still a stupid idea.


And I have plenty of work, Or at least the PC does.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's