But I don't think you can make the assumption that for AR= X. Task(A) AR = X and Task(B) AR =X therefore task A = task B and thus credit Task(A ) = credit Task(B). It just doesn't work out that way. BOINC still generates the random number for credit for each task.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I participate in the tests done in the past, you could compare the crunching times etc but not really the credits since the credit depends on your wingmate hosts performance too. That's one of the problems of CreditScrew. You can't really control the test environment to be sure if your results have really meaning or no.

+1

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

What they need to do is forget CreditScrew and create a "standard WU", give that WU a fixed credit, no matters what app or host crunch it.
Then adjust the credit of the rest of the types of WU to that standard WU. Not a hard task since they have a lot of data to work on it.
Remember always the kilo example... one kilo is one kilo, no matters what instrument you use to measure it's weight, that's IMHO the big flaw of CreditScrew, it's give credit depending on the host & the wingmate (besides the performance of the CPU/GPU/ARM, etc) who crunch the WU. So the same WU will never receive the same credit even if you crunch that WU several times on the same host That's why the random number appears..

---

But I don't think you can make the assumption that for AR= X. Task(A) AR = X and Task(B) AR =X therefore task A = task B and thus credit Task(A ) = credit Task(B). It just doesn't work out that way. BOINC still generates the random number for credit for each task.

That's why I looked at multiple tasks in each category and just posted the raw results. It was how the range of credits in each rescheduled group compared with the similar control groups that I felt was meaningful, not the individual credit amount for any specific task. Obviously, the more tasks in each group, the better the comparison that can be made. Only one group in my test (non-VLARs rescheduled from CPU to GPU on one machine) contained fewer than 4 tasks. The other 11 groups all had 4.

After looking into the history of my 2 rigs here's a breakdown.

When we had that period of just Arecibo MB work both my rigs produced a combined RAC of 103K.

With a good mix of all types of work they produced a combined RAC of 92K.

With a good mix of just MB work produced a combined RAC of 86-88K.

Now with just these GBT the combined RAC is less than 60K (and with time may even drop to that magical "0" figure that some are predicting).

But it is nice that D.A. has finally fessed up to what a lot of us were telling him years ago.

Cheers.

CreditScrew is clearly a Utopia . Why keep something that is clearly broken?

---

But it is nice that D.A. has finally fessed up to what a lot of us were telling him years ago.

Cheers.

He may have 'fessed up' or at least acknowledged that the Credit algorithm needs looking at ..... but the important thing is he actually needs to start working on the problem. At least restart on that action #Issue 2132 that is already posted on the developer site. Only Richard has done anything recent on it. DA needs to start working on it himself or assign more developers. This action should be on the very top of the action list at the next Project Management Committee gathering.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

APR uses a long time rolling average in its calculation so 46 tasks will have no (visible) impact on its value, try 46000 and you will see the impact, just about.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

You can find out all about Credit new here.

Always good to provide the link to the explanation of CreditNew when the question arises anew. Thanks, Grant.

. . It would help even more if I understood it ... :)

Stephen

? ?

You can find out all about Credit new here.

Always good to provide the link to the explanation of CreditNew when the question arises anew. Thanks, Grant.

. . It would help even more if I understood it ... :)

Stephen

? ?

It would help still more if those working on the code these days understood it.
And put it on the priority list to fix it now.
Again, I don't compare Seti credits to any other project. And it won't affect my participation here.
But, within Seti, the credit awarded does seem to have dropped dramatically over the last few months for the same amount of work done. And there is no sign of that decline hitting the brakes.

Meow!

---

"Time is simply the mechanism that keeps everything from happening all at once."

