I've completed updating my files on the new rosetta wus. I've included them into the "cross project comparison spreadsheet that is being compiled for Eric K (seti beta). Al (aka Pappa) is also doing this. I've added extra rows to mine for this project to show "old ralph, and all 3 stages of the development of the new Rosetta credit system. Stage 1, 2 credits/model. Stage 2, Calculated credit, and stage 3, calculated with correction factor (NOTE: they haven't disclosed the actual progression, so my names for them are made up by me. I don't know what they're called at rosetta/ralph). The following spreadsheet shows what I've actually done for the various projects and what I've claimed vs what I've been granted. The "benchmark calculated claimed credit" is calculated using (dhrystone+whetstone)x 3600 seconds/1728000, and can be seen at the bottom. In an Ideal credit world the claimed and granted credits would be as close as possible to the benchmark calculated credit/hour.

CC is claimed credit
GC is Granted credit
GWC is Granted Work credit (rosetta new system)

All ralph/rosetta numbers are "Brown" for easy location. Calculated benchmark credit/hour is green. NOTE: this data covers my 5 puters.

It appears to me and my findings that Rosetta is about "spot on" with the new system as it compares to BOTH the "benchmark system" as used by standard clients and also with cross project parity.

Good Job Rosetta.

[edit} darn it, the third column over is supposed to read "# of result entries"

---

And here's the rosetta wus that I've done. I also see a variation in GWC and models, but it comes out pretty decent when averaged.

Einstein have been adjusting their credits to the standard, they reduced it in two steps lately.

They grant about 68% of the previous values now, bringing them very close to the average values of other projects.

Hi mmciastro,


Thanks - these are very interesting data. So the average seems to be okay for the moment but there are occasional anomalies which should be reduced. I hope you will be update your tables further I am interested in such a comparison very much.

---

My main puzzle is that the WUs seem to have shrunk considerably. All of a sudden they do in four or five hours (maybe 8).

---

My main puzzle is that the WUs seem to have shrunk considerably. All of a sudden they do in four or five hours (maybe 8).

What do you mean by shrunk? The WU calculation lenght is based on your preferences. So if you specify 20 hours, each WU will run 20 hours.

Thierry I think he is referring to points/credits !

---

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

Make no mistake This IS the TEDDIES TEAM.

My main puzzle is that the WUs seem to have shrunk considerably. All of a sudden they do in four or five hours (maybe 8).

Andy

I've had a look at your results - and there's a big drop in run-time over the last week or two. Have you changed the Target CPU run time in the preferences, or changed the profile your computer is running under (home, work, school etc)?

---

And here's the rosetta wus that I've done. I also see a variation in GWC and models, but it comes out pretty decent when averaged.

.
.
.
Thanks much for your efforts in aggregating WU data! I very much appreciate your assistance. Please keep up the great work!

I found it much easier to compare when using a "per hour" indicator. I wonder if the project could add that to the results page. It would be easier for people to understand and compare. As it is now users have to figure out whether or not thing have gone bonkers with a calculator. It would be nice to see displayed.

thanks for your support as well. Every once in a while it's good to hear nice things, especially lately.

yes, thanks for your efforts :)
my very limited personal results look similar, most are damn close, with a rare outlier in either direction, seems to average out in the long run for me too though.

My results were averaging out nicely, at least until I got some t000__BOINC_SRAMAN_periLABRELAX_SAVE_ALL_OUT__1178 WUs, which seem to be a bit too generous.
https://boinc.bakerlab.org/rosetta/result.php?resultid=33627639

My results were averaging out nicely, at least until I got some t000__BOINC_SRAMAN_periLABRELAX_SAVE_ALL_OUT__1178 WUs, which seem to be a bit too generous.
https://boinc.bakerlab.org/rosetta/result.php?resultid=33627639

criminy, Me too, I have one from my 2800 that came in last night 33629145 that was supposed to be 20-28 credits but came in at 80+. t000__BOINC_SRAMAN_periLABRELAX_SAVE_ALL_OUT__1178_6987_0

I have ONE on my mobile 3700, 33625267 that also came in overnite. Was supposed to be 40ish but came in at 112ish. t000__BOINC_SRAMAN_periLABRELAX_SAVE_ALL_OUT__1178_3382_0

and ONE on my 3700 33631855 that should have been 43 but came in at 107. also overnite. t000__BOINC_SRAMAN_periLABRELAX_SAVE_ALL_OUT__1178_9512_0

ONE on my P4 1.8 33626258 that came in at 51 and was supposed to be 16. t000__BOINC_SRAMAN_periLABRELAX_SAVE_ALL_OUT__1178_4307_0

Anyone seeing a pattern? I think the t000_BOINC_SRAMANs' need some adjustment from the staff.

Ethan, how about a sticky thread for reporting "suspected" incorrect "granted Work credit" values. I think we found one.

Ethan, how about a sticky thread for reporting "suspected" incorrect "granted Work credit" values. I think we found one.

I support that idea! :-)
edit: Perhaps we wait until the new credit system goes live - David Kim is still working on it.

edit: double post, sorry!

tralala, that was kinda of the reason to have it. It's in testing. much like in ralph, they may need to know where the bugs are so they can squash them. Hopefully without reading every thread to find them. :)

You all are on top of it. The SRAMAN batch was submitted using a credits/model value determined from a ralph test run. So far the test run of 100 jobs has produced 240 structures with a credits/model value of 5.3. But surprisingly, the value on R@h is currently 2.2 with over 100,000 models returned (quite a big sample). Because of this discrepancy, we decided to use R@h to determine the credit/model value as results come in. There will obviously be some variation in the value for the first few results but the value will stabilize rather quickly.

Today, I will be working on the final system and after it's activated, I will post some information about it.

The SRAMAN batch will start using the R@h credits/model value with the new system.

You all are on top of it. The SRAMAN batch was submitted using a credits/model value determined from a ralph test run. So far the test run of 100 jobs has produced 240 structures with a credits/model value of 5.3. But surprisingly, the value on R@h is currently 2.2 with over 100,000 models returned (quite a big sample). Because of this discrepancy, we decided to use R@h to determine the credit/model value as results come in. There will obviously be some variation in the value for the first few results but the value will stabilize rather quickly.

Today, I will be working on the final system and after it's activated, I will post some information about it.

The SRAMAN batch will start using the R@h credits/model value with the new system.

This might happen in the future as well. On Ralph there is currently a daily quota of 20 WU/day, which means in extreme cases 100 jobs could be sent to only 5 hosts. If 3 or 4 of them are using the optimized client the credits/model value will be greatly distorted. There are ways to avoid this but since David Baker asked not to come forward with suggestions I keep my mouth. I'm sure you will find a solution, but in case you want to hear suggestions, feel free... ;-)

But we are not going to use Ralph so the variation will only occur as the first results come in. You can email me your suggestions at dekim at u washington edu.