Bitcoin Forum
April 19, 2024, 10:08:21 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Looking at Three Systems (poor hash rates on a Xeon)  (Read 2486 times)
inertia (OP)
Newbie
*
Offline Offline

Activity: 35
Merit: 0



View Profile WWW
November 20, 2010, 09:18:26 PM
 #1

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?
"Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what." -- Greg Maxwell
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713521301
Hero Member
*
Offline Offline

Posts: 1713521301

View Profile Personal Message (Offline)

Ignore
1713521301
Reply with quote  #2

1713521301
Report to moderator
1713521301
Hero Member
*
Offline Offline

Posts: 1713521301

View Profile Personal Message (Offline)

Ignore
1713521301
Reply with quote  #2

1713521301
Report to moderator
1713521301
Hero Member
*
Offline Offline

Posts: 1713521301

View Profile Personal Message (Offline)

Ignore
1713521301
Reply with quote  #2

1713521301
Report to moderator
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
November 20, 2010, 09:35:51 PM
 #2

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
inertia (OP)
Newbie
*
Offline Offline

Activity: 35
Merit: 0



View Profile WWW
November 20, 2010, 09:38:40 PM
 #3

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.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5166
Merit: 12865


View Profile
November 20, 2010, 09:52:22 PM
 #4

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
teknohog
Sr. Member
****
Offline Offline

Activity: 519
Merit: 252


555


View Profile WWW
November 20, 2010, 10:05:25 PM
 #5

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.

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
inertia (OP)
Newbie
*
Offline Offline

Activity: 35
Merit: 0



View Profile WWW
November 20, 2010, 11:53:03 PM
 #6

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!