BOINC benchmarks

[Smoke]

Let me say first off, I am not trying to thread crap which is something I'd never do and especially a thread created by one of my closest TeAm Mates, but wouldn't it be more "comparative" to list RACs for each system and what project(s) they are running?

This would give us a data base of what "work" one would expect to achieve with various systems running various projects. That would be helpful to see how your system is performing vis a vis other systems and also provide a little guidance when you are planning future investments in computer equipment.

For those of us running Rosetta, we'd best wait another week or so before we post our RACs because of the change in the way credit is calculated back on or about the 23rd of August.

 

[Assimilator1]

That's not thread crapping mate

Not a bad idea actually ,maybe something worthwhile for a new thread.
But wouldn't the RACs be different between different projects even on the same PC?
I guess it would still provide useful data just that it couldn't be used across projects.

 

[Smoke]

Originally posted by: Assimilator1
.......

But wouldn't the RACs be different between different projects even on the same PC?
I guess it would still provide useful data just that it couldn't be used across projects.

I think the RACs would be different for different projects. A useful database could be accumulated and sorted by: (1) Project(s), (2) System Info, and (3) RAC.

As you said, it probably needs to be a different thread. Want to do the honors? You actually got the ball rolling.

 

[Ken g6]

I hate to spoil the party:brokenheart:, but I don't think RACs will be very useful for benchmarking. It's somewhat OK for projects that have a quorum and initial replication of 1. But if you do anything on your machine besides crunch for the entire month on that one project (including powering down for any reason or running multiple projects), the RAC won't be accurate.

