Well, the features provided by the BOINC platform are just that. Features which *can* be used by a given project, but of necessity don't have to be. As example, there is a feature for platform consistency (don't remember the exact term off the top of my head), but predictor@home uses this. In this way only results from computers using the same operating system and CPU platform (aka AMD or Intel for instance) are compared to each other. Though the feature was included in BOINC, SETI doesn't use it. Presumably the people at Berkley didn't feel it was necessary for their own project.

My understanding from some of the project description is that our test is on a known protein or one that has been mapped out already. In this case, they would already have "the answer" for that which they've done their own computation on. Or as the project pages indicate

https://boinc.bakerlab.org/rosetta/rah_top_predictions.php

"This is a test case where we know what the actual structure is and we want to see how well it can be predicted with all of your help (the actual structure was determined experimentally at a huge cost of time, money, and effort)...This experiment will show us how much searching is necessary to ensure that the lowest energy valley is found, which we need to figure out before we can confidently predict the structures of the many important proteins in your bodies for which the lowest energy structure is not known."

At least I'm understanding this to mean that they already know what they're looking for, and so as kel mentioned a bogus result would stick out like a sore thumb. Perhaps after the project moves along, they'll feel it'll be necessary to have redundancy checks (should they move on to some of these "unknown proteins". They'd be in a better position then I to know their plans.

I do find it odd though that since I joined this project my RAC has been consistently higher then my actual credit for more then a day now, though the discrepency has fallen some. Probably a result of credit being instantly granted I gather.

In the typical way (a quorum of 3) which I've seen in many projects, one thing is apperent. People with computers among the fastest have a double benefit.

- They'll almost always be among those to to declare the lowest credit, hence meaning they'll almost always get more credit then they have declared

- Because they can complete the same amount of work in less time, they'll get to do more WUs on the same CPU core

Yes I won't mind when that Athlon 64 gets here (actually some of it has arrived, and one component, the motherboard was back ordered but has shipped). Though not the highest clocked A64, it's not the lowest either. And as to the X2s, their dual core CPUs, so it won't really benefit the computation time on 1 WU that much (except their clocked higher), as I'm expecting (unless someone knows different) that it would just process 2 WUs at the same time... Now I won't have to expect a drop in credit when someone with an A64 or P4 3.0c gets a WU, as I'll be the one declaring shorter completion times :D :) Well for awhile anyhow...

