John talk about optimized applications not optimized BOINC client. He is consistent.

John talk about optimized applications not optimized BOINC client. He is consistent.

He may be consistent, but his post is useless if you read it the way you are doing, cause there have never been optimised rosetta applications. I don't want to be rude or something, but just point it out :).

---

And I'm proud of it!

http://www.xtremesystems.org/forums/showpost.php?p=1662769&postcount=28

http://www.xtremesystems.org/forums/showpost.php?p=1662478&postcount=20

http://www.xtremesystems.org/forums/showpost.php?p=1662584&postcount=27

Again I apologise to XS but feel it necessary to show D.Bakers thoughts.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

Maybe I was thinking of SIMAP or LHC, it was one of those that had a quorum of 3. Nonetheless, quorums blow.

The reason BOINC is failing in regard to that original idea is because optimised clients are screwing up the amount of credit different systems claim.

The real real reason BOINC is failing is because it is not being updated with new security measures built in. Do not try to tell me that BOINC is failing because of optimized clients that actually utilize all the capabilites of current processors, that is a load of pooh.

For some projects, redundancy (quorum greater than 1) is the only method for validating that the science was done correctly. There are cases where the science is not done correctly by a given computer - some people attempt to create an output file that will pass so that they can get credit for no work (happened in S@H classic), some people over clock their computers until the FPU goes crazy (but the logic portion can appear stable - again happened in S@H classic and happens in S@H BOINC), some hosts have unknown heat problems (has happened in S@H BOINC), and occasionally something just goes wrong with an otherwise healthy host (occasional random validation errors).

For other projects where the science can be easily validated (Riesel Sieve comes to mind) a quorum of more than one can be a waste of time.

Rosetta appears to fall in the middle since it is statistics based. If most of the work is done correctly, then the answer they get is close to what they wanted. The more work that is done correctly, the closer the answer is likely to be to the goal of finding the lowest energy. So the redundancy is built in slightly differently.

John : Rosetta has the best validator available to any bar none: They KNOW THE CORRECT STRUCTURE of the proteins involved in the work units they send. Even in the case of CASP where for the time of the running of the protein model they are running "blind"they get access to the Protein True structure once the deadline of that protein is met and the structure is released by the cristalographer that determined.

And yes for anyone interested in catching true cheats: The database of Workunits at Rosetta , allows for true statistical analysis that can lead to the taging of highly suspect claims, and analysis of those claims to see what corrective action can or must be taken. That work takes time and that works takes the discipline not to rush to judgment.

Would you like to try your hand at cheat hunting? I can give you the ids of the last 5 cases I was working on before I decided to stop crunching for Rosetta. I for one, would like to see others having to make the call to recomend the zeroing out or even the downward modification of credits. I can tell you from personal experience: it is not fun .

From David Bakers thread at XS....

the push to improve the credit system was from Jose and other XS members who did not like the fact that it was easy to trick the system into
reporting huge amount of credits when in fact no work was done. this obscures the great contribution many of you are making.

