When checking the other users who crunched the same WU as me, I'm finding that AMD users seem to have a much higher claimed credit. eg. at least twice as much as mine (on a 3Ghz Intel).

I can imagine small differences but why such large ones? When checking out such users all their claimed credits seem higher?

Is this an AMD thing or something else?

> When checking the other users who crunched the same WU as me, I'm finding that
> AMD users seem to have a much higher claimed credit. eg. at least twice as
> much as mine (on a 3Ghz Intel).
>
> I can imagine small differences but why such large ones? When checking out
> such users all their claimed credits seem higher?
>
> Is this an AMD thing or something else?
>
Well, since your computers are "hidden" and you didn't post any examples, it is kind of hard to answer your question.

---

<img src='http://www.boincsynergy.com/images/stats/comb-912.jpg'>

> When checking the other users who crunched the same WU as me, I'm finding that
> AMD users seem to have a much higher claimed credit. eg. at least twice as
> much as mine (on a 3Ghz Intel).

Well - I'm sorry, but I dont agree!

My AMD Opteron constantly claims credit between 20-30 per WU, yet my INTEL P1's and P2's are claiming between 60-80 credits per WU.

Generally speaking - the way credit is calculated is inaccurate at best, and damn right random most of the time. The credit is (roughly) based on CPU Benchmark speed * Calc time - so if you have an inaccurate benchmark, then slower calc times will radically multiply the error.

Hence, my fast AMD (2 to 2.5 hr's per WU) claims small credit, and the slower Intels (1-2 WU's per day) claim high credit.

Personally, I think that credit chould be based on the calculations you do, and not on the speed of your processor. Instead of guessing the credit, why dont they actually count the number of calculations done whilst processing a WU - no more benchmarking required, and only small differences between cpu architectures.

My computers are not hidden (as I actually own them and am authorised to use them - so I dont need to hide!!!) so please check out the results for yourselves.

Cheers, SwissNic.

P.s. Join Team Sausageroll - desperately seeking members!!! ;o)))

---

Actually, I hid my computers from day 1 because I assumed the IP address would be visible to everyone for obvious reasons. They're visible now - at least the option to show them has been set.

And yes, they're all my PCs too, no secrets here, although I don't remember authorising myself ;)

It's a bit weird when you look at a result like this one:

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=3471323

The 4th. result (mine) has 10,119.31sec and a claimed credit of 23.20
The 3rd. result has 14,169.73sec and a claimed credit of 49.98
The 2nd. result has 12,685.77sec and a claimed credit of 48.95
The 1st. had no reply

If you look at the benchmarks there doesn't seem to be that much difference to account for such a difference in the claimed credits?

SwissNic: Interesting what you said about the slower PCs. I have a 1Ghz Intel laptop which has a benchmark figure over 50% that of my 3Ghz and does indeed show higher claimed credits.

So much for the fairer credit system!

Thanks
Mark

All are running XP, as Windows vs Linux on the same HW will give much different results...

Seems you have a dual CPU while the others have only one... (or you have one with HT)

Duals will consistantly request less credit, and I can remember seeing it quite often on Predictor... (you never wanted to have the "other" system being a dual, as you always got less credit than you claimed!)

---

Yes, it's a dual alright.

What gives it the low credit claim? Bad benchmarks? I've noticed before that the integer benchmark in particular can vary by 200% from the lowest figure. e.g. I get from around 1700 to 5000.

Is it the integer benchmark which is causing the wide difference in the credits? I would have thought more weight would have been given to the fp benchmark considering the maths of these projects.

Is anyone working on fixing the dual cpu benchmark problem?

> Yes, it's a dual alright.

> Is anyone working on fixing the dual cpu benchmark problem?
>

I doubt it.. It was well known on Predictor months ago.. That project have been "over" for a few months, although there are rumors it will be back soon!

Same as the different benchmarks/claimed credits beween windows and linux on the same HW. (the same HW running Linux claims ~1/2 the credit if running windows...)

So you can run without HT and claim 40 credits or run HT and claim 20...

---

If you want your hyperthreaded p4 to get a better benchmark, you can go to your bios and turn off hyperthreading. Then benchmark your CPU. Then go back to your bios and turn the hyperthreading back on. Your bench marks will not update again until you either request it or you update to a new version.

---

> If you want your hyperthreaded p4 to get a better benchmark, you can go to
> your bios and turn off hyperthreading. Then benchmark your CPU. Then go back
> to your bios and turn the hyperthreading back on. Your bench marks will not
> update again until you either request it or you update to a new version.
>

Actually not.. Benchmarks are run automatically evey few days (no way to disable) to eliminate this type of stuff as well as to check for HW changes... I think it's every 5 days, IIRC..

So, if you want to do it, you'll need to do it every 4 days! (more often if you crunch multiple project as they might be on different cycles)

It would be best to get the developers to fix this correctly.. We've been waiting for a "linux fix" since june, however....

---

> We've been
> waiting for a "linux fix" since june, however....

Last time I read, it is fixed in the upcoming BOINC 4.5x (alpha at the moment). It was actually a problem with the windows BOINC. The windows compiler was optimizing the benchmark code were it shouldn’t.

---

SETI@home classic workunits: 1,985 CPU time: 24,567 hours



Professor Desty Nova
Researching Karma the Hard Way

Okay - we're all agreed that the current credit rating system sucks. There's differences for Single/Dual setups, HT, Mhz and OS's. I also know that the DEV's are trying to recruit some C++ programmers to work specifically on that area of the project.

