I think the top 1 machine gets used in the equation of the scores.

1 reason to think so, my Top 2 machines dropped immediatly when i stopped it, while the Top 1 machine did not drop 1 unit yet (3,855.88 after 2 days)
my 2 other machines dropped too immediatly.

There is obviously a special treatement for the machine 1.
I know many people already told me that the scoring does not work this way, but i can t explain the RAC of Top 1 with what was explained to me.


who?

Working out RAC http://boinc-wiki.ath.cx/index.php?title=RAC

---

Team mauisun.org

deleted

...My credit has begun so sneak up a little, 3 days ago, we'll see if it continues to climb, or if it just a bump. Before who? shut his machines down.
...

The biggest effect will be work machines + servers coming online again after the holiday which will be returning to the balance of machines that the project had before the holidays. A single machine, even a giant one, will not make a detectable difference.

1 reason to think so, my Top 2 machines dropped immediatly when i stopped it, while the Top 1 machine did not drop 1 unit yet (3,855.88 after 2 days)
my 2 other machines dropped too immediatly.

The RAC only seems to drop at intervals (weekly?), at least it looks like that on my PCs.

---

1 reason to think so, my Top 2 machines dropped immediatly when i stopped it, while the Top 1 machine did not drop 1 unit yet (3,855.88 after 2 days)
my 2 other machines dropped too immediatly.

RAC is only updated when work is sent in, so a machine that abruptly stops sending work will have a RAC that doesn't change.

Once a week a script is run to update the RAC of machines that have stopped sending work.

Another thought just occurred to me. Sorry if this was alreay suggested, but this is a long thread, and I'm not re-reading it all.

Could the drop in RAC be due to migration from 5.4.xx, to 5.7.x and 5.8.x? I believe the later versions of the client have changed the way the benchmarks work. Credits awarded are based on the average of credits claimed, and if the new clients claim less on average...

Do the dates line up?

---

Reno, NV
Team: SETI.USA

Another thought just occurred to me. Sorry if this was alreay suggested, but this is a long thread, and I'm not re-reading it all.

Could the drop in RAC be due to migration from 5.4.xx, to 5.7.x and 5.8.x? I believe the later versions of the client have changed the way the benchmarks work. Credits awarded are based on the average of credits claimed, and if the new clients claim less on average...

Do the dates line up?

The benchmark is just the same in the new versions, the only thing that may have changed is altering the linux benchmark to near the windows one (but I cannot remember if this was actually done or not)

P.S. 5.8.1 (still dev release) has been released for all platforms.

---

Team mauisun.org

the only thing that may have changed is altering the linux benchmark to near the windows one (but I cannot remember if this was actually done or not)

P.S. 5.8.1 (still dev release) has been released for all platforms.

Ah, I'd have to say "yes" to the linux benchmark improvement. I didn't take readings but they were like:

5.6.4 1800/2400

then

5.8.1 1900/3200

OR some such noticable improvement. Dare I say "significant"????

This was on my AMD64 4800 which Windows says more like 2400/4400, but it's closer.
I was testing a different issue, but it certainly caught my eye.

NOTE: I do know of a couple bugs getting squashed about this version, so I'd advise you don't just jump to get it, without understanding that. One is where it won't run both cores of a dual core. Yielding some messages like "waiting for memory", and then "waiting (the replacement for preempted)"

The benchmark is just the same in the new versions, the only thing that may have changed is altering the linux benchmark to near the windows one (but I cannot remember if this was actually done or not)

Really? I just built a new intel machine (intel Pentium D 945). Ran the benchmarks with 5.4.11. Upgraded to 5.7.5, and the results dropped dramatically (about 30%).

---

Reno, NV
Team: SETI.USA

The benchmark is just the same in the new versions, the only thing that may have changed is altering the linux benchmark to near the windows one (but I cannot remember if this was actually done or not)

Really? I just built a new intel machine (intel Pentium D 945). Ran the benchmarks with 5.4.11. Upgraded to 5.7.5, and the results dropped dramatically (about 30%).

There was talk about what compilers where used (the switches) but you'd need to search the dev/alph archives for the past couple of months.

No alterations are mentioned in the code.


I think the problem Astro is seeing is that 5.7/8 include the new memory manager and so is getting triggered into the low memory state so it wil not fire off another process. It's not new in 5.8.1, since I think 5.7 had the same happen. 5.6 without the mem manager of course just ran the task regardless.

Unfortunaly for Rosetta users the General Prefrence options are not htere since it still uses the old 505 server and I think they need to get all the updates to 507 +
The options are (see general refs at seti@home for example)
Use at most 50% of memory when computer is in use
Use at most 90% of memory when computer is idle

So setting them to 100% is probably the same as <=5.6.x
Though I have no idea which is used when if you have selected to run always... OR what happens when the preference isn't there other than assume it uses the defaults.

---

Team mauisun.org

Ah I see you 'many' posts on the alpha list Astro :-)
I guess they will find out what is happening.

