Well, if system has only 1 stick, the memory-bandwidth should drop to half (or possibly 1/4th) of currently, meaning much worse than currently. If it's not dropping, it atleast indicates win32 is only using 1 memory-stick...

Taking a look on the manual, wow, 16 memory-slots, 4 channels, so should atleast in theory have a ton of memory-bandwidth...

Hmm, with 4 sticks, the optimal is to put one in each "channel". Make sure it's in "DIMM_00", "DIMM_10", "DIMM_20", "DIMM_30", it's likely easy to put it wrong... Hmm, would guess the BIOS "System Memory Information" will show there each stick is placed?

In BIOS, on "NorthBridge Chipset Configuration", would guess the optimal is:

"MCH Branch Mode" - Interleaving

"*** sparing" - disabled

"Branc 0/1" - enabled

"Rank Interleaving" - good question... Hmm, not sure if 1:1 is best here or not, with 2 sticks in each "branch"... You'll have to test this...

Yes, if running 1 instance shows example 50 credit/hour per core and 8 instances shows 30 credit/hour per core, it's a clear indication your computer is memory-bandwidth-limited in Rosetta@home. In this example Rosetta@home is likely maxed-out at 5 or 6 cores, meaning it's probably possible to find another non-memory-bandwidth-limited BOINC-project and run this for 25% of the time "for free", since Rosetta@home will get the same credit/day regardless of uses all 8 cores or only 6 of them...

Or, switching to faster memory would increase Rosetta@home-production...

If on the other hand 1 instance gives example 50 credit/hour per core and 8 instances gives 47 credit/hour per core, it indicates Rosetta@home is not memory-bandwidth-limited, and there's likely another reason for your computers mediocre Rosetta@home-production...


As for switching to 64-bit OS, this should be done regardless of whatever test-results you're getting, since running an OS that can't use 78% of installed memory doesn't make much sence...

Wouldn't expect OS-switch will change anything significantly for Rosetta@home...
... Except...
I've no idea if it's true or not for some mainboards, but if you're running 4x 4 GB-memory-sticks, it's maybe possible your mainboard somehow only uses the 1st. memory-stick in win32, so in practice it's single-channel-mode in win32...

Yes, if running 1 instance shows example 50 credit/hour per core and 8 instances shows 30 credit/hour per core, it's a clear indication your computer is memory-bandwidth-limited in Rosetta@home. In this example Rosetta@home is likely maxed-out at 5 or 6 cores, meaning it's probably possible to find another non-memory-bandwidth-limited BOINC-project and run this for 25% of the time "for free", since Rosetta@home will get the same credit/day regardless of uses all 8 cores or only 6 of them...

Or, switching to faster memory would increase Rosetta@home-production...

If on the other hand 1 instance gives example 50 credit/hour per core and 8 instances gives 47 credit/hour per core, it indicates Rosetta@home is not memory-bandwidth-limited, and there's likely another reason for your computers mediocre Rosetta@home-production...


As for switching to 64-bit OS, this should be done regardless of whatever test-results you're getting, since running an OS that can't use 78% of installed memory doesn't make much sence...

Wouldn't expect OS-switch will change anything significantly for Rosetta@home...
... Except...
I've no idea if it's true or not for some mainboards, but if you're running 4x 4 GB-memory-sticks, it's maybe possible your mainboard somehow only uses the 1st. memory-stick in win32, so in practice it's single-channel-mode in win32...

I wonder if it would just balance out--less WUs complete, but fewer ones completed faster for more credit per WU....

I think the point was that if a test running say 2 WUs shows better credit per hour per core (with 2 cores) then when running 8 WUs at once, it would basically prove that memory is constrained and therefore it would indicate it might be worth installing an OS that can support all of your memory. Then you could expect to run all 8 at once and yield the same (better) credit per core you saw while running 2.

I wonder if it would just balance out--less WUs complete, but fewer ones completed faster for more credit per WU....

I think the point was that if a test running say 2 WUs shows better credit per hour per core (with 2 cores) then when running 8 WUs at once, it would basically prove that memory is constrained and therefore it would indicate it might be worth installing an OS that can support all of your memory. Then you could expect to run all 8 at once and yield the same (better) credit per core you saw while running 2.

While win-64 will probably have little or no effect in Rosetta@home, didn't you say your system has 16 GB ram? Meaning, over 75% of the installed memory can't be used as long as runs 32-bit...

