With the new 3 of 4 sended WU calculation, the
granted credit is not working correct.

look at this example:

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7159111

the four claimed are: 38.15;18.77;27.11 and 43.93

the granted is 27.11;

Because of the formular the correct granted should be: (27.11 + 38.15) / 2 = 32.63

more examples:

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7159111

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7159102

and so on..

any ideas about this behaviour??

---

The way I believe it works, Honie, is that it is only on the first three usually that the credit is worked out. So in this case, the first three were 38.15, 18.77 and 27.11. The middle of those is 27.11 and that is what is granted. The fourth result just gets whatever was granted for the first 3.
Haven't looked at the other two examples of yours, but I would presume they are the same.

---

<img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=268&amp;prj=1&amp;trans=off" /><img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=268&amp;prj=4&amp;trans=off" />

> The way I believe it works, Honie, is that it is only on the first three
> usually that the credit is worked out. So in this case, the first three were
> 38.15, 18.77 and 27.11. The middle of those is 27.11 and that is what is
> granted. The fourth result just gets whatever was granted for the first 3.
> Haven't looked at the other two examples of yours, but I would presume they
> are the same.
>

That's correct - credit is calculated on the first 3 returned results only. The 4th result to be returned, if validated, get's whatever the other 3 got. No recalculation is performed.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

I believe it it still OK.

For the WU with id 71591113 fhe first result that came in had a claimed credit of 38.15, the second a claimed credit of 18.77 and for the third it was 27.11. The granted credit if I am correct is the mid value of these 3, so it is 27.11. The fourth returned one receives this value as well.

For the WU with id 7159102, the numbers are 33.88 then 22.58 and finally 35.15, so the mid value is 22.58, corresponding to the granted credit.

> The way I believe it works, Honie, is that it is only on the first three
> usually that the credit is worked out. So in this case, the first three were
> 38.15, 18.77 and 27.11. The middle of those is 27.11 and that is what is
> granted. The fourth result just gets whatever was granted for the first 3.
> Haven't looked at the other two examples of yours, but I would presume they
> are the same.
>

Ok, would make sense, but in the past, if a fourth or fifth result is returned in time, the granted credit was calculated backwards by eliminating the highest and lowest and building the average of the rest, even when the granted credit was calculated before.

Example:

3 WU were send and 2 results were returned with 20.5 and 24.5 claimed and the 3rd ran out of time. The 4th WU was sended and BEFORE the 4th was sending a result the 3rd returned his result with 22.5 claimed. Now the validator calculats the granted with 22.5 which is correct.
Now the 4th returns its result with claimed 21.5 the granted is corected with
(21.5+22.5)/2 = 22 by the validator. And now the granted is decreased by 0.5 to 22 granted.

That's the way it worked in the past. And I don't know any reason why it should changed.

---

Please look at this thread: (3 Months ago)

http://setiweb.ssl.berkeley.edu/forum_thread.php?id=5525

---

Also dont forget that with the backlog of work some unit atm are getting all 4 results in before the credit is granted. When this happens then it does use an avg of the middle 2.
Once things are caught up I doubt you'll see to much more of these types of conflicting granted credits.

---

<a href="http://www.teampicard.net"><img src="http://boinc.mundayweb.com/seti2/stats.php?userID=2205&amp;trans=off"></a>

> With the new 3 of 4 sended WU calculation, the
> granted credit is not working correct.
>
> look at this example:
>
> http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7159111
>
> the four claimed are: 38.15;18.77;27.11 and 43.93
>
> the granted is 27.11;
>
> Because of the formular the correct granted should be: (27.11 + 38.15) / 2 =
> 32.63
>
NO formula, NO division is done with the credits! Straight numbers here, 3 results, all within statistical limits, the middle number is what everyone gets!
Computer A requests 34.75, Computer B 35.98, Computer C 43.22, ALL users are granted 35.98 credits!


>
> any ideas about this behaviour??
>

---

> > The way I believe it works, Honie, is that it is only on the first three
> > usually that the credit is worked out. So in this case, the first three
> were
> > 38.15, 18.77 and 27.11. The middle of those is 27.11 and that is what is
> > granted. The fourth result just gets whatever was granted for the first
> 3.
> > Haven't looked at the other two examples of yours, but I would presume
> they
> > are the same.
> >
>
> Ok, would make sense, but in the past, if a fourth or fifth result is returned
> in time, the granted credit was calculated backwards by eliminating the
> highest and lowest and building the average of the rest, even when the granted
> credit was calculated before.
>
> Example:
>
> 3 WU were send and 2 results were returned with 20.5 and 24.5 claimed and the
> 3rd ran out of time. The 4th WU was sended and BEFORE the 4th was sending a
> result the 3rd returned his result with 22.5 claimed. Now the validator
> calculats the granted with 22.5 which is correct.
> Now the 4th returns its result with claimed 21.5 the granted is corected with
> (21.5+22.5)/2 = 22 by the validator. And now the granted is decreased by 0.5
> to 22 granted.
>
You are still trying to divide! NO FORMULAS are used in the granting of credits!

> That's the way it worked in the past. And I don't know any reason why it
> should changed.
>
No it didn't EVER work that way! I have been here since the Beta was still going on and we have NEVER done it the way you are thinking.

---

The four results come back in order:

38.15
18.77
27.11
43.93

Normally, the unit is validated after the 3rd one comes back, so discarding the high and the low values, this sets the 'granted credit' for this work unit to be the middle value, 27.11

