|
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?
|