One thing I did notice though is the averaging system tents to make up a little bit of the difference. Even though my Dual Opteron constantly claims low 20's and 30's per WU, it's usually the lowest of the 3 results, and therefore I nearly always get more credit than claimed... On the flip side, the slow puters who claim 80+ credits usually only get half of what they claim as they are usually the highest claims...

It is for this reason ONLY that the current system is workable until they release a better form of Credit calculation. (please let it be soon!)

Just my 2 rappen's worth!

Cheers, Nic.

---

I know that the benchmark is inaccurate, but for multiprocessors system, and in particular for pentium 4 HT processors, maybe is better to don't run the benchmark in both virtual processors in the same time but do 2 benchmark to single processors virtual or not that is. The problem is that i don't know if it's possible to choose for an application to run on a processor instead of another.

---

<img src="http://www.boincstats.com/stats/banner.php?cpid=eb8430bdcd1ac999e6fdea2ba9da7454">

> The problem is that i don't know if
> it's possible to choose for an application to run on a processor instead of
> another.

Sorry - but I only know windows, and here it is possible.

If you access the Task Manager (right-click on the menu bar) and select the Processes tab. Select the process you want, and right-click. On the menu at the bottom, you will see "set Affinity". Use this option to force the computer to run a certain process on a certain CPU.

Unfortunately, as BOINC is an SMP aware program, it will set the affinity of it's sub-processes on it's own, and I'm not sure how the benchmark sub-process is launched or works...

Personally - I dont think this is a route forward. The only way to consistantly and accurately award credits is to bug-fix the current system, or re-write it completely.

Cheers, Nic.

---

It is on the to-do list to enable setting affinity for BOINC processes, currently the worker apps can run on any available processor.

The biggest problem I see with HT benchmarks is that performance varies depending on load. And different programs put different loads on the processor due to different I/O and computational needs. So there may be no way to get consistantly accurate scores out of a HT machine. I personally think the best way deal with it is to run the benchmarks under load and average the results. They are currently run under load, but each result overwrites the previous one.

---

BOINC WIKI

BOINCing since 2002/12/8

> The biggest problem I see with HT benchmarks is that performance varies
> depending on load. And different programs put different loads on the processor
> due to different I/O and computational needs. So there may be no way to get
> consistantly accurate scores out of a HT machine. I personally think the best
> way deal with it is to run the benchmarks under load and average the results.
> They are currently run under load, but each result overwrites the previous
> one.

Hey John,

Thanks for the insight.

Tell me - why do you guestimate by taking the approach of benchmark * time to calculate the credit. Why not actually count the number of FLOP's during the calculation? Surely this would produce a far more consistant credit across all platforms and os's, and remove the headache of trying to benchmark many different types of processor architecture?

I understand that adding a { flop_count++ } into the loop would add millions of extra operations, but does this dramaticaly change the WU completion time?

Cheers, Nic.

---

>Tell me - why do you guestimate by taking the approach of benchmark * time to
>calculate the credit. Why not actually count the number of FLOP's during the
>calculation? Surely this would produce a far more consistant credit across
>all platforms and os's, and remove the headache of trying to benchmark many
>different types of processor architecture?
>
>I understand that adding a { flop_count++ } into the loop would add millions
>of extra operations, but does this dramaticaly change the WU completion time?

One problem with counting flops is deciding where to do it. If you do it at the lowest possible level it could add a large overhead. If you do it at a higher level it may not be as accurate as the current method. The current method will most likely always be needed to some extent for estimating how much work to download and for projects that are unwilling or unable to inculde counters in their science apps. That doesn't mean the current system doesn't need to be improved though.

---

BOINC WIKI

BOINCing since 2002/12/8

With my AMD 2800 XP+ I get very much invalid results (file missing or something like that). So I think there should be versions for AMD, Pentium, ... .

---

WARR - Wissenschaftliche Arbeitsgemeinschaft für Raketentechnik und Raumfahrt
(WARR - scientific working group for rocket technology and space travel)

> With my AMD 2800 XP+ I get very much invalid results (file missing or
> something like that). So I think there should be versions for AMD, Pentium,
> ... .
>

Do not use an alpha-release with known fatal upload-bug...

All v4.52-v4.55 have this bug, but is apparently fixed for next release.

> One problem with counting flops is deciding where to do it.

Yes, it would require some actual thought and design work. Is there nobod on the design teams of the various projects capable of that level of thought?

> If you do it at a
> higher level it may not be as accurate as the current method.

That might happen, but seems unlikely with any reasonable amount of design work. Judging by the typical range of claimed credits, the current scheme seems to be accurate to no better than a factor of two.

> The current
> method will most likely always be needed to some extent for estimating how
> much work to download

Initially, perhaps. But using the actual observed times for work units would probably be more accurate once a few units have been processed.

> and for projects that are unwilling or unable to inculde
> counters in their science apps.

Those could be a problem. Perhaps they should simply not bother with credit.

> That doesn't mean the current system doesn't
> need to be improved though.
>
But can it be improved enough to be workable? While it is certainly possible to improve the current implementation, I don't think it can be fixed. It is based on the assumption that there exists some number which, when multiplied by the CPU time, reflects the actual work dones. With many computers these days I don't think such a number exists. The computers simply do not produce work at a fixed rate, but at a rate that varies depending on all sorts of factors -- ambient temperature, what the other CPUs (more or less real or just conceptual) are doing, battery vs. line operation, etc.

---

------- Tom Gutman

Might be improving in near future...

-whispered mysterious stranger