Everyone knows credit screw is crap , people leaving the project coz they can get more credit elsewhere says a lot about them people . I don't give a shi#e if you want to have a go at me bring it on , just saying what I think if you don't like it that's your problem not mine !!!

Only the beaten dogs bark...

---

Aloha, Uli

Why do people keep saying there is a design flaw.

Maybe I wasn't clear in my original statement - I meant there was a design flaw in the CODE, not the hardware. If you know hardware has certain characteristics, you should code with that in mind, not just implement an algorithm that (maybe) doesn't take hardware quirks into account.

In the case at hand, if the AR affects how the code executes time-wise (as it does), than that should be compensated for (as much as possible) in the implementation actually coded. Just as the Lunatics code is written to work differently on different implementations of hardware in the CPUs. THAT is what I meant... and that's why I called it a design flaw. Anybody remember the old Pentium FDIV bug? It could be coded around, once it was known.

Anyway, it really bothers me that my nice 980s are basically producing much less results for the current they are drawing (about 1/4 of previous), so I am experimenting with a 32-thread machine to replace at least one of my crunchers, When that is up and running, I will likely return, after maybe selling my GPUs. Yes, they still produce more work than CPU cores, but not enough, it would seem, to justify the electricity expense - the 980 draws around 150 watts while running 3 WUs at a time, and an 8c/16t CPU around 115. So no longer is the 980 justifiable, at least until the code is fixed.

I would agree with many of those points in principle, and in fact I see Raistmer, Petri, and myself all searching for ways to better handle these new tasks (probing from different directions, each finding our own set of new issues).

What can be easily missed in this, is the level of optimisation you're seeking (akin to, for example, the CUFFT library and the like) is very costly, in manpower and time, something the project itself has not had the resources to do on its own, even for the stock CPU apps.

In this particular GPU case, It's 'simply' a poor match of Seti's pulsefinding algorithm to the hardware. The stark (or grim) reality is, for this unique pulsefinding code, more than 'simple' attention to microarchitectural-optimisation/scaling/streaming is required, but in fact a replacement algorithm outright.

This unfortunately takes mathematical proofs (language/device agnostic models) that tend to venture outside realistic resources, especially given many of those that performed the original CPU pulsefinding vectorisations/optimisations have moved on, and left little to no documentation.

So your frustration is justified, and we're all left carrying the can of worms that the rush to v8 and nvidia's fairly rushed/crude implementation (with only minor polish applied in those areas) have created. Some practical intermediate solutions do exist, though none of them the simple tweaks/bugfixes sometimes implied.

