Windows faster than Linux?
13 Jun 2006 1:20:51 UTC
Topic 191368
(moderation:
How is it possible for someone to have a recent average credit of 600 on a AMD Athlon XP1800+ and Windows XP prof (see here), while I, on a AMD Athlon XP2400+ and Linux, won't get higher as 375 (see here)?
Is the Windows software faster than the software for Linux or am I missing something?
B.t.w.: my AMD is crunching 24 hours a day...
Windows faster than Linux?
)
Yeah, it's true. It seems to be so for all projects. It may also be that the 1800 is running an optimized app. You should try one yourself if you're not already.
My 1800+ (oc'd to a 2100+) is running SuSE 10.1 - just started it a week ago - is just ramping up to 107 with a credit total of less than 1400. I suspect I'll top out at RAC 300 or so but I'm not sure yet. It's my 1st Linux box so we'll see. It topped out at about 450 on SETI.
Luck -
Jim
Those who don’t build must burn. It’s as old as history and juvenile delinquents.
Ray Bradbury - Fahrenheit 451
I am running albert 4.58, and
)
I am running albert 4.58, and don't know of any more optimized app.
I'm just curious (it won't get me back to Windows, I love Linux...): what is the cause of this difference in speed?
On the vast majority of BOINC
)
On the vast majority of BOINC projects, Linux boxes routinely earn about half as much credit as a Windows box with identical hardware.
That's discrimination!
)
That's discrimination! Linux-users, let's unite!
Ah, well: we, linux-users, have the better OS... So let those poor Windows-users have some more BOINC-credit.... :-)
It's all about
)
It's all about micro-optimizing the flops benchmark in boinc-client.
I noticed some of your machines report very low on this benchmark, Jan Gnodde.
http://einsteinathome.org/host/662758 reports 553
http://einsteinathome.org/host/455989 reports 850
and they should be same specs! You should look into this. Higher benchmark, higher claims.
For comparision my equal hardware running FreeBSD (Unix derivate) reports 1000 on that benchmark:
http://einsteinathome.org/host/566669
Hmm, my P-III 800 Dual is
)
Hmm, my P-III 800 Dual is turning in a RAC of 645. It is running a Optimized App though. Split that down its about 322 Rac per cpu with a bit of change left over. So basically my old P-III is out producing your newer unit. How is this possible? Higher grade parts, faster ram so on. It does make a differance.
You also have to look at other parts of the system though. I have a couple systems with the same cpu and memory size, but with one large differance. On one of them it runs on Rambus memory, while the others run PC-133. Both are P-4 1.5's with 256 meg of ram. The pc-133 units turn in a WU every 2.5 hours. The Rambus unit turns in a wu every 1.5 hours. A large differance made due to nothing more than the Ram speed.
So even if your rig is the same basic specs as anothers, simple differances in parts can make a serious differance in times.
Come Join us at Hawaiian Beach Bums
It really does not work that
)
It really does not work that way, Beach Bum. Your dual PIII is claiming it can do 3500 megaflops per CPU per second. That's because you're using the cheating modified unofficial boinc-client.
You really can't compare your numbers to a real hardware.
RE: I noticed some of your
)
That is because that's not the computer that realy does the crunching. I use, besides my home-computers, some computer at work. I start them up from a USB-stick containing DamnSmallLinux, and, of course, the BOINC en Einstein apps, and cant't use an internet-connection there. After hours or days of crunching I take the USB-sticks home, start my home-computer from them, send back the results and get some new work_units. So the real crunching is done on other computers (with other CPU's) than the ones mentioned in those host_details...
The only "real" computers of my hosts are lap.gnodde.lan, main.gnodde.lan and server.gnodde.lan.
RE: It really does not work
)
Now how am I cheating? As I am running a authorized Einstein client,, which is what does the work, not the boinc client. I run Trux's client to bring my numbers back to close to normal.
Look at per cpu , per hour work, It is putting out more work than yours dude.
Its doing it due to higher end parts. Which was what I was pointing out. A simple differance in say ram speed can make a large differance in how fast the WU is processed.
This is the benchmark for the unit, per CPU. Without adjustment.
739 double precision MIPS (Whetstone) per CPU
2032 integer MIPS (Dhrystone) per CPU
So before you claim somebody is cheating, figure out what the client was made for. And then pull your head out. It does not do anything to the actaul hardware stats, it adjust the stats when reporting to make them pull the same amount of credit everybody else would get for the same WU. Which if you knew anything about the client, you can set what projects get the adjustment. So all my clients are set to adjust Einstein, and SETI, but no adjustment to any other project. As they do not have optimized applications.
I dont look at the RAC , I look at the time taken to crunch the WU. take 2 identical speced machines like I have, figure the only differance, IE speed of RAM. And with that one differance, the faster ram machine is cranking out WU's in a full hour faster than the slower RAM machine. SAME CLIENT, SAME APP. Same CPU same size of ram, Identical speed Hard drive and size. Benchmarks mean very little compared to the time it really took to crunch the WU's.
Lets look at real numbers, how long it takes to crunch a WU.
My average time of my PIII-800 is about 11,828.10 per WU. You can go look,
Now your average time on your p4-1400 on linux is 18,681.28 , now why is it that your linux machine at almost twice the speed is still so much slower? I would add it up to cheaper parts, and no optimized app.
Now it seems your 2.8 gig machine is a slightly better match, beating my 800 by a slight margin. Seeing as it looks to do a average WU in 10,815.39.
Maybe its time to load windows and the optimized app, and do the machines full potential of work for einstein.
Come Join us at Hawaiian Beach Bums
RE: That's because you're
)
And if I am useing a so called cheating client, then why is it that I regularly run into this
32735563 600380 7 Jun 2006 22:07:08 UTC 10 Jun 2006 19:37:27 UTC Over Success Done 11,663.23 38.02 61.95
32735564 454249 7 Jun 2006 22:18:28 UTC 8 Jun 2006 15:45:20 UTC Over Success Done 44,029.59 61.95 61.95
32735565 74279 7 Jun 2006 22:21:16 UTC 9 Jun 2006 5:40:05 UTC Over Success Done 54,514.62 78.15 61.95
Seems my cheating client was the lowest claimed credit turned in for the 3. So that makes my claimed credit get thrown out.
So I believe the client must be really cheating for me to turn in lower claimed credits than the standard client does. When are people going to learn, the calibrating client only trys to bring the score closer to the normal, so those not useing a optimized client dont get hosed on credits.
If 3 computers get the same WU, and 2 of those computers are running a optimized application, but no calibrating client. Then the guy who is running the standard app is going to see his claimed credit get thrown out, and get a granted credit worth 1/3 what his machine should have gotten.
Ie optimized unit 1 claimes 7
optimized unit 2 claimes 9
and unit 3 on the standard claims 37
Guess what he gets, he gets a 9, as his is the high claimed, and the other optimized is the low claimed, they get thrown out, leaving the standard app guy pissin and moaning about the optimized app screwing up his credits.
so with the calibrated app bumping things to an average around 35, the standard guy would make out better on this if both the optimized units ran the calibrated client. He would have came out with 35 for his claimed 37, not 9.
So if you look through my 800's history, you will see on most wu's , it is the low credit turn in. So I am getting more credits than I am claiming due to somebody else, not the so called cheating client.
So you can call it cheating, but I will still use it because I think it helps out the guy that is not running optimized to keep what he deserves.
Come Join us at Hawaiian Beach Bums