Good luck with that. I tried that about a year ago with very poor results. I was using a VMware workstation (6.0.2, I think) with an Ubuntu 7.04 and 7.10 guest. Performance was in the tank due to overhead from the VM.
I'd be interested though if you have better luck...since this disparity has been around for almost 2 years now...
If you just want to give Linux a try, you'd be better off just booting from a live Linux CD, and installing BOINC to its virtual drive. That way, you won't have the overhead of a VM.
(Sorry Brian, that I didn't think to mention this before.)
No problem. Does that virtual drive run from a USB drive or from main system memory? Either way, if it doesn't use the physical disk it's not a good test.
As for "giving Linux a try", I'm retaking the class from last year with a different instructor. We're using Fedora 8 and we are doing all work in class, at least up to this point (near-midterm), so I haven't even put a VM on my machine... I'm still not terribly impressed from a end-user standpoint, particularly since I have "fancy hardware" that needs customizing for full support (Logitech MX Revolution mouse, X-Fi sound card). At least this different instructor isn't doing any "Sermon on the Mount" kind of stuff. He's trying to go through the material with a minimum amount of evangelizing.
Plan: Run a few more to try to see where the cyclic variance is currently at in the current frequency template. Later, try changing "AuthenticAMD" in the binary to be "AuthenticABC" (the "Naughty Intel" test).
Ok, anybody who would like to do the same: note that you have to prepare an app_info.xml file first, to prevent BOINC from applying the MD5 checksum check on the executable (a modified version would fail the test, probably causing an automatic re-download of the app files).
Hmmm... Good point. I about asked if that was something new because the S5R2 power user app....oh...wait, that has an app_info.xml. DOH! ;-)
Ok, then I'll wait, I will get another system anyways ;-)
Quote:
I read Astro's results from BOINCsimap and I think they are indeed comparatively favorable for the AMDs. There are even a few AMD boxes under the TOP 20 hosts at BOINCSimap, something unusual these days.
Does anybody know what kind of computation BOINCSIMAP does (is it more integer arithmetic, memory intensive data shuffling or floating point arithmetic?).
They havent updated their code for a long time now, as they currently have little work.
I think the P3D Forum could be a good information source, the Simap was the P3D Team's first race back then in the old times ;-)
Interesting is also, that they have 2 apps, simap and hmmer. Hmmer still has an AMD Win bug, the Linux version is faster ... it is also faster in a Linux VM under Win ... hence my idea above to try the same with Einstein.
They tried to tune the code .. but then they gave up, after further optimization gave better results on Intel, and worse with AMD ...
Well, my first task on my 3700+ took 40,833.34 seconds (11.34 hours). As was pointed out, I have no idea if that is a runtime maxima, minima, or somewhere in between...
In between. The frequency was 847.70, and sequence number 596.
According to the cycle length estimating function I posted a while back, the expected cycle period for 847.70 is 210.4, so sequence number 596 is about 83% of the way through the third cycle.
As your next three results are sequentially lower in the same frequency, I'd expect them to drop in time requirement at a nearly linear rate. (I think you are far enough away from the minimum not to have much of a wiggle problem)
I like to be contrary, I suppose... Second task completed in 42,018.56
Brian, I've run liveCD's, although I haven't measured it, linux runs from RAM with minimum usage, going to the CD when needed. Power loss means everything lost. I don't remember it detracting from WU comp times by much.
Oh yeah, Still here, gathering data. turned down the OC on 9950one from 2.7945 to 2.781. Found two different Einstein wus showing 100%, --to completion, and yet still running. Watched for a bit seems stuck, so I turned it down one notch.
Brian, I've run liveCD's, although I haven't measured it, linux runs from RAM with minimum usage, going to the CD when needed. Power loss means everything lost. I don't remember it detracting from WU comp times by much.
Sounds like a viable option, if the runtimes were not as long. I do have a battery backup and the power is not normally out for that long (normally just a flicker or 5 seconds), but I can't (ok, "refuse" is the better term) leave my system running a LiveCD for 10 hours or so at a time, particularly when I need to do school work...
If you are using "Knoppix Live CD" (debian based) , you can actually tell Knoppix to use a big file that it can create on your Windows filesystem as kind of a virtual hard disk. So Knoppix will save changes you make in Linux to (e.g.) your home Directory to this file, but will modify ONLY this file and nothing else on your windows system. Nothing has to installed, and you don't lose anything when switching of the PC.
However, Knoppix 5.3 might be affected by the notorious Linux Kernel bug that affects Einstein@Home, so using a Knoppix 5.2 version should be safer for E@H tests.
I've just about burned off the docking and primegrid work that was on the AMD hosts, and all are almost all Einstein. Now to wait until enough samples are done to look at the disparity at Einstein.
I now have as much as a weeks worth of Einstein on some computers, so more data will be available. I'm not sure how much the following data will change, but I've done an early comparison:
RE: RE: RE: Maybe I'll
)
No problem. Does that virtual drive run from a USB drive or from main system memory? Either way, if it doesn't use the physical disk it's not a good test.
As for "giving Linux a try", I'm retaking the class from last year with a different instructor. We're using Fedora 8 and we are doing all work in class, at least up to this point (near-midterm), so I haven't even put a VM on my machine... I'm still not terribly impressed from a end-user standpoint, particularly since I have "fancy hardware" that needs customizing for full support (Logitech MX Revolution mouse, X-Fi sound card). At least this different instructor isn't doing any "Sermon on the Mount" kind of stuff. He's trying to go through the material with a minimum amount of evangelizing.
RE: RE: Plan: Run a few
)
Hmmm... Good point. I about asked if that was something new because the S5R2 power user app....oh...wait, that has an app_info.xml. DOH! ;-)
RE: Stay tuned. Ok, then
)
Ok, then I'll wait, I will get another system anyways ;-)
They havent updated their code for a long time now, as they currently have little work.
I think the P3D Forum could be a good information source, the Simap was the P3D Team's first race back then in the old times ;-)
Interesting is also, that they have 2 apps, simap and hmmer. Hmmer still has an AMD Win bug, the Linux version is faster ... it is also faster in a Linux VM under Win ... hence my idea above to try the same with Einstein.
They tried to tune the code .. but then they gave up, after further optimization gave better results on Intel, and worse with AMD ...
http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?f=7&t=507&start=105
cheers
Opteron
RE: RE: Well, my first
)
I like to be contrary, I suppose... Second task completed in 42,018.56
Brian, I've run liveCD's,
)
Brian, I've run liveCD's, although I haven't measured it, linux runs from RAM with minimum usage, going to the CD when needed. Power loss means everything lost. I don't remember it detracting from WU comp times by much.
Oh yeah, Still here, gathering data. turned down the OC on 9950one from 2.7945 to 2.781. Found two different Einstein wus showing 100%, --to completion, and yet still running. Watched for a bit seems stuck, so I turned it down one notch.
RE: Brian, I've run
)
Sounds like a viable option, if the runtimes were not as long. I do have a battery backup and the power is not normally out for that long (normally just a flicker or 5 seconds), but I can't (ok, "refuse" is the better term) leave my system running a LiveCD for 10 hours or so at a time, particularly when I need to do school work...
If you are using "Knoppix
)
If you are using "Knoppix Live CD" (debian based) , you can actually tell Knoppix to use a big file that it can create on your Windows filesystem as kind of a virtual hard disk. So Knoppix will save changes you make in Linux to (e.g.) your home Directory to this file, but will modify ONLY this file and nothing else on your windows system. Nothing has to installed, and you don't lose anything when switching of the PC.
However, Knoppix 5.3 might be affected by the notorious Linux Kernel bug that affects Einstein@Home, so using a Knoppix 5.2 version should be safer for E@H tests.
CU
Bikeman
OK, I now have numbers for
)
OK, I now have numbers for Docking:(all are from 64b linux)
Processor/Avg Sec per wu/number of samples
Q6600/ 3008/ 105
9950two/ 3568/ 235
9950one/ 3622/ 230
9600/ 4280/ 179
x2 6000/ 3292/ 124
x2 5200/ 3580/ 108
x2 4800/ 4029/ 98
3700/ 4275/ 18
I've just about burned off the docking and primegrid work that was on the AMD hosts, and all are almost all Einstein. Now to wait until enough samples are done to look at the disparity at Einstein.
I now have as much as a weeks
)
I now have as much as a weeks worth of Einstein on some computers, so more data will be available. I'm not sure how much the following data will change, but I've done an early comparison:
Processor/avg cpu seconds/# of sample
Q6600/ 21666/ 106
9950one/ 33308/ 4
9950two/ 32556/ 3
9600/ 47567/ 9
x2 6000/ 30275/ 11
x2 5200/ 35385/ 14
x2 4800/ 38489/ 5
3700/ 45916/ 1
I went through Primegrid
)
I went through Primegrid again, this time using all available data:
Processor/avg cpu seconds/# of samples
Q6600/ 817/ 211
9950one/ 924/ 327
9950two/ 921/ 292
9600/ 1016/ 165
x2 6000/ 827/ 33
x2 5200/ 915/ 96
x2 4800/ 1022/ 28