project X pays much better

To solve this, simplest way is to make them not comparable.
This way users chose projects for their merit in their mind, not for credit.
Make them compete within the project if they WANT to.

The whole point of BOINC though was that they were meant to be comparable.

Well the big thing for me, credit/kibblestones aside, is it's all connected to task scheduling (estimates), and 99.9% of problems in scheduling and estimates are therefore just as wacky/frustrating (but obscured).

Can point to credits and say they don't matter until the cows come home, but when the chips are down Boinc is about task scheduling and estimating work, and I think we deserve state of the art. We will get that, if it takes me 3 years to setup a vanilla test project to make it happen.

---

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

project X pays much better

To solve this, simplest way is to make them not comparable.
This way users chose projects for their merit in their mind, not for credit.
Make them compete within the project if they WANT to.

The whole point of BOINC though was that they were meant to be comparable.

But, that concept was never enforced as a requirement of being a project under the Boinc umbrella.
So, projects have been allowed to hand out credits like candy in whatever fashion they wish to.
And with so much water under the dam, it is never going to be changed.

That is why I am rather proud of my Seti credits....they are very hard earned credits.

Meow.

Regulation/enforcement only works if you make something 'good', otherwise you just create more black markets and segmentation.

---

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

IIRC we have the same conversation few years ago when V7 apears and the diference V7 vs AP comes to a big number.

At that time Jason and some others makes a lot of test (eben with other projects) and the conclusion was simple: creditscrew is broken.

It´s penalizes optimization.

Aparently DA and his team never agree of that and makes nothing to correct it.

Now the history is repeated.

My 0.02 cents.

---

Well, since credit has (almost literally) fallen off a cliff in the last couple of weeks, I'll have no trouble with maintaining my current ranking for the foreseeable future. That's a plus, isn't it?

---

IIRC we have the same conversation few years ago when V7 apears and the diference V7 vs AP comes to a big number.

At that time Jason and some others makes a lot of test (eben with other projects) and the conclusion was simple: creditscrew is broken.

It´s penalizes optimization.

Aparently DA and his team never agree of that and makes nothing to correct it.

Now the history is repeated.

My 0.02 cents.

Agree. What we need to do is sack DA, he is a millstone around ever ones neck ...

---

This is something I just put over in the credit discussion on the BOINC forums:

What I see is that people stare themselves blind on the recent average credit (RAC) and when it goes down, they panic, even while their credit is still going up.

So I am wondering if we shouldn't just do something about the RAC. With the present CreditNew RAC is being calculated all wrong anyway, so isn't it easiest then to get rid of RAC?

It is at the moment no longer a value that shows how well your computer has been doing over a set length of time. So either fix it so it again is showing the progress your computer makes over a set length of time, or don't use RAC.

---

This is something I just put over in the credit discussion on the BOINC forums:

What I see is that people stare themselves blind on the recent average credit (RAC) and when it goes down, they panic, even while their credit is still going up.

So I am wondering if we shouldn't just do something about the RAC. With the present CreditNew RAC is being calculated all wrong anyway, so isn't it easiest then to get rid of RAC?

It is at the moment no longer a value that shows how well your computer has been doing over a set length of time. So either fix it so it again is showing the progress your computer makes over a set length of time, or don't use RAC.

I personally would prefer that it be repaired, as it can and should be a useful barometer of how one's computers are running.

---

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

I personally would prefer that it be repaired, as it can and should be a useful barometer of how one's computers are running.
____________

+1
Every time I look and see my rac dropping I keep thinking there's a problem then I remember Credit Screw

---

Life is what you make of it :-)

When i'm good i'm very good , but when i'm bad i'm shi#eloads better ;-) In't I " buttercups " p.m.s.l at authoritie !!;-)

I personally would prefer that it be repaired, as it can and should be a useful barometer of how one's computers are running.

It's a kindof sleight of hand by luddites, to suppose dismissing RAC or Credits will solve anything. This is since the measure of work drives the whole system, that is the estimation of how much work to send you, to process between project switches and indeed track your progress. Perhaps if this number were converted to Joules of Energy, or Kilograms of carbon (both quite doable), then the pressing needs, benefits and very real costs might be more relatable.

---

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

Every time I look and see my rac dropping I keep thinking there's a problem then I remember Credit Screw

Not the cause anymore... it's now due to your exclusively NVidia farm receiving GUPPI VLAR work units on the GPUs. As noted much elsewhere, they process much more slowly than Arecibo MBs but pay the same credit.

