Less credit on faster CPU
22 Oct 2005 21:52:29 UTC
Topic 190045
(moderation:
In the past I run 3 computers with Boinc 4.43/einstein 4.81 under W2K and XP with CPU's ranging from 1.8 to 2.8 GHz.
The claimed credit average vary between 60 to 85.
Now a fourth Computer is running under Debian-Linux (2.6.8) with a P4-CPU with 3 GHz - my fastes CPU.
Since starting Einstein at that new machine I was astonished that the claimed credit only wobbles around 40. The Boinc benchmark results in 768 Whetstones and 2052 Dhrystones - this is less then the half compared to my other machines. The bogomips are 5947.
It is interesting that a new WU request 14 hours at the beginning and finished continously after 7 h.
My Linux-friends and I have no idea why this has happened. Can anybody help me?
Ulrich
Less credit on faster CPU
)
Ulrich,
The problem is with the inefficiency of Einstein benchmarks under Linux OS, which you have noticed. Since credit is a factor of (benchmarks * CPU time), your claimed credit suffers in direct relation to the lower benchmarks. I'm not a Linux user, so I am not entirely up-to-date on news relating to it, but I seem to recall that a better Linux app is in development.
Regards,
Michael
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Thank you for your answer,
)
Thank you for your answer, Michael,
it means all computers with a Linux OS has very wrong benchmark results ?! That is funny ! All the donated CPU-power (and electrical powerconsumption too) lead to an enormous amount of wrong credited WU. All the complex computing for finding the right credit for each unit is a joke compared to such errors.
Of course very funny !
Best regards
Ulrich
RE: Thank you for your
)
Ulrich,
I may have to retract that statement, about all Linux benchmarking badly on Einstein. This morning, as I was poking through the message boards, I read a thread about the new Einstein Linux beta, looked at the WU results of the person posting, and the credit claims were around 100!!! So, you may want to look into trying the beta app.
Michael
microcraft
"The arc of history is long, but it bends toward justice" - MLK
RE: ... it means all
)
No, if you have a look in the Cafe, there is a thread about a new linux application. A user (Purple Rabbit) has just posted in that thread and if you look at the results list for his linux box you will see he is claiming in the mid 80s so obviously it is possible. You should go and check out that thread.
Please understand that the value of the science done is in no way compromised by faulty benchmarks. Also, to put things in perspective, if the code to calculate your claim for credit for each result returned were completely stripped out of BOINC, you might be able to save enough cpu cyles to knock a tiny fraction of one second off a 25,000 second crunch time. So please don't think there is any complex computing in the calculation of the credit claim. The more complex benchmarks are done every five days and take about a minute to perform. Even there, you wouldn't even notice the time saved if you completely removed benchmarking.
Please understand that the developers have huge workloads just to get the science right. More cosmetic features like accurate benchmarks and a fair and equitable credit system have to take a lesser priority. If it were a simple issue to fix, they would have done it already. Also please note that it is the BOINC Devs who are responsible for the benchmarking/credit system so the EAH project has to live with what BOINC provides or else divert scarce resources away from the true science effort. I don't think we want that to happen just to make a user's score look better.
Cheers,
Gary.
RE: No, if you have a look
)
Hi, Gary
You didn't wait long to jump back into the fire, did you?
Purple Rabbit's was the recent post, but the preceeding poster, ziegenmelker, was the one to which I was referring (and feeling embarassed about, because his post is almost 4 weeks old and I never noticed it. Talk about foot-in-mouth syndrome). Zieg's knocking out WUs in times that compare very nicely with the same CPU under Windows, and claiming 100+ in credit.
That 0.15 linux app must be really well-written.
Regards,
Michael
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Hi Michael, Things are not
)
Hi Michael,
Things are not always what they seem and apparent anomalies always interest me. On the whole, linux users often seem to get a bit of a raw deal with slower crunching and lower credit claims seeming to be the norm. Because of the optimisations that Bernd has done, it seems that crunching times are much improved for linux. However there are still many instances of low credit claims. But, as you point out, some users are claiming higher than expected. I wonder if we can reconcile this.
In ziegenmelker's case, he stated that:-
So, he built his own BOINC executable based on 4.72. I'm guessing he was able to optimise the build using particular complier flags so as to improve the benchmarks in much the same way that folks over at Seti have been building optimised BOINC clients and science apps. I don't think his 100+ claims per result could only come from an optimised BOINC. I think there has to be another factor at work there for the claim to be that high.
In Purple Rabbit's case, there is no discussion of BOINC or benchmarks, but if you go looking you will see the version is 4.72 and he is claiming in the mid 80's which is what I think a well optimised BOINC may deliver. He may have got this from over at Seti. His EAH production is less than one result per day so he's probably running other projects and an optimised Seti would seem likely.
Please realise there are no negative connotations in the above commentary. Good luck to both of them. If I were running linux and was being penalised by low benchmarks around 40-50 then I'd be finding an optimised BOINC as well in order to try to get my claim on a par with what others are claiming.
Cheers,
Gary.
I would like to express my
)
I would like to express my view about the periodic benchmarking and the credit system. I wrote this message with the hope it could help the project to reach its goals.
In my humble opinion a good credit system is important as well the science algorithms for a simple reason: a great number of users (majority) keep heavily crunching for competitive reasons. Even the opinion of "less competitive spirit" users about the fairness of the system is _very_ important.
If the fairness is "felt" weak, than the computing efficiency will be lower.
Just imagine what happens when in a state the currency heavily looses its value: even the economy (factories, shops, etc) collapses. As a "currency", credits are the guarantors of the system.
This point was the true force of the seti@home "classic" project.
The periodic benchmarking suffers several intrinsic problems: above of all the benchmark requires to be executed within idle pc time in order to be precise. Due this issue the same pc can give quite differents results over the time.
The benchmark it has also to be optimized for every platform, etc.
Here is my little suggestion: within every single WU is there a deterministic computing fraction? (a small part that requires even the same workload in order to be computed)
Yes, is there. (it isn't?)
So what about using it in order to valutate the non-deterministic part of the WU?
Does the development team already considered this way?
I can assure you that all
)
I can assure you that all Project Developers are completely aware of the number of users that the "Stats competition" delivers to each project. I can also assure you that a lot of thought has been put into how to improve the benchmarking so as to deliver the fairest possible system. The discussions I've seen over the last year lead me to believe that it is NOT a simple task. If it were, it would have been done by now. End of story.
There have even been proposals for "mini" reference work units to try to achieve more consistent benchmark results. I'm sure that the complexity of CPU options, OS versions, memory, cache, chipset and Mobo options all compound the problem.
If you think it should be fairly easy to develop a better system than we currently have, I'm sure your code contributions would be greatly appreciated. The place to go to see what the BOINC developers are actively working on is the BOINC developers list. It's quite informative to lurk over there for a while :).
Here is a link to an archive of all the BOINC developer discussions for about the last year.
This is the page where you can actually subscribe to the developers list and make contributions to the development process.
This is a link to the BOINC message boards where BOINC developers are more likely to see comments relating to BOINC. BOINC itself handles everything to do with benchmarks. The individual projects based on BOINC leave that entirely to BOINC.
Cheers,
Gary.
First I am going to point you
)
First I am going to point you to the Wiki articles on benchmarking, and their related links. You need to read those first. Then look at this PDF about some benchmarking programs.
You can also look at my last proposal where I also discuss some of the issues.
But, one comment you made is incorrect. The benchmark is NOT to be optimized to a particular system. If it is, it is no longer an independent measurement. Which is the whole point. Sorry ... :)
Benchmarking is a tough area to understand. And, because of some of its intracacies, can also be an area of "religion" ... where things are believed and taken on faith. And, yes, I do not think that I have the absolute answer either. What I *DO* have is a long history with computers (1975) with testing computers with various benchmarks. Much of the lecture is laced with personal experiences with the specific benchmarks ...
RE: The periodic
)
This is a big problem on my "main" system - estimated completion times increase by almost 20% when Eudora runs.
I fixed it by manually running the benchmarks at 2am every four days. I just set up a scheduled task to run this command:
boinccmd --run_benchmarks
And make sure I only leave BOINC running overnight.
Walt