So can all you whiners stop whining that XS are the ones whinging about the new system. They aren`t.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

John talk about optimized applications not optimized BOINC client. He is consistent.

Split all the hairs you want. He is not consistent.

You can shift and backtrack and repostulate your claims and statemenets but, nothing you and the likes of you say and do cannot change the fact that from the get go:

THE DEVELPERS HERE HAVE ALLOWED THE USE OF OPTIMIZED CLIENTS. THEY decided from the begining how to run the application in such a way that allows the use of the optimized client.

Maybe I was thinking of SIMAP or LHC, it was one of those that had a quorum of 3. Nonetheless, quorums blow.

You may have been thinking of WCG, which uses a quorum of 3 to validate the results to ensure the science is done without error.

All 3 quorum credit claims SHOULD be similar for any given work unit, regardless of CPU etc, the only difference being is the length of time the result has taken to complete.

The ideal situation SHOULD be:

(Example purposes only!)
A Conroe takes 2 hours and claims 50 credits, A P4 takes 3 hours and claims 50 credits, and the lowly P2 takes 6 hours and also claims 50 credits.
Result: They all get 50 credits for the same result, as they have all done the same amount of work.

Where the Conroe gets the benefit is that it can do 3 results in the time the P2 does one - so after 6 hours the situation looks like this:

Conroe - 150 credits
P4 - 100 credits
P2 - 50 credits

Now to me as an example ONLY, that sounds fair in an ideal world - but unfortunately we're not in one, and there can often be large differences in credit claimed, particularly from those using enhanced clients.

The quorum system nullifies the effects of enhancements to a large degree, and the only time they come into effect is if the are 2 enhanced clients in the same quorum, but of course this would also mean the 3rd one also gets the enhanced claim too, so he/shes probably not complaining!

This situation has been discussed recently over at WCG - but the general concensus is that it isn't much of a problem to get worked up about, lets just get on with the work.

I think the Utopian vision is that there should be one Boinc client only, that fairly recognises the the work done by particular types of machine, and awards that credit uniformally over all projects.

I have deliberately avoided commenting on the arguements here, as its not my place to do so, all I would say is always remember that it is the work done that is the most important thing.

Ady :)

---

Crunching In Memory Of My Dad

Crunch3r created a collection of optimized Seti application that outperformed the standard Seti application. Supposedly, there's different applications compiled with different levels of the advanced features of newer cpus. (SSE, SSE2, etc). The optimized applications run much faster than the standard science application. Roughly 3 times faster than the standard app. So Crunch3r created a boinc client to go along with the 3x faster optimized app. All it does is give a benchmark that is 3 times higher than the standard benchmark.

We now have people claiming that by using the Crunch3r 5.5.0 client, that they're mystically turning on all the advanced features of their cpus. Wha? It doesn't.

We have people claiming that they need to use Crunch3r's 5.5.0 client to get the points they deserve from the advanced features of their cpus and that if it's a problem for the Rosetta community, that the Rosetta team needs to create a SSE enabled application that works 3 times as fast as the standard application. These must be the same people who believe that converting every 32 bit app to a 64 bit app doubles its performance. (It doesn't.. some 32 bit apps become slower when compiled in 64 bit mode.) Turning on SSE doesn't make every program 3x faster, either.

If people keep stating these urban legends that they've been told, then others will point out the errors in the information the urban legend tellers have been given.

Pointing out these errors in logic is in no way claiming anyone is cheating. Wait for people to move on to the sentence about how they feel it's cheating - rather than instantly assume that's what they're doing.

David Baker mentioned that the optimized clients were okay for Rosetta, so he didn't consider it cheating - which means that the opinions of any of the rest of the Rosetta contributors doesn't matter in regards to optimized clients equalling cheating. It's like the person who has the opinion that their 200Mhz Pentium is better than your 2Ghz Athlon cpu because it's made by the folks that advertised with the Blue Man Group. It's an opinion.

Optimized clients being okay to use on Rosetta does not, however, make rediculous urban legends true.


----------

But back to the topic of the thread - how close do you think the backdated data (which won't be used for external stats sites) will be to your current score? -10%, -5%, right on.. +5%, +10%, etc?

---

Benny that isn`t helpful.

