Just what do those CPU Benchmarks run by the Seti program mean? And what constitutes good benchmarks? Is there a table where I can compare my benchmarks against others?

---

Just what do those CPU Benchmarks run by the Seti program mean?
The "MIPS" means millions of instructions per second. Since computers deal with integers (whole numbers) and floats (decimals and fractions) differently, two ratings are needed.

And what constitutes good benchmarks?
Define "Good". Higher is always better.

Is there a table where I can compare my benchmarks against others?
Not that I'm aware of.

---

Take a look at Paul's Boinc Handbook - Claimed Credit

---

> Take a look at Paul's Boinc Handbook - Claimed Credit
>
>

HELP boinc-doc.net/index.php

---

is it possible that an AMD XP 3000+ (@2200MHz) calculates more MIPS than an AMD 64 3000+ (@1980MHz)?

every application/program/game I start runs faster on the AMD 64, but BOINC measures following:
AMD64
Measured floating point speed 1733.86 million ops/sec
Measured integer speed 3193.81 million ops/sec

AMD XP
Measured floating point speed 2103.29 million ops/sec
Measured integer speed 3564.68 million ops/sec

But then why is a SETI@home WU done in ca. 2:20 by the AMD64 and 2:40 by the AMD XP???

Something wrong with the benchmark (V4.25)?

Andy

---

Want to know your pending credit?


The biggest bug is sitting 10 inch in front of the screen.

> Something wrong with the benchmark (V4.25)?

Something is wrong with every benchmark. The problem is that benchmarks usually don't corespond directly to any of real-life tasks. Thus benchmark can be better or worse suited than real-life task for any given HW platform. The second thing is compiler optimizations. A given compiler can do better job on one kind of code (eg. benchmark) and worse on another kind of job (real-life app) or the other way around.

When comparing performance of the same binaries on different HW platforms (in your case) one can attribute the difference to different HW design.

One ought to consider benchmarks only as (more or less educated) first guess about the performance to expect.

---

Metod ...

> One ought to consider benchmarks only as (more or less educated) first guess
> about the performance to expect.

normally I would agree, but with BOINC it isn't really satisfying, 'cause the claimed credits rely on the benchmarks and if the benchmark is low, I'll get few claimed credits...

should I reverse to 4.19?
(That benchmark gave lot more :-D)

Andy

---

Want to know your pending credit?


The biggest bug is sitting 10 inch in front of the screen.

> > One ought to consider benchmarks only as (more or less educated) first
> guess
> > about the performance to expect.
>
> normally I would agree, but with BOINC it isn't really satisfying, 'cause the
> claimed credits rely on the benchmarks and if the benchmark is low, I'll get
> few claimed credits...
>
> should I reverse to 4.19?
> (That benchmark gave lot more :-D)
>
> Andy
>

Because of the calculation:

claimed credit = ([whetstone]+[dhrystone]) * wu_cpu_time_in_sec / 1728000

the higher the sum of whetstone and dhrystone, the higher the claimed credt.

The granted credit is another matter, it depends on what others claim.

---

> is it possible that an AMD XP 3000+ (@2200MHz) calculates more MIPS than an
> AMD 64 3000+ (@1980MHz)?
>
> every application/program/game I start runs faster on the AMD 64, but BOINC
> measures following:
> AMD64
> Measured floating point speed 1733.86 million ops/sec
> Measured integer speed 3193.81 million ops/sec
>
> AMD XP
> Measured floating point speed 2103.29 million ops/sec
> Measured integer speed 3564.68 million ops/sec
>
> But then why is a SETI@home WU done in ca. 2:20 by the AMD64 and 2:40 by the
> AMD XP???
>
> Something wrong with the benchmark (V4.25)?
>
> Andy
>
You have your cpu's running at differant speeds. Try adjusting the clock speed to match then compare the performance of the two.

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

> > One ought to consider benchmarks only as (more or less educated) first
> guess
> > about the performance to expect.
>
> normally I would agree, but with BOINC it isn't really satisfying, 'cause the
> claimed credits rely on the benchmarks and if the benchmark is low, I'll get
> few claimed credits...

Granted credits really count, not claimed credits.

You claim credits, and BOINC takes the machines that return a work unit, throw out high and low, and grant credit based on the average claimed credit.

Then there are different machines for each work unit.

It averages out.

Besides, which would you prefer: "higher credits" or "fair credits"?

---

Some related info here too:

http://www.pperry.f2s.com/boinc-credit.htm

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***