---

Team mauisun.org

yes, 5.8.1 at 100% each for those settings still only run one core, so something is "hincky" (xfiles ref). 5.6.4 runs great

From this machine.

55714973 49519902 6 Jan 2007 1:31:02 UTC 8 Jan 2007 10:16:26 UTC Over Success Done 12,641.65 24.54 0.90
55681318 49489434 5 Jan 2007 20:49:44 UTC 8 Jan 2007 3:51:45 UTC Over Success Done 12,997.67 25.23 0.86
55648970 49459718 5 Jan 2007 16:35:47 UTC 7 Jan 2007 23:41:33 UTC Over Success Done 13,106.79 25.44 0.95
55624128 49437007 5 Jan 2007 13:15:57 UTC 7 Jan 2007 19:45:42 UTC Over Success Done 13,248.38 25.71 1.36
55599609 49414544 5 Jan 2007 9:46:58 UTC 7 Jan 2007 15:26:20 UTC Over Success Done 12,953.51 25.14 1.03

Some more evidence for the reduced credits. The numbers at the end are the granted credits, and the ones immediately before are claimed. This is on a P3 1.333GHz, 512MB RAM, XP MCE, 24/7. Is it that errored jobs are being included in the averages?

---

Looks like these are all "looprlx" WUs. I've got two looprlx WUs I see:

55705133 49511000 Over Success Done 86,198.66 143.86 128.49
55591588 49407266 Over Success Done 86,199.78 143.86 137.70

My credit seems more inline with claim on hyperthreaded P4.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Well spotted - they are all looprlx WUs. Mine have generated 2 decoys each (no failures), while yours have generated 281 and 400+!

Obviously my P3 isn't as quick as your P4, but I wouldn't have thought yours would be much more than twice as quick (strangely mine gets a higher average benchmark than yours! It's running the stock client though...) and it certainly isn't 100x faster!

Either there's something wrong with my PC (possible, but not evident - I've watched a few films on it recently, and all the other jobs have run fine), or maybe those were just really long running jobs? Or maybe it's a bug in Rosetta or in the credit process?

---

Mine ran for 24hrs :) So that is a 10x difference. Further knowledge of the rest of the names given in the WU may be required to explain the rest of the varience there. Some WUs are scouting out the backbone and not doing the full atom relax, others do the time consuming full relax.

Here's another looprlx GP120 WU 55705307
Claimed credit 125.129644599415
Granted credit 151.947520562676
for 86359 seconds of CPU time on this host

I also run stock client, no overclocking or other tinkering.

I've got some more of these looprlx WUs and so have suspended my other tasks to crunch them first to get some more data on this.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Mine ran for 24hrs :) So that is a 10x difference.

doh! I should really have spotted that!

Further knowledge of the rest of the names given in the WU may be required to explain the rest of the varience there. Some WUs are scouting out the backbone and not doing the full atom relax, others do the time consuming full relax.

I'll see if i can get some more of these running on that PC too.

---

just uploaded another looprlx:

55773277 49573448 6 Jan 2007 10:13:36 UTC 8 Jan 2007 18:17:25 UTC Over Success Done 12,654.04 24.56 0.78

same as before - the task that ran in-between these tasks was granted normally.

---

Well it (RAC) continues to creep up.

Up over 1240 now, hopefully it will continue to climb and reach it's previous >1325 average.

Would still like to know what happened, even if its over?
But according to these there is still a problem, but these are not effecting me?

just uploaded another looprlx:

55773277 49573448 6 Jan 2007 10:13:36 UTC 8 Jan 2007 18:17:25 UTC Over Success Done 12,654.04 24.56 0.78

same as before - the task that ran in-between these tasks was granted normally.

That's just wrong...0.78?


Seems that the problem remains.

---

BETA = Bahhh

Way too many errors, killing both the credit & RAC.

And I still think the (New and Improved) credit system is not ready for prime time...

Boinc expects all the work units take the same amount of time. The credit system fluctuates in the beginning and averages out over time. Because some of the jobs for the looprlx are short and likely finished before the stats can stabilize, it is the nature of this type of jobs. The jobs run without any problem.

Possu, thank you for the response, we all understand and accept the variability of WUs as you've described. But you've not explained what we're observing here. Have ANOTHER look at dcdc's host. Just look at the claimed vs granted credit. You will see that days after these looprlx GP120 WUs have had time to settle in on an average credit per model, that THIS machine gets about 10% of the credit that is claimed, and yet other types of work on the same machine grant in-line with the credit claimed.

His machine reports 511.47MB of memory. Are the tasks in question the high memory ones? I doubt it because I've got two running now, each taking about 130MB. About 20MB more then normal. On his machine though he only has one CPU. So it is doubtful that he's hitting high pages faults due to this additional 20MB.

What are other hosts seeing on these looprlx GP120 tasks? How does your claimed vs granted credit stack up?

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/