What is going to help, is those that have the skills and time, pitch in with solutions. I know in my case (Can't speak for the others) I have some 7 years of research, and options to explore, though sadly near zero time at the moment. Best temporary measure IMO, is to crunch the Guppi/VLARs on the device that does them most efficiently (Usually CPU). Correctness (which has been non-trivial) comes first, then efficiency after.

Too bad there's a perfect storm of new tasks/apps, new hardware, new driver models, and for me no time. Fingers crossed one or more of us can polish off the algorithm design books in time, though the uniqueness of this one I feel is going to take a fair bit more than 'just a bit of optimisation'

---

"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.

Why do people keep saying there is a design flaw.

Maybe I wasn't clear in my original statement - I meant there was a design flaw in the CODE, not the hardware. If you know hardware has certain characteristics, you should code with that in mind, not just implement an algorithm that (maybe) doesn't take hardware quirks into account.

In the case at hand, if the AR affects how the code executes time-wise (as it does), than that should be compensated for (as much as possible) in the implementation actually coded. Just as the Lunatics code is written to work differently on different implementations of hardware in the CPUs. THAT is what I meant... and that's why I called it a design flaw. Anybody remember the old Pentium FDIV bug? It could be coded around, once it was known.

Anyway, it really bothers me that my nice 980s are basically producing much less results for the current they are drawing (about 1/4 of previous), so I am experimenting with a 32-thread machine to replace at least one of my crunchers, When that is up and running, I will likely return, after maybe selling my GPUs. Yes, they still produce more work than CPU cores, but not enough, it would seem, to justify the electricity expense - the 980 draws around 150 watts while running 3 WUs at a time, and an 8c/16t CPU around 115. So no longer is the 980 justifiable, at least until the code is fixed.

It seems you are asking for an app that executes different code deepening on the AR of the task. To my knowledge none of the applications do this. If you would care to fund a full time application development I'm sure we could have apps optimized for every situation & hardware revision.
My R9 390X is less efficient than my i5-4690K when doing normal AR tasks. So I don't have it configured to run MB work on the GPU. Because I rather use my computing power as efficiently as possible. I haven't compared how each runs GBT data yet, but if the GBT VLARs are more efficient on the GPU they would defiantly be run there on my system. VLARs were never much of a problem for my Radeon GPUs.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

It seems you are asking for an app that executes different code deepening on the AR of the task. To my knowledge none of the applications do this. If you would care to fund a full time application development I'm sure we could have apps optimized for every situation & hardware revision.
My R9 390X is less efficient than my i5-4690K when doing normal AR tasks. So I don't have it configured to run MB work on the GPU. Because I rather use my computing power as efficiently as possible. I haven't compared how each runs GBT data yet, but if the GBT VLARs are more efficient on the GPU they would defiantly be run there on my system. VLARs were never much of a problem for my Radeon GPUs.

Actually all the GPU builds (afaik, Raistmer can correct me on his) dispatch to different GPU code depending on the lengths of the pulsefinds (strongly connected with AR). They have tuning parameters mostly targeted at minimising display lag (rather than speed), and various levels of microarchitectural optimisation. It is looking like those optimisations (where applied) are insufficient, and that a replacement pulsefinding algorithm (as opposed to code) is what's needed, redesigned to cope with the new demands.

---

"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.

It seems you are asking for an app that executes different code deepening on the AR of the task. To my knowledge none of the applications do this. If you would care to fund a full time application development I'm sure we could have apps optimized for every situation & hardware revision.
My R9 390X is less efficient than my i5-4690K when doing normal AR tasks. So I don't have it configured to run MB work on the GPU. Because I rather use my computing power as efficiently as possible. I haven't compared how each runs GBT data yet, but if the GBT VLARs are more efficient on the GPU they would defiantly be run there on my system. VLARs were never much of a problem for my Radeon GPUs.

Actually all the GPU builds (afaik, Raistmer can correct me on his) dispatch to different GPU code depending on the lengths of the pulsefinds (strongly connected with AR). They have tuning parameters mostly targeted at minimising display lag (rather than speed), and various levels of microarchitectural optimisation. It is looking like those optimisations (where applied) are insufficient, and that a replacement pulsefinding algorithm (as opposed to code) is what's needed, redesigned to cope with the new demands.

I had read your previous post right after I had posted mine. Whipping up a new algorithm should be easy enough. At least for someone with degrees in mathematics, computer science, & possibly astronomy as well.

For the moment it sounds like we are in this situation

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Pretty much, lol, or, "She's holding together by the skin of her teeth Captain"
I'm just glad we're not trying to breathe in hard vacuum at the moment.

---

"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.

I may have a solution for solving the effect that credit screw is having on some people's motivations for the project. Instead of re-writing the calculation code why not simply provide a freeform data entry field to allow people to enter their own RAC?
That way the folks that feel that credit is an important part of their endeavour here can enter a value that they would feel happy with?

---

I may have a solution for solving the effect that credit screw is having on some people's motivations for the project. Instead of re-writing the calculation code why not simply provide a freeform data entry field to allow people to enter their own RAC?
That way the folks that feel that credit is an important part of their endeavour here can enter a value that they would feel happy with?

LOL....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Greetings,

Has it ever occurred to those with extremely high RACs and 10s or 100s of millions of credits that those with a low RAC and less than say 10 million credits do not feel they are contributing as much as those previously mentioned? No? Didn't think so. :(

I'm not speaking for myself here, I'm speaking for those being ridiculed.

Nuf sed... :|

Keep on BOINCing...! :)

[edit]And that is another reason I've been thinking of taking a break. People telling others basically: "Don't let the door hit you on the a$$ on your way out."[/edit]

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

I don't think I was ridiculing anybody.

I simply said that if folks wish to leave the Seti project for another in the hunt for a better RAC, that is their personal decision.
And I also added that other Boinc projects are worthy as well.

However, whatever the current situation here regarding hard to crunch Guppi work and declining RACs......

I am not going anywhere else.

Meow!

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Well, I'm glad to see that I'm NOT alone in my thinking. :-)

Several days ago, I posted this in the LPTPW Thread in the Cafe:

"One PC vs three.", Zoom314, Vic.

Well, I don't have three machines; I have two of my own machines, (Prometheus/Andromeda, and Exeter.) Andromeda, (the MAC with GTX-750 TI SC), and Exeter, (XP Pro x64 with GTX-760), are currently both crunching Einstein. I made the switch to Einstein after my RAC here dropped to 11 + K for no apparent real reason other than the problems with CreditNew... (See Number Crunching...)