And for projects where the quorum or the inital replication is greater than 1, the RAC shows more about the project than the computer. Take this WU (Please!) for an instance of quorum 1 but initial replicaiton higher. I was the poor sap who claimed 51 cobblestones but got less than 13. (Don't worry, I usually do get the canonical result. )

On the other hand, if WUs are a standard size (e.g. Riesel Sieve), or claim credit proportional to time, individual WUs could provide a better benchmark.

 

[Assimilator1]

Damn ,of course ,any downtime will effect RAC scores & won't be 'factorable' (is that a real word Greg?).

Btw Ken ,what the heck does this mean?

It's somewhat OK for projects that have a quorum and initial replication of 1.

Which projects fall under this catogory?

if WUs are a standard size (e.g. Riesel Sieve), or claim credit proportional to time

 

[Bateluer]

P4 2.53Ghz, BOINC 5.4.11
Measured floating point speed 1250.19 million ops/sec
Measured integer speed 2517.71 million ops/sec

 

[Rattledagger]

Originally posted by: Assimilator1
It's somewhat OK for projects that have a quorum and initial replication of 1.

Which projects fall under this catogory?

if WUs are a standard size (e.g. Riesel Sieve), or claim credit proportional to time

target_nresults = how many copies is initially made per wu to be sent-out. This is also called "Initial Replication" if you click on a wu on web-page.
min_quorum = how many "success" results must be reported for a wu before tries Validation.

A project can use target_nresults > min_quorum, to speed-up validation (and crediting), and to account for errors and "missing" results.


Using min_quorum >= 2 means results is Validated against eachother. This guards against unintentional errors like random hardware-problems and "too much overclock", but also users intentionally trying to pass-on garbage as "real" results. As a "free" bonus, it also makes it much harder for users trying to cheat with too high credit-claims.

Since crediting is not done before wu Validated, it means users often must wait for another user to return their result for same wu before credit is given. With a little "luck", you're paired-off with the user sitting with a 10+ days cache, so you'll have a long list of "pending" results before crediting finally starts...
Still, after a slow startup, most users will reach an equilibrium with fairly steady credit-flow, depending on your own production. Adding/removing a computer can take a couple days before shows-up as increase/decrease in production, but it will show-up after a little time.

Most projects uses min_qourum >= 2, and only if the Science can be easily validated another way should a public DC-project run without redundancy, min_quorum = 1.
Of the "big" projects, CPDN and Rosetta@home uses min_quorum = 1. Of the various small projects, atleast QMC doesn't use redundancy, and probably a couple other also...


As for "claim credit proportional with time"...

Seti_enhanced is proportional to the Scientific Work done, since it "counts flops". This should in theority be proportional with time, but in practice it's not. The problem is, if example 2 computers A and B crunches the exact same wu with AR=0.4 and both uses 6h, if both crunches another wu with example AR=1.5 computer A can use example 1h while computer-B can use 2h...

Since the Scientific Work Done is the same regardless of A or B, the "pay" is also the same for both computers. But, this means one of the computer will get "paid" more per hour than the other for some of the angle-ranges, and this isn't anything to do anything with.

 

[Ken g6]

Originally posted by: Assimilator1
Damn ,of course ,any downtime will effect RAC scores & won't be 'factorable' (is that a real word Greg?).

Btw Ken ,what the heck does this mean?

It's somewhat OK for projects that have a quorum and initial replication of 1.

Which projects fall under this catogory?

if WUs are a standard size (e.g. Riesel Sieve), or claim credit proportional to time

Riesel Sieve, for instance, has a quorum of 1 (1 result validates the WU), and initial replication of 1 (they only send a WU out once, unless it returns an error). But that's not really a good example, since their credit is independent of these benchmarks. uFluids used to be a good example, but now they've gone to quorum 3, initial replication 4. QMC may be like this - I plan to check at some point.

For the second sentence, I don't know what projects are like that. You'd have to graph the time taken vs. credit claimed for one machine, and see if the points form a line. Either that or know the innards like for Riesel Sieve, but like I said that's not a good example because they throw out the claimed credit.

 

[Assimilator1]

Thanks for info guys

Seems we're back to square one ,darn.

Maybe we should all just use SETI classic & the TLC WU to benchmark our rigs for DC?
I'd love to see how fast an o/ced Core2 would crunch S@H1[img]i/expressions/face-icon-small-happy.gif[/img] (bearing in mind my creeky old XPM @ 2.5GHz did it in about 2.1hrs)

I guess we could 'grab' a 'typical' WU from S@H2 to benchmark from like TLC did for S@H1? ,though of course that couldn't be used across projects.
Could a 'typical' WU be grabbed from other projects too?

 

[Wiz]

Just for my own curiosity I have been keeping a spreadsheet that has my machines and their RAC & work done weekly.

I'm only running R@H so that simplifies the situation for me.

Of course I've seen a big dropoff in the RAC over the past few weeks, but work done remains constant.

I can really tell when a client goes silent for any reason, it really hits the avarage hard.
Anyway, even though my AMD 2 ghz machines score a way higher benchmark my P4's do at least twice the amount of work in the same time frame.

There's only one phrase I've got to describe what I think of that: SNAFU

 

[Wiz]

Here's an example.

P4 3.8ghz
Current RAC: 450.84
Sept 14 - 22 Avg work / hr: 17.9788

XP2400+ @ 2ghz
Current RAC: 223.47
Sept 14 - 22 Avg work / hr: 8.4039

XP1700+ @ 2.1ghz
Current RAC: 197.37
Sept 14 - 22 Avg work / hr: 8.9847

Like Smoke said the RAC in R@H is still settling out after the switch to the new system.
The two AMD systems above will continue leveling out towards the low 200's in RAC - maybe another week will provide the real RAC for these systems.

 

[Assimilator1]

Yea it seems the benchmark is waaay off on P4s

 

[bluestrobe]

AMD XP 3000 Barton 1GB RAM

1944 Whetstone
3275 Dhrystone

2.66 P4 Northwood 1GB RAM

1400 Whetstone
2740 Dhrystone

933mhz Dual CPU P3 Coppermine 1GB ECC RAM

0807 Whetstone
1032 Dhrystone

500mhz Dual CPU P3 560MB RAM

0439 Whetstone
0735 Dhrystone

667mhz P3 Coppermine with 360MB RAM

0599 Whetstone
1046 Dhrystone

 

[Dulanic]

9/24/2006 10:23:37 PM||Running CPU benchmarks
9/24/2006 10:24:36 PM||Benchmark results:
9/24/2006 10:24:36 PM|| Number of CPUs: 2
9/24/2006 10:24:36 PM|| 5459 floating point MIPS (Whetstone) per CPU
9/24/2006 10:24:36 PM|| 25199 integer MIPS (Dhrystone) per CPU
9/24/2006 10:24:36 PM||Finished CPU benchmarks


That is using a opt version. C2D 3.08Ghz.

 

[Assimilator1]

v5.5.x? ,that explains the high integer scores

Awesome CPU btw

bluestrobe
Good to see some old PIIIs still in action
What do you crunch on them?

 

[Ken g6]

You like old CPUs?

Here's a PII-400 running Linux with BOINC 5.4.9:
193 floating point MIPS (Whetstone) per CPU
356 integer MIPS (Dhrystone) per CPU

It normally does Seventeen or Bust. I tried running BOINC with Tanpaku on it, but Tanpaku just reported errors.

 

[Assimilator1]

heh ,old faithful a?

What's Tanpaku & why did it error?

Anyone else crunch on an older/slower CPU?

 

[mk]

Originally posted by: Assimilator1
heh ,old faithful a?
Anyone else crunch on an older/slower CPU?

*sigh* not anymore. After 5½ years of dedicated and reliable service I finally retired my 1st cruncher.

933MHz PIII Coppermine

1150 Whetstone
4071 Dhrystone

(using an optimized 5.5.0 BOINC client)

What's Tanpaku?

Tanpaku

 

[Assimilator1]

Seems to be another variant of the F@H idea(?)

RIP PIII 933
Did it go to a good home?

 

[bluestrobe]

Originally posted by: Assimilator1
bluestrobe
Good to see some old PIIIs still in action
What do you crunch on them?

PrimeGrid at the moment but I run all of the projects in my sig in two months rotations. I might be going back to Rosetta on 10/01. I had a 333mhz P2 running but I figured the power usage vs. output wasn't worth it and it's now sitting in storage.

 

[keeleysam]

Core 2 Duo E6600:

Measured floating point speed 10166.32 million ops/sec
Measured integer speed 12882.21 million ops/sec

 

[Assimilator1]

Nice

What clock speed is that at? & what BOINC version?

 

[Bateluer]

Looks like 5.5x to me?

Perhaps someone can explain to me why my 2.4Ghz (128KBL2/400MHZFSB) Celeron is out performing my P4 2.53Ghz? I know the cely is on a dual channel 865 chipset and the P4 is on a single channel 845 chipset. The Celeron RAC is almost 2x the RAC of theP4, and its returned more results in the same time frame.

 

[keeleysam]

Originally posted by: Assimilator1
Nice

What clock speed is that at? & what BOINC version?

That was at 3.2GHz, I'm pretty sure the BOINC version for that wat 5.2.xx, but I'm too lazy to really care. All it does is change how much work is requested.

 

[Assimilator1]

No ,you see if it was the optimised version 5.5.x then that massively inflates the integer scores (read some of the rest of the thread) ,hence I asked.
Awesome CPU anyway

Originally posted by: Bateluer

Perhaps someone can explain to me why my 2.4Ghz (128KBL2/400MHZFSB) Celeron is out performing my P4 2.53Ghz? I know the cely is on a dual channel 865 chipset and the P4 is on a single channel 845 chipset. The Celeron RAC is almost 2x the RAC of theP4, and its returned more results in the same time frame.

That P4 isn't running on PC133 RAM is it?
For some stupid reason (budget systems I guess) Intel thought it would be a good idea to run the P4/Cel on PC133 RAM on some variants of the 845 chipset for a while:roll: ,this absolutely cripples the P4s performance.
If not then the dual channel RAM on the Cel must be the answer (P4s & their Cel variants love bandwidth)