Message boards : Number crunching : Performance/MIPS
Message board moderation
Author | Message |
---|---|
Send message Joined: 5 Aug 04 Posts: 55 Credit: 87,392 RAC: 0 |
I know my PC isn\'t one of the fastest ( a 2.4Ghz P4 doing about 3.5s/ts ), but I thought the limit on it\'s performance was mostly the processer. Looking at other machines though, this seems to be very little of the problem. The top machine, astroWX\'s, reports MIPS of about a third of mine but is running about 1.7s/ts and my laptop which also reports lower MIPS than my desktop is running at a faster 3s/ts The biggest difference between them that I can see is the O/S - astro is on Linux, my laptop is on Win2000 and my desktop is on WinXp But under boinc, s/ts is calculated from the time the processor spends on the project. So anything the O/S is doing should be discounted as external. So why are they different and what is the relationship between MIPS and s/ts? <a href="http://www.users.globalnet.co.uk/~sykesm/cpdn.html"><img src="http://www.users.globalnet.co.uk/~sykesm/gfx/sig.jpg"></a> |
Send message Joined: 5 Aug 04 Posts: 907 Credit: 299,864 RAC: 0 |
I'm not sure if there's an exact correlation, if you look at that little CPU page I made at http://climateapps2.oucs.ox.ac.uk/cpdnboinc/cpu.html the numbers for MIPS are all over the place. but we use trickles for credit which I guess is a good thing. boy those amd64 fx-53's sure came out of nowhere, I just noticed they are in the lead (hopefully a real run and not unstable! :-) |
Send message Joined: 7 Aug 04 Posts: 2187 Credit: 64,822,615 RAC: 5,275 |
> I'm not sure if there's an exact correlation, if you look at that little CPU > page I made at http://climateapps2.oucs.ox.ac.uk/cpdnboinc/cpu.html the > numbers for MIPS are all over the place. but we use trickles for credit which > I guess is a good thing. boy those amd64 fx-53's sure came out of nowhere, I > just noticed they are in the lead (hopefully a real run and not unstable! :-) > > For the exact same PC (mine), running under Windows and under Linux produces vastly different benchmark results for nearly the same trickle times. Definitely something wrong with the way the PCs are benchmarked under different OS's. The FX-53's were granted a huge amount of credit for finishing the runs, whether that's intended or not. See here for a discussion... http://climateapps2.oucs.ox.ac.uk/cpdnboinc/forum_thread.php?id=286 As for Martin's question about his laptop vs. desktop, maybe the laptop has a higher front side bus. P4 2400s can have 400, 533, or 800 FSB's. Heck, some of them even can use SDRAM instead of DDR I believe. Maybe that has nothing to do with it in this case though? |
Send message Joined: 7 Aug 04 Posts: 187 Credit: 44,163 RAC: 0 |
@ Carl > boy those amd64 fx-53's sure came out of nowhere, I > just noticed they are in the lead (hopefully a real run and not unstable! :-) Hey Carl, could you take a look at my post in <a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/forum_thread.php?id=280">this thread?</a> My FX-53 keeps going waaay down the list and registers around 8s/ts even though it did a whole run at 1.7s/ts. @ Geophi > For the exact same PC (mine), running under Windows and under Linux produces > vastly different benchmark results for nearly the same trickle times. > Definitely something wrong with the way the PCs are benchmarked under > different OS's. The benchmarking has been messed up since back in S@H BOINC beta. It was even worse until they switched to the more industry standard method of benchmarking shortly before public release. It's still pretty funky... <a><img src="http://boinc.mundayweb.com/cpdn/stats.php?userID=18"></a> |
Send message Joined: 30 Aug 04 Posts: 3 Credit: 2,631,402 RAC: 0 |
> For the exact same PC (mine), running under Windows and under Linux produces > vastly different benchmark results for nearly the same trickle times. > Definitely something wrong with the way the PCs are benchmarked under > different OS's. I have an AMD 1800+ with Windows and an 1700+ with Linux. With the standard Boinc-client there is a big difference between the two computers. The Linux maschine only the half of the Win client. Then i have compiled a Boinc-client with some optimazions for the AMD prozessor and now the difference is much smaller, near the value i expected. |
Send message Joined: 19 Aug 04 Posts: 39 Credit: 18,866 RAC: 0 |
> I have an AMD 1800+ with Windows and an 1700+ with Linux. With the standard > Boinc-client there is a big difference between the two computers. The Linux > maschine only the half of the Win client. Then i have compiled a Boinc-client > with some optimazions for the AMD prozessor and now the difference is much > smaller, near the value i expected. > > Are the own-compiled results higher than the standart ones? <img src="http://boinc.mundayweb.com/cpdn/stats.php?userID=70"> |
Send message Joined: 5 Aug 04 Posts: 36 Credit: 2,559,795 RAC: 0 |
This has been an ongoing issue with boinc since last year when the benchmarking models changed. some rather powerful cpu's benchmark very badly, especially with HT enabled for both the windows and linux platforms. I resigned myself to the fact that ssl will not address the issue, and has no apparent desire to change it. I have a dual P4 3.06GHz xeon running Linux.latest.smp with HT enabled. The benchmark(s) look like a pIII on a bad day. Solution: Disable HT, reboot, benchmark, reboot, enable HT, and start your model run. As long as you don't change boinc client rev in the process, your machine won't re-bench on restart, so you're good-to-go, so to speak. Also, the self-built boinc_client weighs in at only 5.6mb whereas the "stock client" unzips to something like 8.9 mb as an execuable. You can tweak boinc_client with processor specific optimizations all you want, but it won't make the client apps (hasum etc.) run any faster in the long run. FWIW - YMMV. JSC aka Xcamel <img src="http://boinc.mundayweb.com/cpdn/stats.php/userID:55/trans:off/.png"> |
Send message Joined: 5 Aug 04 Posts: 426 Credit: 2,426,069 RAC: 0 |
> This has been an ongoing issue with boinc since last year when the > benchmarking models changed. some rather powerful cpu's benchmark very badly, > especially with HT enabled for both the windows and linux platforms. I > resigned myself to the fact that ssl will not address the issue, and has no > apparent desire to change it. I have a dual P4 3.06GHz xeon running > Linux.latest.smp with HT enabled. The benchmark(s) look like a pIII on a bad > day. Solution: Disable HT, reboot, benchmark, reboot, enable HT, and start > your model run. As long as you don't change boinc client rev in the process, > your machine won't re-bench on restart, so you're good-to-go, so to speak. > Also, the self-built boinc_client weighs in at only 5.6mb whereas the "stock > client" unzips to something like 8.9 mb as an execuable. You can tweak > boinc_client with processor specific optimizations all you want, but it won't > make the client apps (hasum etc.) run any faster in the long run. FWIW - > YMMV. > > JSC aka Xcamel > I thought this had been solved (gotten reasonably accurate). The benchmarks should be about half of what they would be with HT disabled. ie. a 3ghz processor with HT enabled should get about the same scores as a 1.5ghz processor without HT. I know it still isn't perfect but I thought it was good enough until more pressing problems were taken care of. <br>John Keck -- BOINCing since 2002/12/08 -- <a href="http://www.boinc.dk/index.php?page=user_statistics&project=cpdn&userid=191"><img border="0" height="80" src="http://191.cpdn.sig.boinc.dk?188"></a> |
Send message Joined: 30 Aug 04 Posts: 3 Credit: 2,631,402 RAC: 0 |
> Are the own-compiled results higher than the standart ones? The value for the double precision MIPS is doubled in the self compiled version. For the integer MIPS the effect is not so high. |
Send message Joined: 26 Aug 04 Posts: 14 Credit: 160,168 RAC: 0 |
> I have a dual P4 3.06GHz xeon running > Linux.latest.smp with HT enabled. The benchmark(s) look like a pIII on a bad > day. Solution: Disable HT, reboot, benchmark, reboot, enable HT, and start > your model run. As long as you don't change boinc client rev in the process, > your machine won't re-bench on restart, so you're good-to-go, so to speak. Does all of this benchmarking affect the speed at which the WU is processed, or strictly for informational purpose? I have a box with 2 physical P4 2.8GHz Xeons with HT enabled, so 4 virtual CPUs. Whether I have one WU loaded and crunching or 4 (one for each CPU), the benchmarks are dismal, and the performance matches. Each WU is only trickling about once a day, and the speed is something like 7.1 sec/TS. My standard P4 2.0GHz by comparison is running at about 2.5 sec/TS. All boxes on versions of W2K. |
Send message Joined: 5 Aug 04 Posts: 36 Credit: 2,559,795 RAC: 0 |
You describe the long and the short of it willy1. It doesn't matter if it's linux or windoze anymore, the benchmarks are equally bad. "Good enough" as John mentioned was supposed to be a very short-term bugfix, which has now turned into what seems a long term feature. Even true smp benches worse than a single proc mb of equal power. If you "roll your own" boinc_client, you'll gain some on the FP bench, and little or nothing on the INT bench. And yes it DOES have a direct effect on how much credit you claim and have granted, because credit is calculated on time-to-complete vs your benchmark. FWIW JSC aka Xcamel <img src="http://boinc.mundayweb.com/cpdn/stats.php/userID:55/trans:off/.png"> |
Send message Joined: 26 Aug 04 Posts: 14 Credit: 160,168 RAC: 0 |
> You describe the long and the short of it willy1. It doesn't matter if it's > linux or windoze anymore, the benchmarks are equally bad. "Good enough" as > John mentioned was supposed to be a very short-term bugfix, which has now > turned into what seems a long term feature. Even true smp benches worse than a > single proc mb of equal power. If you "roll your own" boinc_client, you'll > gain some on the FP bench, and little or nothing on the INT bench. And yes it > DOES have a direct effect on how much credit you claim and have granted, > because credit is calculated on time-to-complete vs your benchmark. > > FWIW > > JSC aka Xcamel > > > <img src="http://boinc.mundayweb.com/cpdn/stats.php/userID:55/trans:off/.png"> > But the benchmark has little or no direct effect on the actual crunching speed? The credit issue is one thing, but the P4 Xeons are actually crunching slowly - about a third of the expected speed. The trickles happen much further apart - one per day instead of almost 3 per day. |
Send message Joined: 6 Aug 04 Posts: 25 Credit: 333,886 RAC: 0 |
If you haven't already, under your Performance Options, try setting "Optimize Peformance:" from Applications to Background Services. When I benchmarked my system, a dual Athlon MP2800+, w/the setting at Applications, I got 1428 Integer/2574 FP. With the setting at Background, it jumped up to 4562 Integer/2574 FP. |
Send message Joined: 5 Aug 04 Posts: 907 Credit: 299,864 RAC: 0 |
for CPDN the "benchmarks" aren't really used other than for information purposes on your display, since we give credits by trickle/timesteps. The model performance is pretty closely tied to your FPU & memory bandwidth, however the benchmark values seem to be "all over the place" so hard to correspond (i.e. if you look <A HREF="http://cpdn.comlab.ox.ac.uk/cpu.zip">at the CPU comparison page</A>) |
Send message Joined: 5 Aug 04 Posts: 55 Credit: 87,392 RAC: 0 |
> for CPDN the "benchmarks" aren't really used other than for information > purposes on your display, since we give credits by trickle/timesteps. The > model performance is pretty closely tied to your FPU & memory bandwidth, > however the benchmark values seem to be "all over the place" so hard to > correspond (i.e. if you look <A HREF="http://cpdn.comlab.ox.ac.uk/cpu.zip">at > the CPU comparison page</A>) > > > That page looks like it lists every machine because there are a duplicated rows showing the same OS, #CPUs, Clock speed etc. Do you have an aggregated version which just lists each machine and OS combination once? |
©2024 cpdn.org