And as for the backdating, you`re not keeping up. David Baker stated quite clearly on XS " There wil be NO backdating".

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

Wow!! - I get a negative rating here for my earlier post(09:24:56 UTC) - when all I did was give a neutral view.

I can see now how things can get heated here if folks can even get worked up over such non-controversial posts.

Ady :(

---

Crunching In Memory Of My Dad

There appears to be a misunderstanding by some about the proposed credit system here- there are a number of posts that clear this up though, although Ady's post a few before mine (above? below?...) summarises it well. The system doensn't penalise faster computers - or more accurately it doesn't credit based on CPU time - it bases credit on work done, so faster computers get more credit, not per decoy, but by doing more decoys in a given time.

---

There were two possibilities mentioned. Showing the backdated credit system's scores along side the old system's scores - and actually replacing the old system's scores with the backdated new credit system's scores. David Baker's comment could be referring to just the replacement option. If they've abandoned the idea of even showing the new credit system's scores backdated to Feb side by side with the current scoring system, then leaving this thread going is a silly idea.

But then, Rosetta staff posting comments like that on other forums and not even repeating them here seems awfully silly, as well.

---

Agree with your last Benny entirely !

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

Man If I had my way:

1- No allowing for benchmarks to be reset at the will of the participants.
2- Random change of the benchmark runs

Projects has had the opportunity to use their own application-specific benchmark since v5.2.6 was released October 2005. This would likely mean a quick benchmark at start of each wu or something.

Projects can also "count flops" (and integer-ops), and by this not rely on any benchmarking at all.

3- Close source, heavy encription of the credit granting code.

BOINC is open-source, end of discussion.

But, this doesn't stop any project for using closed-source, and if they're relying on client-side crediting and it's a problem with BOINC-client-side-tampering, they can return the credit-claim as part of the result-file uploaded at the end. With reporting crediting both through BOINC-client and through the result that can be encrypted, you'll have an extra check to see if someone is trying to tamper with credit-claims.

4- A code that will reward time crunched ( as time is the ressource we contribute) as well as work done.

Maybe mis-understanding you here, but any system there a p200 MHz will get the same credit per hour as an p4-4 GHz is in my opinion useless.


A credit-system should preferably give the same amount of credit for the same amount of scientific work:

If a 486-33 MHz uses 100 hours to crunch 1 decoy (or whatever it's called) from a specific wu/random-seed, and a 486-33 GHz uses 0.1 hours to crunch 1 decoy from the exact same wu/random-seed, both should get the exact same credit for this scientific work.

Since the 486-33 GHz can after 100 hours crunch 1000 same-sized wu as the 486-33 MHz, it should also get 1000x more credit after 100 hours of crunching.

So, while the credit for a single wu should be the same, credit/hour will be hugely different, making it advantagous to run as many fast computers as possible.

5- A system that doesnt favor AMDS vs Intels or whatever over whatever. And that includes the anti Linux bias that are obvious in BOINC.

The Linux-"bias" is due to the Linux-compiler doesn't optimize so much of the benchmark as the Windows-compiler is doing. This is unfortunate, but since more accurate methods of deciding crediting has been made available, it's unlikely any of the BOINC-developers will use much time to try fixing this problem. But, if someone does have neccessary code-changes to improve the benchmark so different compilers doesn't optimize-away part of the benchmark, by all means supply it to the BOINC dev-list or directly to David Anderson, and maybe it will be added to the code.

As for any cpu-favouring, it's a fact that different cpu's isn't wired the exact same way. Example, cpu A can be excellent on example sin/cos while mediocre on logs, while cpu B can be excellent on logs but mediocre on sin/cos. If a project relies mostly on sin/cos, cpu A will be much better than cpu B, while a project that relies mostly on logs will be exactly opposite. For some projects, like most likely Rosetta@home, different wu can have different fractions of the various calculations, meaning credit/hour will variate between wu even if counts actual scientific work done.


An analogy, let's say two twins, Charlie and Dave, is hired to do some work. Charlie is using a spade, while Dave is using a pitchfork. Both is set to move 1000 kg of earth from their own pile of earth to another pile.

Now, let's say Charlie uses 13 hours on the job, while Dave is a little bit faster and uses 12 hours on the job. In this instance, it wouldn't be a large difference between paying by the hour or paying for the amount of earth moved, but since both has done the same amount of "real" work the best is to pay both for moving 1000 kg of earth.

Next job, Charlie and Dave is set to each move 1000 kg of water from their own tank to another, and they're using the same equipment as before...

Now, Charlie again uses 13 hours to move 1000 kg of water, while Dave, using his pitchfork, uses 130 hours to move 1000 kg of water.

In this instance, would it be fair if Dave is paid 10x more than Charlie for using much longer on getting the work done? Of course not, equal pay for equal work done is better. That Dave's tools isn't fitting for the particular work should not lead to more pay.


The same should be true for computers, 2 different computers can be roughly equal doing one type of work, but one of them can be really slow on other work. Since the scientific work is the same, the really slow computer should not get "paid" more for doing the work slowly.

So, depending on what type of calculations a project and a specific wu is relying on, a particular cpu-brand will have an advantage over another cpu-brand either for the whole project, or for a limited group of wu's.

6- A rational way of determining the work credits: I think That was being talked about with some of the people in the other thread. I even showed whqt I believe could be done )If memory doenst fail me two or three people made good comments about the idea.)

For the moment it's too much noise on these forums to try keeping an on-topic discussion going. Also, till the real effects of the current changes is better known, it's unclear if anything more needs to be done or not.

So, my recommendation is to wait a week or so and see that happens...

---

"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."

John talk about optimized applications not optimized BOINC client. He is consistent.

Split all the hairs you want. He is not consistent.

You can shift and backtrack and repostulate your claims and statemenets but, nothing you and the likes of you say and do cannot change the fact that from the get go:

THE DEVELPERS HERE HAVE ALLOWED THE USE OF OPTIMIZED CLIENTS. THEY decided from the begining how to run the application in such a way that allows the use of the optimized client.

It is not a hair that is being split.

Optimized BOINC core clients just raise credit scores, nothing else.

Optimized project applications (the real science) do increase the actual work done, but they have the drawback that they reduce credit requests for the same work units done on non-optimized science applications. There are no optimized science applications for Rosetta, therefore, optimized BOINC core clients are merely a cheat.

---

BOINC WIKI

Give up John. There is no way. We crucnh with the BOINC idea. Means, many projects, many users, uniformity in credits to stay comparable. They don't want to ear that.

Finally I agree with Jose, the way this project and a part of its users do things must be done outside BOINC.

Cheat ?

Is less work being done by those machines ? Answer No they still do exactly what they do as Boinc credits are NOT a work measure.

Did the project leaders condemn 5.5 ? No

So it`s not cheating the project.

