Can someone explain how it works and why it's better? I've been looking at the allocation of WUs and it seems to be totally random. WUs that I get seem to always be given to machines with OSs and CPUs that are different from mine. Looking at my credit it seems that I'll be getting roughly a third to half of the credit requested. It doesn't seem very fair at all. It would be better to give the credit requested since a P4, which seems to get less credit, can work much faster than a P3, say, which gets more credit.


j

Assigning a work unit to a diversity of OSs and CPUs is a good thing, in my opinion. It cuts down on the likelyhood of a bad science core (mis-compiled, mis-ported, etc) contaminating the science database.

A work unit is issued initially as 3 'results', which are issued to 3 different accounts. If all 3 are not returned by the 2-week deadline, more 'results' are made from this work unit and issued, until 3 come back. When 3 are returned, the *data* (not the number of credits claimed) from the 3 are compared. If the data is similar enough, the work unit is marked as being validated, and credit is awarded. If the 3 do not successfully compare, I believe that the scheduler will continue to issue 'results' to people until 3 come back that do match, but don't hold me to that (I am not sure).

Once a work unit is validated, the middle of the 3 values of 'claimed credits' is awarded to the three people that returned the ones validated (and maybe to the rest that have returned it on time). This was done to prevent people profitting from doing an exploit that would artifically inflate their credits. In the initial stages of the Alpha/Beta testing, it used to grant the LOWEST of the 3, but after complaints (usually about the Sun/Solaris client and its almost always claiming some rediculous value of credit such as 0.04 - a client bug) they changed it to the middle value.

Claimed credit is calculated using both your computer's benchmarks and the CPU time that unit took to complete. Currently, as you have noticed, there are... issues between various CPU types and modes of operation. The two biggest issues that I have noticed are:

1. Imbalance between a newer AMD (ie. AthlonXP) and an Intel P4. The new AMDs seem to have higher (faster) benchmarks than a P4 which takes an equivalent amount of CPU time. This results in AMDs having an advantage in the credits.

2. Imbalance between a P4 running in HT (hyperthreaded) mode and one that is not. I have seen a lot of complaints about this one, but have no direct experience with it due to lack of having a P4 (HTed or not).

Both issues are known, and the Developers are working on it. Right before release, the entire benchmark section was replaced in an effort to balance things. It does not seem to have helped. Give it some time. If possible, this issue WILL be fixed.


------------
KWSN-MajorKong
KWSN Forum Admin (retired)
http://www.kwsnforum.com

S@H participant since May 28, 1999 (other acct.)
BOINC Beta Tester since Nov 19, 2003

> Once a work unit is validated, the middle of the 3 values of 'claimed credits'
> is awarded to the three people that returned the ones validated (and maybe to
> the rest that have returned it on time). This was done to prevent people
> profitting from doing an exploit that would artifically inflate their credits.
> In the initial stages of the Alpha/Beta testing, it used to grant the LOWEST
> of the 3, but after complaints (usually about the Sun/Solaris client and its
> almost always claiming some rediculous value of credit such as 0.04 - a client
> bug) they changed it to the middle value.
>

Thanks for the explanation.

The docs still say it's the lowest credit. I've now lost confidence in the docs so I won't be reading them again. Clearly out of date.

To be frank the whole project seems to be in a state of chaos. I've never known anything like it. I thought Americans led the way in project management.

So the best thing for users would be to just let the client run and forget about it. I'm surprised the news is saying go back to the old SETI client if the new client runs out of work - where's the recognition for using the old client? The transition document clearly says that the old SETI stats won't be updated. Shambles.


j

> The docs still say it's the lowest credit. I've now lost confidence in the
> docs so I won't be reading them again. Clearly out of date.

Yes, the median was changed just before release.

> To be frank the whole project seems to be in a state of chaos. I've never
> known anything like it. I thought Americans led the way in project
> management.

That's an unfair generalization... :(