Farragut, (my parents' HP Desktop system with Intel HD 530 integrated GPU), only seldom crunches SETI. Dad refuses to let it run during the day when he's not here, and mom just checks e-Mail and social sites. So, Farragut might be on one or two days a week...

In the past 4 days of crunching Einstein, my RAC there has shot up to 38 + K... A considerable difference! Highest I've been here, (prior to V8 work), was 18 + K. While I'm NOT a credit hound per se; I MUST justify the electricity usage to dad - numbers are key...

When CreditNew gets properly fixed/adjusted/replaced I will resume crunching SETI full time. (Yes this is a formal protest!)

If I don't see any of you here when my RAC reaches infinitesimal numbers, (1 or 0), just know that I will be thinking of you all, and missing you. I've crunched hard for SETI for just over ten years. CreditNew is the WORST thing to have happened to the Project. V8 work just shows the error more pronounced.

God bless everyone.


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

And still no official direction from management. Waiting.........

All the best,
Aaron Lephart

---

Simple fact of the matter (and a lot of folks are in denial about this) the software the project issues us with does not work correctly with VLAR's or at the very least is extremely inefficient.

---

I believe Jason you may be the first person I've seen on these boards from the developer side actually speak sense about this issue.


Jason Gee wrote:

Actually all the GPU builds (afaik, Raistmer can correct me on his) dispatch to different GPU code depending on the lengths of the pulsefinds (strongly connected with AR). They have tuning parameters mostly targeted at minimising display lag (rather than speed), and various levels of microarchitectural optimisation. It is looking like those optimisations (where applied) are insufficient, and that a replacement pulsefinding algorithm (as opposed to code) is what's needed, redesigned to cope with the new demands.

---

since my ati doesn't have that problem, can the ati app run on nvidia?

if this question is too stupid to answer, please ignore and save keystrokes

since my ati doesn't have that problem, can the ati app run on nvidia?

if this question is too stupid to answer, please ignore and save keystrokes

It actually does with some required changes.

---

With each crime and every kindness we birth our future.

my ati takes about 11 minutes for a vlar with minimal cpu usage

i can understand how annoying it would be if a vlar took an hour and pegged the cpu and affected the display

so the question would be if running the ati app on nvidia would fix anything at all

my ati takes about 11 minutes for a vlar with minimal cpu usage

i can understand how annoying it would be if a vlar took an hour and pegged the cpu and affected the display

so the question would be if running the ati app on nvidia would fix anything at all

All I've heard from people trying certain things, is there are Pros and Cons to everything so far, so no 'Óne Size Fits All' solutions. Naturally that's a continuously changing picture though, so anything someone (including myself) says today may not be applicable next week, for example.

For my small part, what I tend to do is watch, wait, and try to figure out what will make things work 'simply'. Sometimes that pays off big, sometimes it doesn't. To me in this case it's looking like we have our first really complex problem to solve since I've been here, and we need to think about a 'Manhattan Project' style approach over diddling with existing apps and settings.

---

"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.

my ati takes about 11 minutes for a vlar with minimal cpu usage

i can understand how annoying it would be if a vlar took an hour and pegged the cpu and affected the display

so the question would be if running the ati app on nvidia would fix anything at all

All I've heard from people trying certain things, is there are Pros and Cons to everything so far, so no 'Óne Size Fits All' solutions. Naturally that's a continuously changing picture though, so anything someone (including myself) says today may not be applicable next week, for example.

For my small part, what I tend to do is watch, wait, and try to figure out what will make things work 'simply'. Sometimes that pays off big, sometimes it doesn't. To me in this case it's looking like we have our first really complex problem to solve since I've been here, and we need to think about a 'Manhattan Project' style approach over diddling with existing apps and settings.

What about a straight fixed Credit per WU. Einstein has MORE WU Types than SETI, yet they manage a Fixed Credit System for each WU Type. Certainly that plan can be implemented here.

In 6 Days of crunching Einstein, I'm now at 57 + K RAC!!! Certainly, this Fixed Credit System they've implemented bears merit to be looked at to be used here.


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

my ati takes about 11 minutes for a vlar with minimal cpu usage

i can understand how annoying it would be if a vlar took an hour and pegged the cpu and affected the display

so the question would be if running the ati app on nvidia would fix anything at all

All I've heard from people trying certain things, is there are Pros and Cons to everything so far, so no 'Óne Size Fits All' solutions. Naturally that's a continuously changing picture though, so anything someone (including myself) says today may not be applicable next week, for example.

For my small part, what I tend to do is watch, wait, and try to figure out what will make things work 'simply'. Sometimes that pays off big, sometimes it doesn't. To me in this case it's looking like we have our first really complex problem to solve since I've been here, and we need to think about a 'Manhattan Project' style approach over diddling with existing apps and settings.

What about a straight fixed Credit per WU. Einstein has MORE WU Types than SETI, yet they manage a Fixed Credit System for each WU Type. Certainly that plan can be implemented here.

In 6 Days of crunching Einstein, I'm now at 57 + K RAC!!! Certainly, this Fixed Credit System they've implemented bears merit to be looked at to be used here.


TL

Funny thing about it is: the Credit is now appearing to be a smokescreen, and crushing every attempt to propose solutions like every time before. The automation/estimation component of CreditNew is there in Einstein too and critical. Fortunately they have (relatively) uniform applications+tasks, and last I checked single appversions per App, so therefore the fraudulent/broken normalisation components are not active. They get [fair] Cobblestone Scale Credit ( +/-)[ for equal work, which is entirely measurable and predictable on mass scales, read Asimov]. Naturally things could have changed since I last chatted with Bernd and Oliver and the consensus was the whole thing needed a rewrite.

[Edit:] Maybe they changed opinions since then, somehow I doubt it.

---

"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.