Oh, and FYI a bit OT, but if anyone else finds themself ready to upgrade, the latter Venice core has added SSE3 support (or 11 of the 13 functions in SSE3, leaving the 2 for SMT which doesn't apply to the A64 out anyhow). It also includes improved/more efficient memory management (with slightly higher benchmark scores) and is a bit less picky on memory configurations then the older cores. AMD hadn't made a big deal of their newer A64 core, but some hardware sites inquired as to it's improvements... Not sure that this extention added with the Pentium 4s will help though...

---

The term you were looking for is Homogenous Redudancy. Took me a moment to remember what it was ...

---

This is the kind of thing with RAC that makes me crazy.

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4747

This PC has only been crunching for a little over 21 hours, the total credits are 330.99, and the RAC is only 128.93 The PC returns every result for credit as it is finished.

How does that make ANY SENSE at all?? It should be fairly close to 330.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

This is the kind of thing with RAC that makes me crazy.

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4747

This PC has only been crunching for a little over 21 hours, the total credits are 330.99, and the RAC is only 128.93 The PC returns every result for credit as it is finished.

How does that make ANY SENSE at all?? It should be fairly close to 330.

That machine is a dual processor system, I would expect its RAC to go a lot higher than 330. The RAC isn't calculated instantaneously, it is an average over time.

---

This is the kind of thing with RAC that makes me crazy.

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4747

This PC has only been crunching for a little over 21 hours, the total credits are 330.99, and the RAC is only 128.93 The PC returns every result for credit as it is finished.

How does that make ANY SENSE at all?? It should be fairly close to 330.

That machine is a dual processor system, I would expect its RAC to go a lot higher than 330. The RAC isn't calculated instantaneously, it is an average over time.

An average of what over what period of time? No one has defined "Recent" of Recent Average Credit. It's obviously not a day, or this host would be closer to 330.

When the next WU is credited to this host shortly, we should be able to plug values into Paul's equation and demonstrate how this works, unless there is some "funny stuff" going on to keep the RAC low.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Recent_Average_Credit

---

BOINC Wiki

Recent_Average_Credit

Is that (it WAS some link about Validators before it was edited)supposed to mean something in this context? Paul has already quoted the RAC portion of his FAQ.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=70#633

Now I'm trying to put some REAL numbers against that RAC equation to see if it works as advertised, or at all.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

OH.... and the #1 & #3 Top computers (based on RAC) are still bogus. And #2 is the real deal. :p

Looking at the processing times, I suspect that the #3 computer is overclocked. So it may not be bogus. It is also using a highly optimized BOINC client which is evident from the extremely high benchmarks, creating a higher claimed credit. Because many crunchers work on projects where they run highly optimized apps that tend create lower then average claimed credit, they compensate by running an optimized BOINC client. However, on a project that does not have the same highly optimized apps, they will overclaim credit.

The #1 computer however has been active since before I joined, but it has a very "recent" node number. In fact it has had several recent new node numbers. There is a glitch in the standings where if a new node is created, and then merged with a prior node that has accrued credit. The prior credit will appear as though it is new credit, and for a short period of time it will experience an inflated ranking. The current #1 client has had multiple new nodes that were merged. This might be intentional, but then due to the high error rate of work units it may also be accidental, because of a hardware problem. It's RAC standing is inflated though due to the frequent new nodes created, that are then merged with the older nodes. If it is intentional, then it is really a silly waste of time, because the total credit will eventually be far less then other crunchers and the "game" will be obvious.

Interestingly, this caused me to look at my own clients, one of which was used for testing highly optimized SETI clients. I discovered that I still had the optimized BOINC client and was greatly over-claiming credit for that machine on Rosetta. I have now scaled it back to a more reasonable client. Of course that only went on for a couple of days, and it is actually one of my slower machines so no real harm was done. Because of on and off use due to testing, its RAC is still well below its normal potential. But this question did remind me that I had been swapping BOINC clients for testing purposes on different projects. Going forward it will now be claiming half what it did for the last day or two, which should put it in the middle of the pack. I have stopped testing and dedicated it solely to Rosetta.

For a project like Rosetta, which is more similar to Climate in its credit needs (redundancy is not needed), I think a set amount for each work unit completed would be more fair. That way optimized BOINC clients could not influence the outcome. Credit would be earned based upon the work actually completed. Faster apps or computers will naturally increase total credit more, because more science work is done.

Can't see where there is any perfect solution though.

---

Team MacNN - The best Macintosh team ever.

Using the formula from Paul's FAQ

d(t)=e^(-ln(2*t)/604800)

Can someone calculate d(t) if t=7560

I'm trying to do some Excel magic against the reulsts for the hosts quoted below, and am having problems with this value.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

I actually once did do some work to try to illustrate this well, and had to throw up my hands in surrender.

The *KEY* to the "magic" is that the TIME INTERVAL becomes an exponential factor, in intent, this SHOULD mean that older results have less "weight". So, as the computer does work, instead of being a pure running average, it is a running average where the prior output is reduced by an exponential function of time.

What this means effectively is that in an account like mine:

Dell-Dual-XEON 87.24 667.84
g5a.local 55.58 695.99
Account: 99.40 1,363.83

These two computers have earned about the same amount of total credit, but, the Xeon is supposidly doing it faster, and at nearly twice the speed.

Anyway, if you look at the notes for the function, the initial RAC uses 0 as its starting point, from there you send in the new increments and it updates based on the interval from the first input. From there you, feed in additional values ... The problem is that you have to vary the interval between successive updates ... for a real world example you also have to try different scenerios with the primary changes coming in the variation of the intervals between updates.

If some one wants to use my account as an example it is fine by me. The newness and the fact that the project has not deleted work allows you to start at a known point and calculate out from there. The difficulty with all of this is that the RAC is not captured as a stand-alone value ...

---

Using the formula from Paul's FAQ

d(t)=e^(-ln(2*t)/604800)

Can someone calculate d(t) if t=7560

I'm trying to do some Excel magic against the reulsts for the hosts quoted below, and am having problems with this value.

Angus
I have a spreadsheet that works pretty well, if you want a copy, email me at eberndl at rogers point com

It's pretty lazy and assumes that all credit comes in at exactly the same time, once a day. Even so, I find that it's relatively accurate (with in 1-3 credits, most of the time).

Oh, and d(7560)= 0.999984

(It's nice to see people using my pet formulae!!)

---

Questions? Try the Wiki!
Take a look inside my brain

Using the formula from Paul's FAQ

d(t)=e^(-ln(2*t)/604800)

Can someone calculate d(t) if t=7560

I'm trying to do some Excel magic against the reulsts for the hosts quoted below, and am having problems with this value.

Angus
I have a spreadsheet that works pretty well, if you want a copy, email me at eberndl at rogers point com

It's pretty lazy and assumes that all credit comes in at exactly the same time, once a day. Even so, I find that it's relatively accurate (with in 1-3 credits, most of the time).

Oh, and d(7560)= 0.999984

(It's nice to see people using my pet formulae!!)

Thanks - look for email.

That's the same answer I got, so something else is wrong in my spreadsheet.

Is "t" the time between the current credit and the previous result being applied?

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Yeah, it is, so there was a 2h 8 minute interval between results??

Don't forget, RAC gets calculated when the results are VALIDATED not when they are submitted....

---

Questions? Try the Wiki!
Take a look inside my brain

Yeah, it is, so there was a 2h 8 minute interval between results??

Don't forget, RAC gets calculated when the results are VALIDATED not when they are submitted....

Which is the same thing here, until the quorum feature gets turned on.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Of course, I forgot about that =-)

So it's 2h between upload times? There's a caveat in the RAC programming about if the results are less than a certain time apart... I'll see if I can find it for you.

[edit]Ok, here is the programming for the RAC calculation, that I based the Wiki stuff on.

The part I'm referring to is

if ((1.0-weight) > 1.e-6) {
            avg += (1-weight)*(work/diff_days);

[/edit]

---

Questions? Try the Wiki!
Take a look inside my brain

Of course, I forgot about that =-)

So it's 2h between upload times? There's a caveat in the RAC programming about if the results are less than a certain time apart... I'll see if I can find it for you.

And a further complication that I'm suspicious of is that most of my crunchers are quad CPUs, and end up returning results in groups, and all get credit at the same time. I'm thinking that the 0 time code in the RAC is shorting me on the RAC calculation.
It wouldn't be an issue in projects that require a quorum because the credit would be awarded a different times.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

The 0 factor was pointed out some time ago ... it was supposed to be changed to at least one second ...

But, since RAC is so useless ...

---

If results are less that 2hrs 8min apart the RAC doesn't increment is this correct ?

I checked the farm and my Athlon XP's / 64 are returning results well under 2 hrs apart.

They don't always report the results straight away though.

The linux boxes return results straight away but often don't report until they have done 3 or 3 WU's.

---

Something about the RAC Calculations that I've never been able to understand is the fact that my fastest Computer always is at the top of my Computer list for Total Credit. Yet it seems it is always at the Bottom of my Computer List for RAC ... Weird ... ;)