Who are these people cheating ? John MacLoud VII with his 7 RAC ?

A reasonable competitor would have also put on 5.5 to remain competitive. It was not , has not, ever been stated it is outside the rulings of this project therefore in competition it is judged fair.

Of course you may THINK otherwise, it`s just an opinion NOT a fact.

If you were truely behind the project and could see the actual harm all this is doing you`d think again about your post.You have now started this whole episode right up again and I can only presume, most people having a reasonable intelligence, that you deliberately intend to re-ignite this flame war.

Get this once and for all.

It is not for you to call cheat, you are no mans judge or jury.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

There are no optimized science applications for Rosetta, therefore, optimized BOINC core clients are merely a cheat.

If that were a true statement, a computer would get the same points when running Linux, OSX, or Windows (all versions).

There is not a benchmark which is universal, therefore let members optimize and get the most points for their systems. I found that a 300% increase in benchmarks only increased RAC by about 60%. (Another alternative would be to encrypt Rosetta___.exe with different, somewhat equitable benchmarks for Linux, OSX, and Windows and get rid of BOINC.)

Give up John. There is no way. We crucnh with the BOINC idea. Means, many projects, many users, uniformity in credits to stay comparable. They don't want to ear that.

Finally I agree with Jose, the way this project and a part of its users do things must be done outside BOINC.

Yes, that's quite clear.
But the actual system doesn't even give any useful results even within a Rosetta-only environment. Any bogus claim gets granted, so the stats don't reflect in any way the crunching power really donated.
The new system will be more accurate in regard or really donated science (if it works right), and so it's definitely better, regardless of in an Rosetta-only environment or with the amounts of credit adjusted to the BOINC-norm. A retroactive adjusting of the credits to reflect the real devotion can imho only be a benefit if it's really possible.
In a Rosetta-only environment you could alteratively norm the credits to the inflated 5.5 values, and thus give the regular users a big boost in credits, that's just as fine, it only would not fit in BOINC any more.

BOINC is open-source, end of discussion.

Exactly as long as BOINC is open source no BOINC based application is free from tampering.

The problem is BOINC . End of discussion.