...and so the on-processor cache would seem to be a key component to the difference between the two systems. And I believe Who? has confirmed that Rosetta really needs cache to run well. The question then becomes "to what extent is memory speed and cache size reflected in the BOINC benchmarks?" If these resources were utilized during the benchmarks, then we'd expect the benchmark to reflect to reduced capacity of dc's older system to do work. However, and I think what we're observing here confirms it, I do not believe the BOINC benchmarks really do much but run a small CPU-bound load.

And so we're concluding that the particular WUs in question require more cache then others, in order to run well.

Perhaps it would be appropriate to flag those WUs for high memory systems. Although that wouldn't assure others avoid the problem either.

---

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/

P-III Celerons never got higher than 256KB cache and most had 128KB cache. If dcdc's 1 GHz Celeron is a Coppermine, it should have a 128KB cache. If it's a Tualatin, it should have 256KB. The FSB is 100 MHz for a 1 GHz on both Coppermine and Tualatin.

Good point - that machine does have less cache than feet1st's (it's a tualatin - 256KB).

---

boinc benchmark.php states the following about both benchmark tests:

Neither of the tests really checks how well/fast a system can access memory, and SETI@home (for example) accesses memory a lot.

Here is an example of memory introducing a delay: A Pentium 4 CPU of any speed can calculate the sine of an angle in approximately 170 ticks of its internal clock. It could have performed 170 regular integer additions in this time.

But if it wanted to do an integer addition on a number somewhere out in memory (say it was working on a table of numbers), the CPU might have to wait as much as 260 ticks for this memory integer to be delivered to the CPU. So a badly timed integer+memory operation would take far longer than a sine calculation.

This is where Celeron CPUs can really slow down. Pentium has many features to predict when the CPU might be getting memory, and begins getting it long before the CPU actually calculates with it. Thus there is much less delay for most memory operations.

...and so the on-processor cache would seem to be a key component to the difference between the two systems. And I believe Who? has confirmed that Rosetta really needs cache to run well. The question then becomes "to what extent is memory speed and cache size reflected in the BOINC benchmarks?" If these resources were utilized during the benchmarks, then we'd expect the benchmark to reflect to reduced capacity of dc's older system to do work. However, and I think what we're observing here confirms it, I do not believe the BOINC benchmarks really do much but run a small CPU-bound load.

And so we're concluding that the particular WUs in question require more cache then others, in order to run well.

Perhaps it would be appropriate to flag those WUs for high memory systems. Although that wouldn't assure others avoid the problem either.

While the cache size is definitely important for Rosetta (allowing for diminishing returns as the size increases), I'd be very supprised if such a massive difference could be caused by the cache size difference though. I've just looked through my other tualatin celeron's results for a looprlx gp120 but can't see any.

Anyone know if you can see all the results returned by a comp showing the WU name without having to click on each result?

---

This is where Celeron CPUs can really slow down. Pentium has many features to predict when the CPU might be getting memory, and begins getting it long before the CPU actually calculates with it. Thus there is much less delay for most memory operations.

I don't think the prefetch makes that much difference - maybe 10% or so, but I think the tualatin celeron has prefetch anyway:

http://www.xbitlabs.com/articles/cpu/display/celeron-1200.html

Other than that, the only difference between the tualatin P3 and tualatin celeron is the lower FSB (which isn't relevant for this machine as it's OC'd from 100MHz to 133MHz - so back up to P3 level) and its smaller cache.

There's one way to find out - if anyone can find another coppermine-P3 or tualatin-celeron (as they're both 256KB cache) that's run a looprlx job, but i'd be surprised if the granted is really low like it was on this machine.

---

Not sure if this is just coincidence but for two WUs that i 'updated' almost as soon as they finished my 'granted credit' is higher than 'claimed credit'.
Wondering if the time a WU actually hits the 'results' has an influence on 'granted credit'.

---

Not sure if this is just coincidence but for two WUs that i 'updated' almost as soon as they finished my 'granted credit' is higher than 'claimed credit'.
Wondering if the time a WU actually hits the 'results' has an influence on 'granted credit'.

The earlier you submit your results in a WU's run, the more influence the benchmarks your computer reports have. Computers with a smaller cache or that are running an 'optimised client' will benefit more from early reporting.

---

...Computers with a smaller cache or that are running an 'optimised client' will benefit more from early reporting.

...actually, the folks that report right AFTER such a machine, regardless of their client, will benefit as well.

...and this is part of the expected and normal variabtility which we started the thread on. Once a few dozen clients have reported in, you've got 100s of models reported and the credit per model is probably settling in.

DC's machine was showing poor credit after the WUs had been crunching for many days. And thus we eliminated that early window as being an explaination.

Yes, there certainly ARE times when you are granted MORE credit then you claim. This is again a reflection on how running Rosetta uses different resources in your computer then running the benchmark, and so the results reported by the benchmark will never accurately predict the results you will see running Rosetta (or any other BOINC app). And the credit granted is based on the number of models you crunched, and the time it took you.

---

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/

Hi everyone. I think one of the problems with droping RAC is the WU's that I have been getting the last few days. They take forever to run and I get very few credits for the CPU time invested. The WU I run last night took 4 and a half hours to do one model! I only got 5 credits for it. I have gotten several others like it in the last couple of days. That will pull down anyone's RAC

---

PUDDIN TAME

Stu asked a question and was directed here, so I'll respond here.
522,024.70 1602.03 1502.33 604800
His system shows 522k seconds of work done when if it's running 24*7, it should be showing roughly 604,800 seconds. Something's eathing close to 24 hours worth of seconds of processing time away from Rosetta. He's requesting 1600 credits and getting 1500 credits - which may or may not be typical for a Sempron. It looks like something's running in the background.

---

Thanks for the reply, I just checked I have had the same work unit running now for over 21 hours it has reached 87% but the other clock is still going up saying still 2 hours + and climbing, what do you think I could have running in the background I close everything switch the screen off and let it run most of the day

---

Thanks for the reply, I just checked I have had the same work unit running now for over 21 hours it has reached 87% but the other clock is still going up saying still 2 hours + and climbing, what do you think I could have running in the background I close everything switch the screen off and let it run most of the day

You could leave task manager running. If you go View > Select Columns and check the 'CPU Time' box you'll be able to see if there's any competing processes.

HTH
Danny

---

Don't know if this is the right area to post my question, but why has my user average been dropping like a rock recently? The last 7 w.u.'s have caused a significant drop in my average. However my overall total climbs like normal.
Whats going on?

---

Don't know if this is the right area to post my question, but why has my user average been dropping like a rock recently? The last 7 w.u.'s have caused a significant drop in my average. However my overall total climbs like normal.
Whats going on?

We both seem to be having the same problem, I can,t fathom it out either

---

This has been going on since mid Dec.

No answer as to why yet....?

---

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...

Still no explanation or guesses as to why this is still happening?



Still 75-100 PPD less than my 8 Month average. And going down again...

---

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...

Still no explanation or guesses as to why this is still happening?



Still 75-100 PPD less than my 8 Month average. And going down again...

That graph shows at what about _+ 2% around the middle for a month..

you should create a cc_config.xml file with
<cc_config>
<options>
<save_stats_days>x</save_stats_days>
</options>
</cc_config>

where x is number of days (default 30) to show a longer period.

so all in all over the past month it has been very stable.
There are plenty of explanations/guesses in the posts above (or below ;))

---

Team mauisun.org