It's BOINC that's running this project, not America. Any chaos is due 100% to the BOINC higher-ups. (I'm just assuming it was upper level who made the decision to release)

> So the best thing for users would be to just let the client run and forget
> about it. I'm surprised the news is saying go back to the old SETI client if
> the new client runs out of work - where's the recognition for using the old
> client? The transition document clearly says that the old SETI stats won't be
> updated. Shambles.

Just a guess here, but I'd bet they do a final "snaphot" of the old S@H project before they turn it off.

> The docs still say it's the lowest credit. I've now lost confidence in the
> docs so I won't be reading them again. Clearly out of date.
>
> To be frank the whole project seems to be in a state of chaos. I've never
> known anything like it. I thought Americans led the way in project
> management.

People all over the world has been participating in the Alpha as well as in the Beta test groups to make the program running better and better.

When the project started, credits for 1 WU was given using the following role: comparing the results of 2 PC's and giving the lowest claimed credit as granted credit to both PC's.

Where are we now? Comparing claimed credits of 3 PC's and giving these PC's the median claimed credit.

This is the result of months and months debates on how credit should be granted, how credits should be calculated as well as how benchmark should be run.

Did we improve the credit system? YES .

Did we improve the software? Definitely YES.

Let us give the people in Berkeley some time to resolve hardware problems and keep confident in this unique project that is Boinc.


Greetings from Belgium.

> Just a guess here, but I'd bet they do a final "snaphot" of the old S@H
> project before they turn it off.
>

They really need to establish some official line on this, one way or the other. I had a cache of about 5 work units and I deleted the lot along with SETI driver and the client, partly because the old client can't run at the same time as BOINC (according to the docs...) but largely because the docs (...) said the "classic" results wouldn't be updated.

Technologists tend to forget that it's rarely about the technology - it's about the people that use it.

j

> > Just a guess here, but I'd bet they do a final "snaphot" of the old S@H
> > project before they turn it off.
> >
>
> They really need to establish some official line on this, one way or the
> other. I had a cache of about 5 work units and I deleted the lot along with
> SETI driver and the client, partly because the old client can't run at the
> same time as BOINC (according to the docs...) but largely because the docs
> (...) said the "classic" results wouldn't be updated.
>
> Technologists tend to forget that it's rarely about the technology - it's
> about the people that use it.
>
> j
>
>
PRECISELY, We shouldn't be doing this for what our scores are, but for what we can find OUT THERE, if anything !!

Ok, I am lost... I have been looking and reading for a while, but I have a couple of questions...
1. Who can "profit" from work unit credits? As far as I can tell, nobody is paying me for my CPU time.
2. Who gives a crap whether someone is using AMD or INtel or Hyperthreading or what? How does this influence the end result? I didn't realize this was a competition that needs leveled out.
I think I will be satisfied with my "classic" work unit credit and consider myself finished with this for a while until they work out their issues...


> Assigning a work unit to a diversity of OSs and CPUs is a good thing, in my
> opinion. It cuts down on the likelyhood of a bad science core (mis-compiled,
> mis-ported, etc) contaminating the science database.
>
> A work unit is issued initially as 3 'results', which are issued to 3
> different accounts. If all 3 are not returned by the 2-week deadline, more
> 'results' are made from this work unit and issued, until 3 come back. When 3
> are returned, the *data* (not the number of credits claimed) from the 3 are
> compared. If the data is similar enough, the work unit is marked as being
> validated, and credit is awarded. If the 3 do not successfully compare, I
> believe that the scheduler will continue to issue 'results' to people until 3
> come back that do match, but don't hold me to that (I am not sure).
>
> Once a work unit is validated, the middle of the 3 values of 'claimed credits'
> is awarded to the three people that returned the ones validated (and maybe to
> the rest that have returned it on time). This was done to prevent people
> profitting from doing an exploit that would artifically inflate their credits.
> In the initial stages of the Alpha/Beta testing, it used to grant the LOWEST
> of the 3, but after complaints (usually about the Sun/Solaris client and its
> almost always claiming some rediculous value of credit such as 0.04 - a client
> bug) they changed it to the middle value.
>
> Claimed credit is calculated using both your computer's benchmarks and the CPU
> time that unit took to complete. Currently, as you have noticed, there are...
> issues between various CPU types and modes of operation. The two biggest
> issues that I have noticed are:
>
> 1. Imbalance between a newer AMD (ie. AthlonXP) and an Intel P4. The new AMDs
> seem to have higher (faster) benchmarks than a P4 which takes an equivalent
> amount of CPU time. This results in AMDs having an advantage in the credits.
>
> 2. Imbalance between a P4 running in HT (hyperthreaded) mode and one that is
> not. I have seen a lot of complaints about this one, but have no direct
> experience with it due to lack of having a P4 (HTed or not).
>
> Both issues are known, and the Developers are working on it. Right before
> release, the entire benchmark section was replaced in an effort to balance
> things. It does not seem to have helped. Give it some time. If possible,
> this issue WILL be fixed.
>
>
> ------------
> KWSN-MajorKong
> KWSN Forum Admin (retired)
> http://www.kwsnforum.com
>
> S@H participant since May 28, 1999 (other acct.)
> BOINC Beta Tester since Nov 19, 2003
>

> Ok, I am lost... I have been looking and reading for a while, but I have a
> couple of questions...
> 1. Who can "profit" from work unit credits? As far as I can tell, nobody is
> paying me for my CPU time.

Eh? Nobody "profits" from it. You're taking it a bit too literal. If you read what he posted, he mentions artificially inflated credit. Meaning, the "profits" are higher status for less (or no) work...

> 2. Who gives a crap whether someone is using AMD or INtel or Hyperthreading or
> what? How does this influence the end result? I didn't realize this was a
> competition that needs leveled out.

It's not a competition. The only reason processors come into play is because of calculation differences. If you are an AMD user for example, the WUs you receive will only be sent out to other AMDs. This is because the different architecture of the chips handle floating point operations differently. Both platforms still do valid science, but the results of a WU completed on an AMD might be different enough that the result couldn't be verified with the same WU done on an Intel processor. That is the only seperation between processors.

> I think I will be satisfied with my "classic" work unit credit and consider
> myself finished with this for a while until they work out their issues...

That's your perogative. I personally don't see any "issues" worth not running the project for. I haven't for the many months I ran beta.

The real "problems" we've been seeing lately have been server issues, not software.

<a> [/url]