I'm sorry if this is a FAQ but I have not realy understood the explanation before.

Most of my Results have less credit granted than claimed.

I'm sure that I read before that this evens out over several weeks with some granted higher than claimed.

I do occasionaly get a grant higher than claimed. Of my currently dispayed results only 3 out of 19 are higher than claimed, all others are lower.

What factors affect the grantimg of credit, is it random, or is there anything that I can do to get more?

---

the claimed credit is calculated from the boinc benchmarks multiplied by the time taken (multiplied by a constant).

The granted credit is worked out basically by the number of decoys multiplied for the average credit that's been requested for that type of work unit.

AthlonXPs gets relatively high benchmarks in comparison to their throughput - especially the pre-barton ones due to their smaller cache (256kb vs 512kb). In summary your athlon's benchmark scores are slightly higher than they would be if they were an accurate reflection of it's rosetta ability. If you want more credit you'll have to overclock it, get a faster chip/chip with bigger cache, or add more computers to your account!

HTH
Danny

---

Does Rosetta not use FLOPS counting?

---

Crunching Rosetta as a member of the Whirlpool BOINC Teams

Does Rosetta not use FLOPS counting?

no - i think the main issue with that is the ability to cheat the system as there's no redundancy of results here. The current system works very well - it's a pretty accurate measure of throughput of Rosetta tasks.

---

I'm not saying anything new but maybe it bears repeating. The subject of Rosetta credit awarding system is raised over and over again. This seems to imply that a large number of people either don't understand the system or don't trust the system.

To me the credit award system seems logical but I have to take it on faith that it delivers on its promise. Nobody can view this mysterious and invisible moving average or see what contributes to it. Nobody can challenge it. I, too, usually claim more than I am awarded.

John Keck suggested an extended baseline, and FluffyChicken suggested a chart.

Will we ever see anything to mitigate this topic or are we destined to re-hash it over and over?

It's a problem of lack of transparency.

There is nothing a user can look at to confirm that they are getting a proper amount of credit.

---

Nemesis n. A righteous infliction of retribution manifested by an appropriate agent.

It's a problem of lack of transparency.

There is nothing a user can look at to confirm that they are getting a proper amount of credit.

It's not a conspiracy.

It's a problem of lack of transparency.

There is nothing a user can look at to confirm that they are getting a proper amount of credit.

It's not a conspiracy.

He didn't say it was a conspiracy, only that there is no way to verify correcct credit granting.

There could easily be a graph developed by Rosetta showing how the credit average for each type of WU evolves as results are returned. I would expect some wild swings at the start, and quickly being damped down to the average most of us *should* see. Having some sort of table of the first few hundred WUs showing claimed vs. granted, and the machine ID should show how the initial average is being set, and what effect certain machines have. It's been suspected that the faster machines with the smaller work queues will have a disproportionately large effect on the average, since they can complete a new WU and return it within the first group. but, since we can't SEE that, it's all a guess. Hence the "lack of transparency".

---

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)

There could easily be a graph developed by Rosetta showing how the credit average for each type of WU evolves as results are returned. I would expect some wild swings at the start, and quickly being damped down to the average most of us *should* see. Having some sort of table of the first few hundred WUs showing claimed vs. granted, and the machine ID should show how the initial average is being set, and what effect certain machines have. It's been suspected that the faster machines with the smaller work queues will have a disproportionately large effect on the average, since they can complete a new WU and return it within the first group. but, since we can't SEE that, it's all a guess. Hence the "lack of transparency".

my hunch is that while the faster cpus (read mainly core2 and some opterons etc) return the WUs faster, they don't skew the credit particularly because they don't benchmark particularly high so the credit claims aren't high...

I'd like to see the graphs mentioned though - this is something we could do ourselves if the necessary data was made available :D

---

so data necessary would be...

WU name
Timestamp when returned
and credit claimed and granted.
You'd want to know the exit status as well while you are at it.
In fact, while you're at it, it would be nice to have the CPU type and reported benchmarks of the host as well.

...umm sounds like the existing results display to me. All there, available for public download, compilation, and graphing. ...a nice graph would be EASIER for you to get the information, but it is not hidden from you. Someone simply has to make a crawler to find it. And if you do make a crawler, please find a way to make the raw data available to others so they don't have to generate hundreds of hits crawling to get it as well. And I would guess that directory probably has a crawlers file asking them not to go there, so be kind to the server (add a delay between hits, don't hit for same data repeatedly).

If the history of transfers of the deed to your property is "available for public inspection" at the courthouse, but you don't know how to access it, and when you do find out how to view it, they want to charge you $1 to photocopy it... you still can't say the information is hidden or unavailable.

Yes, the first to report would be the greatest variance, since the average hasn't got a lot of other weight to it yet. But a one hour WU takes about the same hour on a fast processor as it does on a slow one.