The BOINC-benchmark seems to be higher on 64-bit, especially integer, but this isn't a good indication of actual performance-increase.


I've no idea if Rosetta@home is influenced by cache-size and memory-bandwidth, so is possibly memory-bandwidth-limited then tries to run 8 instances even with large cache-size... One method to test this would be to see how performs then running only 1 instance, 2 instances, 3 ... upto 8. But, with the large variations in rosetta-wu's, should preferably test this by running the exact same wu on all cores...

Hmm, it would be possible to test if single/dual-channel-memory has any effect, even if runs 8 different wu's...

Could the difference be because he's using XP PRO/64 while I'm using Pro/32?

Nice machine :D

No - 64 bit isn't an advantage for BOINC/Rosetta at the moment (might be in the future). Even with those benchmarks you should be getting higher scores for your granted credit... What are your preferences set as - i.e. do you have 'use at least 8 CPUs' and use 100% of CPU?
You could download Sandra Lite and running a few benchmarks, but it sounds like it's running fine. Are there 8 Rosetta processes each using ~12% CPU utilisation? (easiest way to check is to get Task Manager up and have the 'CPU time' column showing and then sort the column by that so the longest running threads are at the top...

Mod.Sense - can you have a look at this as the scores don't look right. Any ideas?

I don't have any additional means to look in to this either. But let's compare your 2.66 Ghz Xeon with your 3Ghz P4.

I found WUs with the same name and batch number in the results list for each.

Xeon WU CPU seconds: 8,074 Models: 2 claimed: 33.27 granted: 10.39
P4 WU CPU seconds: 9,430 Models: 3 claimed: 20.60 granted: 15.57

Credit is granted based on the completed models. The Xeon only completed two, and so received 2/3'rds the credit of the P4 which completed 3.

But your Xeon is running 8 CPUs, and the P4 only 2. So if you calculated credit per hour of CPU on the above, the Xeon is pulling much more credit per hour. (37.06 vs 11.89). And once it has been reporting in work consistently for 2 weeks, you will see this reflected in the RAC for the Xeon.

Thanks for the link to CPUID! Running that, it says the CPU is running at 2.66Ghz, but I was surpised that the max bandwidth of the FBDIMM PC2-5300 DDR2 667 ram is only 333Mhz. I guess they split the bandwidth for each CPU? I have one 4-Gig Ram chip in Slot 0 of each of 4 banks. This RAM was recommended by ASUS as being compatible, but I just couldn't afford faster RAM.

Your RAM is fast enough. CPUZ reports 333MHz as it's DDR (double data rate) so 333MHz frequency is correct, and will have very little effect as it's pretty quick anyway, and the large cache on those CPUs makes a big difference too.

I'd leave CPUz running for a while and montior the CPU speed just incase it is dropping the CPU speed. It will do that if the CPUs get too hot too.

HTH
Danny

Could the difference be because he's using XP PRO/64 while I'm using Pro/32?

Nice machine :D

No - 64 bit isn't an advantage for BOINC/Rosetta at the moment (might be in the future). Even with those benchmarks you should be getting higher scores for your granted credit... What are your preferences set as - i.e. do you have 'use at least 8 CPUs' and use 100% of CPU?
You could download Sandra Lite and running a few benchmarks, but it sounds like it's running fine. Are there 8 Rosetta processes each using ~12% CPU utilisation? (easiest way to check is to get Task Manager up and have the 'CPU time' column showing and then sort the column by that so the longest running threads are at the top...

a graphics card won't make any difference to Rosetta on that machine, but it might improve surfing etc if you use it for that?

There's definitely something wrong, but I can't see what. I don't recommend this often, but maybe a project reset is required...

Mod.Sense - can you have a look at this as the scores don't look right. Any ideas?

The video on the mother board is very much an issue. Because ANY updates to video uses the main memory bus to make changes to video memory. So, the off board memory is the way to go, even with a cheap $29 card.

So, if you are using the system and even doing something like surfing it can make a big differnece.

This is why a slightly more expensive MB can make all the diffence in the world.

I once changed nothing more than the MB, same CPU, memory, Video card, HDD and saw a 20%+ increase in speed. Part was the way memory was accessed. single vs dual channel ... but, it was just a better MB and well, it was on sale ...