If the 4th result comes back while the work unit is still active, it too gets the granted credit of 27.11 (if it matches). Granted credit is not recalculated... Ever.

If the validator is backlogged (as has been the case over the last week or so) and the 4th one comes back BEFORE the validator 'gets to' this work unit, then I believe the 'middle two' of the four claimed credits are averaged to get the granted credit. We haven't seen this behavior before because up until recently, there has only been three possible candidates for validation (the initial 3, plus any single issues to replace 'errors' -- past deadline, or bad results).

Rather recently, they set the initial issue from 3 to 4, but kept the validator quorum at 3. Only in the case of the 4th result being returned before a backlogged validator gets to the work unit should this averaging occur. Hopefully, it will only happen rarely (if the validator can 'keep up' after S@H-Classic goes offline).

---

https://youtu.be/iY57ErBkFFE

#Texit

Don't blame me, I voted for Johnson(L) in 2016.

Truth is dangerous... especially when it challenges those in power.

Also if a wu is re-issued due to "no consensus yet", you can have 4 or more results being validated at the same time wu is validated, and therefore be part of the credit-decision-process.

Has anyone actually seen this "averaging for 4 units" happen?
I've had a few results in now that were waiting validation, with 4 units there, an d they've all gone by the middle of the first 3.

I've not yet seen an average of the middle 2 of 4 taken.. i think this is a myth!

---

<img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=268&amp;prj=1&amp;trans=off" /><img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=268&amp;prj=4&amp;trans=off" />

> NO formula, NO division is done with the credits! Straight numbers here, 3
> results, all within statistical limits, the middle number is what everyone
> gets!
> Computer A requests 34.75, Computer B 35.98, Computer C 43.22, ALL users are
> granted 35.98 credits!
>
But then how is this one figured if no divisions are done?
http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7401955

24.17
28.51
26.49
28.77

granted = 27.50

That looks a lot like (28.51 + 26.49)/2

---

<img src='http://www.boincsynergy.com/images/stats/comb-912.jpg'>

> > NO formula, NO division is done with the credits! Straight numbers here,
> 3
> > results, all within statistical limits, the middle number is what
> everyone
> > gets!
> > Computer A requests 34.75, Computer B 35.98, Computer C 43.22, ALL users
> are
> > granted 35.98 credits!
> >
> But then how is this one figured if no divisions are done?
> http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7401955
>
> 24.17
> 28.51
> 26.49
> 28.77
>
> granted = 27.50
>
> That looks a lot like (28.51 + 26.49)/2
>


I agree, it does look like the average of the top/bottom of the first 3 results
It's the first result I've seen like this, I'd love an explanation from one of the SETI crew

---

<img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=268&amp;prj=1&amp;trans=off" /><img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=268&amp;prj=4&amp;trans=off" />

> Has anyone actually seen this "averaging for 4 units" happen?
> I've had a few results in now that were waiting validation, with 4 units
> there, an d they've all gone by the middle of the first 3.
>
> I've not yet seen an average of the middle 2 of 4 taken.. i think this is a
> myth!
>

I've seen one. Here it is:

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7355335

---

-----

Thanks Matt, that's exactly what I mean.

Maybe it has to do something with the backlog of the validator,
but I think it is not a very good idea, if the granted credits
depends on if the validator has past this wu or not.

So this should be correct:

if the validator didn't pass the WU and 4 or more results are present,
the granted credtis are the average of the claimed after the min and max
are eliminated.

if the validator passed the WU the 4th or higer result will get the once
calculated credit of the middle result from the first three results.

So the granted credit depends on the time, the validator is passing the
results.

---

Yes it did happen here is my recent WU.

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=7324144


Computer A - 6.79
Computer B - 31.57
Computer C - 40.07
Computer D - 34.27

Remove Computer A & B
Add Computer C & D for a total of 74.34
Then divide 74.34/2 = 32.92

otherwise it should have been 34.27.

---

Sorry?

Remove Comp A and Comp C

You get:

(31.57+34.27)/2 = 32.92

(Try calc.exe)

74.34/2 = 37.17 !!!!!!!!

---

The BOINC-crediting haven't changed, the credit is decided at the same time a wu is validated, based on how many of the results passed the validation:

If only 2 passed validation, grant the lowest claimed to everyone.
If 3 or more, remove highest and lowest claimed and average the rest.

Any results returned later and passes validation get the same credit as the others, no re-calculation of credit is done.

The system will wait for late arrivals of results after wu validated, but only till all results is either reported and tried validated, or reached their deadline.


Seti is now issuing wu to 4 users, but tries validation then got 3 "success"-results, so normally the 3 results returned 1st will decide the credit. But, since the validator currently is backlogged, many wu have now 4 results before validator keeps up, for these 4 is used for deciding the crediting.
There's also a small group of wu being re-issued due to no consensus, and these can have upto 6 results passing validation then wu at last is validated.

BTW, in SETI@home it's also possible only 2 of the results passes the validation. ;)

Ingleside is correct,

Code for granting hasn't changed recently.

Has allways been:
A. remove highest claimed
B. remove lowest
C. add up remainder of claims (however many that may be).
D. Divide by count of claims in C (average).

Seti had allways been 3 results per WU, so 3-high-low = 1, and average of middle score = middle/1 .

Backlog caused a few of the 4 result WUs to all be returned and be in database before validation...and for those, it was average of middle two.

This is from looking at the server source code.