Title: Looking at Three Systems (poor hash rates on a Xeon) Post by: inertia on November 20, 2010, 09:18:26 PM I didn't set any switches on the command line on any of these configuration.
System A: Xeon x4 @ 3.0GHz Windows 2003 Small Business Server (32-bit), Bitcoin v0.3.15: Limited to 4 CPU: ~900 khash/s Limited to 3 CPU: ~1100 khash/s Limited to 2 CPU: ~1100 khash/s Limited to 1 CPU: ~725 khash/s System B: Core i7 x4 @2.66GHz Mac OS X 10.6.5 (64-bit), Bitcoin v0.3.13: Limited to 4 CPU: ~1800 khash/s Limited to 3 CPU: ~1800 khash/s Limited to 2 CPU: ~1500 khash/s Limited to 1 CPU: ~1000 khash/s System C: Core i7 x4 @2.66 Windows XP x64 Edition (in VMWare Fusion on Mac OS X 10.6.5), Bitcoin v0.03.15: Limited to 4 CPU: ~2100 khash/s Limited to 3 CPU: ~2300 khash/s Limited to 2 CPU: ~1900 khash/s Limited to 1 CPU: ~1200 khash/s I'm particularly concerned about System A. How can 3 GHz only reach 900 khash/s? I thought it was odd that limiting the number of CPUs to 3 allows the hash rate to increase. That's why I looked at System B and C. I wanted to see if the same thing would happen. So System A doesn't scale in a way I would have expected. If I get ~725 on one CPU, I would expect ~2900 on four. But none of my configurations scale like that, so is this a reasonable expectation? I would have never tried limiting any of my systems to 3 CPUs until I started monkeying with System A, trying to figure out why it was getting such poor hash rates. Who would ever think to run 3 CPUs anyway? If you intend to limit, you would probably limit to half, or a quarter, not three quarters. It didn't occur to me to try it until today. Systems B and C are actually the same computer. Both configurations have managed to generate. My theory as to why the virtualize System C is able to reach higher hash rates than the Mac OS X client is that VMWare is able to schedule as with system priorities as opposed to user priorities. Anyway, my main question here is why does a 3.0 GHz system is getting such abismal hash rates as compared to the 2.66 GHz system? Is Core i7 really that superior to Xeon? Title: Re: Looking at Three Systems (poor hash rates on a Xeon) Post by: wumpus on November 20, 2010, 09:35:51 PM Compared to the systems in this topic you get really low hash rates:
https://www.bitcoin.org/smf/index.php?topic=1628.0 I don't know why. Title: Re: Looking at Three Systems (poor hash rates on a Xeon) Post by: inertia on November 20, 2010, 09:38:40 PM Compared to the systems in this topic you get really low hash rates: https://www.bitcoin.org/smf/index.php?topic=1628.0 I don't know why. Indeed. I saw that thread and tried -4way (and even -4way=0), but it didn't slow anything down nor speed it up. Title: Re: Looking at Three Systems (poor hash rates on a Xeon) Post by: theymos on November 20, 2010, 09:52:22 PM It sounds like you actually only have two physical cores, and you're including the virtual hyper-threading cores. This has different effects on different architectures.
Title: Re: Looking at Three Systems (poor hash rates on a Xeon) Post by: teknohog on November 20, 2010, 10:05:25 PM The Xeon brand stands for a huge range of different CPUs, from the Pentium II days to present. Without a model number it is impossible to tell what kind of a processor it is. A 3.0 GHz Xeon could have a Pentium 4 architecture, which is not particularly efficient.
Title: Re: Looking at Three Systems (poor hash rates on a Xeon) Post by: inertia on November 20, 2010, 11:53:03 PM It sounds like you actually only have two physical cores, and you're including the virtual hyper-threading cores. This has different effects on different architectures. Ok, turns out Small Business Server limits the number of physical CPUs to two. Hyperthreading was indeed enabled so a cursory view made it appear there were four CPUs. Disabling hyperthreading brought the hash rate up to 1400 on two CPUs, which seems fairly appropriate. |