if it is that machine (E5430 Xeon) then it has 12MB L2 cache which it looks like BOINC can't read/report correctly. It doesn't support HT - it's a true 2x4 core machine.

There is something wrong with the credit though - it should be claiming and receiving far more than it is. Is speedstep kicking in?

Other things to check are that you have the most up to date drivers for the motherboard, video card and OS...

You can get a brand new MB and have it have a really old driver/bios ...

A pain, but if this continues that needs to be added to the checklist.

Also check that heat is within tolerances as most processors have "self-help" that will slow the processor for overheat.

There may be other settings in the BIOS that can cause variable processor speeds.

Just for ha-has you could also try another project to see if the same kind of thing is happening there ... sometimes you have to turn over a lot of rocks to isolate an odd problem here and there ...

I'm not sure what "speedstep" is. Where would I see that reported as 'kicking in?'

if it is that machine (E5430 Xeon) then it has 12MB L2 cache which it looks like BOINC can't read/report correctly. It doesn't support HT - it's a true 2x4 core machine.

There is something wrong with the credit though - it should be claiming and receiving far more than it is. Is speedstep kicking in?

Speedstep turns down the speed of your CPUs when they're not in use. An idle priority task (rosetta) might not qualify as 'in use' and so speedstep might be kicking in. Easiest way to tell would be to run cpuz - http://www.cpuid.com/cpuz.php which will show you the speed of your CPUs in real-time. If it varies depending on what you're doing then Speedstep is enabled and might be the cause of the low scores/throughput. You'll be able to change the settings for that in the BIOS but I think there's a way to control it from Windows too.

You're almost certainly right about the L1/L2 issue too - it looks like BOINC is reporting the wrong number!

HTH

if it is that machine (E5430 Xeon) then it has 12MB L2 cache which it looks like BOINC can't read/report correctly. It doesn't support HT - it's a true 2x4 core machine.

There is something wrong with the credit though - it should be claiming and receiving far more than it is. Is speedstep kicking in?

I presume this is the host you are referring to??

I suspect that the tasks that were active at the time you rebooted the machine had not reached a checkpoint yet, and therefore none of their work had been preserved. Some of the tasks being worked on lately are not able to reach a checkpoint very often, and so this further increases the odds of you seeing all 8 starting over at the same time. The good news is that as long as the machine is eventually able to run BOINC long enough, it will recover and continue normally with no intervention. And if this should happen to keep up due to how you use that machine, Rosetta will abort the tasks after 5 restarts in a row with no progress being made. And so then perhaps the new work you get will be able to checkpoint more frequently.

It looks like that host has a very very small L2 cache on the CPU. Indeed it's reporting in with 122K... not Meg, but K! In a nutshell, Rosetta seems to run better on processors with more L2 cache memory. And so your benchmark results are not in line with the actual results you are able to produce when crunching the Rosetta WUs.

This sort of thing is part of why you see so much talk on the internet about one processor being more powerful then another. It's not just as simple as comparing Ghz, and actual performance is very dependant on the type of work you measure the processor doing.

if it is that machine (E5430 Xeon) then it has 12MB L2 cache which it looks like BOINC can't read/report correctly. It doesn't support HT - it's a true 2x4 core machine.

There is something wrong with the credit though - it should be claiming and receiving far more than it is. Is speedstep kicking in?

I presume this is the host you are referring to??

I suspect that the tasks that were active at the time you rebooted the machine had not reached a checkpoint yet, and therefore none of their work had been preserved. Some of the tasks being worked on lately are not able to reach a checkpoint very often, and so this further increases the odds of you seeing all 8 starting over at the same time. The good news is that as long as the machine is eventually able to run BOINC long enough, it will recover and continue normally with no intervention. And if this should happen to keep up due to how you use that machine, Rosetta will abort the tasks after 5 restarts in a row with no progress being made. And so then perhaps the new work you get will be able to checkpoint more frequently.

It looks like that host has a very very small L2 cache on the CPU. Indeed it's reporting in with 122K... not Meg, but K! In a nutshell, Rosetta seems to run better on processors with more L2 cache memory. And so your benchmark results are not in line with the actual results you are able to produce when crunching the Rosetta WUs.

This sort of thing is part of why you see so much talk on the internet about one processor being more powerful then another. It's not just as simple as comparing Ghz, and actual performance is very dependant on the type of work you measure the processor doing.