How much has your RAC Dropped Since 12/6/06

Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06

To post messages, you must log in.

Previous · 1 . . . 4 · 5 · 6 · 7

AuthorMessage
Profile Feet1st
Avatar

Send message
Joined: 30 Dec 05
Posts: 1755
Credit: 4,690,520
RAC: 0
Message 35167 - Posted: 20 Jan 2007, 22:54:31 UTC

...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/
ID: 35167 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile dcdc

Send message
Joined: 3 Nov 05
Posts: 1829
Credit: 114,368,944
RAC: 53,093
Message 35170 - Posted: 21 Jan 2007, 1:10:54 UTC - in response to Message 35160.  

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

ID: 35170 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Astro
Avatar

Send message
Joined: 2 Oct 05
Posts: 987
Credit: 500,253
RAC: 0
Message 35171 - Posted: 21 Jan 2007, 1:17:40 UTC
Last modified: 21 Jan 2007, 1:18:00 UTC

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.

ID: 35171 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile dcdc

Send message
Joined: 3 Nov 05
Posts: 1829
Credit: 114,368,944
RAC: 53,093
Message 35172 - Posted: 21 Jan 2007, 1:19:22 UTC - in response to Message 35167.  

...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?
ID: 35172 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile dcdc

Send message
Joined: 3 Nov 05
Posts: 1829
Credit: 114,368,944
RAC: 53,093
Message 35173 - Posted: 21 Jan 2007, 1:47:18 UTC - in response to Message 35171.  

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.
ID: 35173 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Michael.L

Send message
Joined: 12 Nov 06
Posts: 67
Credit: 31,295
RAC: 0
Message 35189 - Posted: 21 Jan 2007, 11:56:24 UTC

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'.
ID: 35189 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile dcdc

Send message
Joined: 3 Nov 05
Posts: 1829
Credit: 114,368,944
RAC: 53,093
Message 35191 - Posted: 21 Jan 2007, 13:11:53 UTC - in response to Message 35189.  

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.
ID: 35191 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile Feet1st
Avatar

Send message
Joined: 30 Dec 05
Posts: 1755
Credit: 4,690,520
RAC: 0
Message 35209 - Posted: 21 Jan 2007, 15:40:33 UTC - in response to Message 35191.  

...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/
ID: 35209 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
PUDDIN TAME

Send message
Joined: 3 Oct 06
Posts: 13
Credit: 53,998
RAC: 0
Message 35254 - Posted: 22 Jan 2007, 2:58:04 UTC

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
ID: 35254 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
BennyRop

Send message
Joined: 17 Dec 05
Posts: 555
Credit: 140,800
RAC: 0
Message 35262 - Posted: 22 Jan 2007, 6:01:47 UTC

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.



ID: 35262 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Stu

Send message
Joined: 21 Oct 06
Posts: 11
Credit: 21,798
RAC: 0
Message 35263 - Posted: 22 Jan 2007, 6:08:09 UTC

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
ID: 35263 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile dcdc

Send message
Joined: 3 Nov 05
Posts: 1829
Credit: 114,368,944
RAC: 53,093
Message 35273 - Posted: 22 Jan 2007, 9:45:11 UTC - in response to Message 35263.  

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
ID: 35273 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile Greg_BE
Avatar

Send message
Joined: 30 May 06
Posts: 5658
Credit: 5,670,291
RAC: 2,328
Message 35342 - Posted: 22 Jan 2007, 22:31:04 UTC

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?
ID: 35342 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Stu

Send message
Joined: 21 Oct 06
Posts: 11
Credit: 21,798
RAC: 0
Message 35363 - Posted: 23 Jan 2007, 5:40:03 UTC - in response to Message 35342.  

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

ID: 35363 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Stevea

Send message
Joined: 19 Dec 05
Posts: 50
Credit: 738,655
RAC: 0
Message 35365 - Posted: 23 Jan 2007, 6:48:58 UTC

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...
ID: 35365 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Stevea

Send message
Joined: 19 Dec 05
Posts: 50
Credit: 738,655
RAC: 0
Message 35621 - Posted: 27 Jan 2007, 15:55:56 UTC

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...
ID: 35621 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
FluffyChicken
Avatar

Send message
Joined: 1 Nov 05
Posts: 1260
Credit: 369,635
RAC: 0
Message 35638 - Posted: 27 Jan 2007, 21:14:09 UTC - in response to Message 35621.  

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
ID: 35638 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Previous · 1 . . . 4 · 5 · 6 · 7

Message boards : Number crunching : How much has your RAC Dropped Since 12/6/06



©2024 University of Washington
https://www.bakerlab.org