---

Every time I look and see my rac dropping I keep thinking there's a problem then I remember Credit Screw

Not the cause anymore... it's now due to your exclusively NVidia farm receiving GUPPI VLAR work units on the GPUs. As noted much elsewhere, they process much more slowly than Arecibo MBs but pay the same credit.

A bit more to it than that, but thumbs up :) [i.e. not a blame game, more of a cluster f***]

---

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

Every time I look and see my rac dropping I keep thinking there's a problem then I remember Credit Screw

Not the cause anymore... it's now due to your exclusively NVidia farm receiving GUPPI VLAR work units on the GPUs. As noted much elsewhere, they process much more slowly than Arecibo MBs but pay the same credit.

That's the main cause of my current decline....
20 NV GPUs having a nasty time with the Guppies.

---

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

Is it more of a driver issue (where we would have to wait for Nvidia to get their act together before there is any relief), the way that the Guppies are configured when they are split (something that can be addressed internally, though with the manpower crunch, is that likely anytime soon?), or something else that causes such a penalty for them on Nvidia hardware? Are things much better in the AMD world? I haven't ran a AMD card for probably 15+ years, so I basically have no experience with them.

---

Not this time Al :), we're digging into computer science territory now :)

---

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

Is it more of a driver issue (where we would have to wait for Nvidia to get their act together before there is any relief), the way that the Guppies are configured when they are split (something that can be addressed internally, though with the manpower crunch, is that likely anytime soon?), or something else that causes such a penalty for them on Nvidia hardware? Are things much better in the AMD world? I haven't ran a AMD card for probably 15+ years, so I basically have no experience with them.

I haven't checked the source code enough yet to know for sure, but I have a suspicion:

There's something in the CUDA framework that doesn't like that VLAR work units have negligibly small angular size. This should exclude them from even checking for Gaussians because the telescope is not crossing the signal which is what causes one, so any code which checks for Gaussians shouldn't even run in a VLAR.

The fact that it is running really slowly means that something in there is still using that angular size (what else but a Gaussian would need to use it?), and very likely shouldn't be. So, to find what the code is that does it, and don't run it if the angular width is below the VLAR threshold.

I'm going to try to bring myself up to speed to fix this thing, but I'm hoping someone will beat me to it... it's a lot of work getting there. :^)
Edit: Also when I get there I am not sure I will even recognize it when I see it...lol.

---

it's a lot of work getting there. :^)

Correct, but no shortcuts :)

---

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

Is it more of a driver issue (where we would have to wait for Nvidia to get their act together before there is any relief), the way that the Guppies are configured when they are split (something that can be addressed internally, though with the manpower crunch, is that likely anytime soon?), or something else that causes such a penalty for them on Nvidia hardware? Are things much better in the AMD world? I haven't ran a AMD card for probably 15+ years, so I basically have no experience with them.

I am crunching both SETI@home GPUs and SETI Beta GPUs on an AMD HD 7770 in my Linux box and they take about one hour or less even if they are VLAR.
Tullio

---

The fact that it is running really slowly means that something in there is still using that angular size (what else but a Gaussian would need to use it?), and very likely shouldn't be. So, to find what the code is that does it, and don't run it if the angular width is below the VLAR threshold.

AR used not only for Gaussians. It also defines how long telescope stare at the nearly same point so defines length of time through which data coud be accumulated (so all PoT analysis use it).
For explanations why VLAR relatively harder for GPU vs CPU vs other ARs look few my recent posts for example (actually it was repeated few times through years).
And effect strongly depends on memory organization. Even on the same frequency memory access to NV CC1.x (for example) device and AMD device very different. So called coalesced access cause enormous performance drop for early NV architectures in case of random (or close to random from hardware point of view) access to memory. Later architectures improved this.

For explanations why VLAR relatively harder for GPU vs CPU vs other ARs look few my recent posts for example (actually it was repeated few times through years).

Thanks for the details... do you have a link to any of these posts?

---

very short version:
low AR => longer time to stare at same point => bigger data array for single PoT search => failure to fit cache, failure to get enough parallel data to fill all CUs (longer single array = less number of such arrays cause 1M matrix of data point remains constant), decreased computation/memory access ratio (cause most of PulseFind is folding (simple additions) and this search has increased share) => performance drop for devices with massive parallelizm and big memory access latencies (that GPU are).

EDIT: to find person's posts:
http://setiathome.berkeley.edu/forum_user_posts.php?userid=7779286