In fact, it is possible that a slow processor finishes model 1 in 40 minutes and marks the task completed because it would exceed the hour to do a second one. Where a faster processor might finish that first model in 20 minutes and end up doing 3 before returning the result.

It is also possible that a faster processor marks the task completed first, but BOINC doesn't report it for another several hours.

This randomness, lack of ability to intentionally accomplish being the first to report, and dependance upon the exact timing of a given task's history of reported results is a part of why it has always been maintained that it will averge out over time. You won't the early to report, nor late, concistently.

---

Rosetta Moderator: Mod.Sense

...umm sounds like the existing results display to me. All there, available for public download, compilation, and graphing.

I'm not aware of a single display with all returned WUs on it, for all users.

Yes, the first to report would be the greatest variance, since the average hasn't got a lot of other weight to it yet. But a one hour WU takes about the same hour on a fast processor as it does on a slow one.

The average is supposed to be based on claims/model, not WUs. Faster CPUs finish the models first, and just do more of them.

In fact, it is possible that a slow processor finishes model 1 in 40 minutes and marks the task completed because it would exceed the hour to do a second one. Where a faster processor might finish that first model in 20 minutes and end up doing 3 before returning the result.

It is also possible that a faster processor marks the task completed first, but BOINC doesn't report it for another several hours.

This randomness, lack of ability to intentionally accomplish being the first to report, and dependance upon the exact timing of a given task's history of reported results is a part of why it has always been maintained that it will averge out over time. You won't the early to report, nor late, concistently.

If we can get to the data, it can be analyzed. At present we can't see it, and I doubt any project wants crawlers going through every single account looking for it.

---

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)

To put in my one cents worth.
what would be interesting would be a graph showing type of PC against credits granted.
That would make crunchers have words with their wives/partners/bank manager!

---

Sorry - a double post.

---

I'm not aware of a single display with all returned WUs on it, for all users

I believe I rather specifically indicated there was no such display, but that you have all the information you need to make one.

The average is supposed to be based on claims/model, not WUs. Faster CPUs finish the models first, and just do more of them.

You are certainly correct, faster CPUs finish models first, but nothing is reported back until the task is completed. Task completion is based on the runtime preference and is stated in hours... not models. With that in mind, please reread my scenario where a slower machine potentially reports first because it completes a 1hr task in 40 minutes, when a machine that is twice as fast will take a full hour (but report 3 times more models).

If we can get to the data, it can be analyzed. At present we can't see it, and I doubt any project wants crawlers going through every single account looking for it.

You can get to the data.
Start with one of dcdc's results for example:
https://boinc.bakerlab.org/rosetta/result.php?resultid=110183173
add 1, no result, add 1, no result, add 1, no result, here's the next one:
https://boinc.bakerlab.org/rosetta/result.php?resultid=110183176
add 1... I think you get the idea. Crawl the results, not the accounts. Via the accounts you would be missing all the tasks of those with hidden machines.

...and no, the webserver hits would be less then ideal for the project. Not something they would want to see from multiple users, nor run every day; but the data is there for public review. Transparency exists.

---

Rosetta Moderator: Mod.Sense

i've started writing a vba application to pick up some stats for this. What's the best time of day to run it (lowest load on rosetta servers)? I assume weekends are quieter than weekdays too?

---

With so many users in so many locations, I don't think there is a particular peak to avoid, or lull to try and hit. Just but sure to build in a delay from one request to the next (I'd say 5 seconds).

I would actually think the weekends might be busier, since more people are home to have their <24x7 machines active. Although the hits to the SAN might be less on the weekends, since the project team is less likely to be hitting it.

---

Rosetta Moderator: Mod.Sense

With so many users in so many locations, I don't think there is a particular peak to avoid, or lull to try and hit. Just but sure to build in a delay from one request to the next (I'd say 5 seconds).

I would actually think the weekends might be busier, since more people are home to have their <24x7 machines active. Although the hits to the SAN might be less on the weekends, since the project team is less likely to be hitting it.

5 second delay, hell no. You'd want to pelt the server with request, as many as you could get without bringing it down, to cover the date needed.

Now who up for a BOINC project to coordinate the requests to collect all this data... We are DC people here after all ;-)


17280 records is all that could be collected a day if it was every 5 second and there are more users in the project than that

---

Team mauisun.org

The results remain on the server for more then a day. So you don't have to pull all of them at the same time. 10,000+ tasks would be more then a sufficient sample size to harvest for statistics.

---

Rosetta Moderator: Mod.Sense

i don't think i need to introduce a delay into the code - my vba is inefficient enough as it is!

---

These WUs should make interesting blips in the graph.

Where are you getting access to all the results on one screen?

---

Nemesis n. A righteous infliction of retribution manifested by an appropriate agent.