The trouble is there are a number of "tuning factors" that can be applied. A couple of years back (maybe more) Eric/Matt said they'd tried a couple and found they either didn't work the way they thought they did, or worked "the wrong way". Tuning that sort of system pseudo damped system is always going to be a black art, involving a lot of luck, and something SETI does not have, control over the feedback loop (user base).
My guess is that we with the demise (temporary or otherwise) of Arecibo based units we will see a 30 to 40 percent reduction in nett RAC, about half directly due to the loss of the Arecibo work, about 5 percent due to the lack of AstroPulse units, and the rest due to the instability caused by the first two. Obviously this is the project nett RAC, individuals will see their own RAC decreasing by similar amounts, but the exact figure will depend on their mix of recent work (high AstroPulse will tend to push the loss up,as will high Arecibo work).

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Well, maybe then the answer to the problem is to scrap Credit New and start from a clean slate that the new coders can understand and work with. Instead of trying to untangle and patch something that is so obviously broken and works in such mysterious ways that nobody can fix it.

Call it Credit Corrected.

Meow!

---

"Time is simply the mechanism that keeps everything from happening all at once."

+1

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Heck, as long as it provides consistent credit for a given amount of work done, you can call it kibbles for all I care. All I want is consistency, I really don't care about the actual number. 100, 1000, whatever. Just make it Consistent!

---

Heck, as long as it provides consistent credit for a given amount of work done, you can call it kibbles for all I care. All I want is consistency, I really don't care about the actual number. 100, 1000, whatever. Just make it Consistent!

Exactly!!!
You first need to have a system that at least reasonably constant in the amount of credit awarded for the same amount of work done! The current system is not even remotely so. I get a 60% difference between comparable WUs run for the same amount of time on my GPUs? By what flipping reasoning? That is simply crazy.

I know that the point of the project is the search, not the credits. And therefore some do not consider this an important issue. I believe that Eric does care, and has tried to adjust what he could with the code that's in place to no avail. I do not blame him, he did not write the code, and apparently it was written without a proper adjustment mechanism in place. Either that, or what is there does not work properly.

But, fact of the matter is...............
Some folks DO care about the credit system. They want tangible recognition of the resources that they are donating to this project. And in a consistent, reliable manner.
So I really think that the credit system is more important to this project than some might believe.
And I think that some resources, although stretched thin, should be applied to it and create something that works properly. And very soon.

As always, this is just my opinion.

---

"Time is simply the mechanism that keeps everything from happening all at once."

For those that DO care about credit, the recent drop in RAC is just one more reason for them to abandon the project or reduce their resource share and move to higher paying projects. Not something we should want with the increasing amount of work we are seeing and more coming our way. I too think the credit issue should be looked at with more attention from the developers and we need to have them begin an action plan and publish that plan.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Since Credit New does not seem to be able to allocate credit sensibly, let me suggest a possible fix.

Let the servers periodically (say once a week? month?) send out Test WUs to users with known system configurations and use the results to "normalize" the credits for each configuration (both CPU and GPU) based on the results. Due to BOINC not properly characterizing multiple GPU machines with different GPUs on board, they should be sent only to single GPU machines.

The TWUs would be the same for all machines, but marked in some way so that the results are not included in the DB, but used only for getting factors for credit allocation. Thus each machine would get a true rating because they would be doing the exact same TWU. No fancy computation needed by Credit New. Then these factors could be used to allocate credit for regular WUs by machine, and no wingman factor needed. If a machine changes h/w, no problem, as the servers know what the current h/w is at each contact, so factor could be changed on the fly.

Only problem would be machines with multiple different GPUs. I don't know how that might be handled. Are there a lot of those?

---

Only problem would be machines with multiple different GPUs. I don't know how that might be handled. Are there a lot of those?

I would guess that case is the majority. IOW, a user decides they like the project, notices that multiple gpu are the most productive and either drags an old gpu off the spares/castoff shelf and installs it or decides to purchase another 1 or more gpus new. Which based on budget could be newer cards of equal, greater or lesser performance than the initial gpu they started with. So a mix of different types probably is the norm.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I not see any credit complains on E@H who uses a fix credit per WU crunched.

This is simple to put to run. And everybody understand.

Something like Each crunched MB WU receive 100 credit, no matters where (CPU/GPU) or what host crunch it.

Will need to adjust the base value according the WU type (blc, Arecibo, AP, Vlars, etc) due the differences on crunching times, but that is easily to do.

---

I not see any credit complains on E@H who uses a fix credit per WU crunched.

Very easy there, as you know each WU on a given host has the same run time.

---