Topic: Post Your Hash/Sec and Hardware (Read 39000 times)
http://www.freebiebitcoin.com">Earn free bitcoin
EeePC 1001PX Debian GNU/Linux "Sid"/aptosid
Intel Atom 32bits 1.66 GHz
$ uname -r
2.6.36-0.slh.3-aptosid-686
$ bitcoind getinfo |grep hash
"hashespersec" : 261816,
Intel Atom 32bits 1.66 GHz
$ uname -r
2.6.36-0.slh.3-aptosid-686
$ bitcoind getinfo |grep hash
"hashespersec" : 261816,
I was surprised that my Athlon X2 4850e is actually faster than my laptop with a core i55 430m. 2 much older cores faster than 4 newer intel cores? Seems odd, but whatever.
Athlon X2 4850e, 2,2Mhash/s
Intel Core i5 430m 1,8Mhash/s
Athlon X2 4850e, 2,2Mhash/s
Intel Core i5 430m 1,8Mhash/s
Sandos, 2 of those are HT, try turning the laptop down to limiting it to 2 cores. You'll probably get an increase by doing that.
Doh! Youre right of course, I forgot that it was HT. I did an increase to 2Mhash/s
GTS 250
30 mhps @ default aggression
33 mhps @ aggression = 10
30 mhps @ default aggression
33 mhps @ aggression = 10
Zotac Geforce GTX 460: 53mhash @ default aggression
67khash @ aggression = 14, overclocked to 850Mhz
67khash @ aggression = 14, overclocked to 850Mhz
Desktop processors always faster than laptops... as well as GPUs.
For what it's worht i5 430m has 2 cores and 4 threads
For what it's worht i5 430m has 2 cores and 4 threads
I was surprised that my Athlon X2 4850e is actually faster than my laptop with a core i55 430m. 2 much older cores faster than 4 newer intel cores? Seems odd, but whatever.
Athlon X2 4850e, 2,2Mhash/s
Intel Core i5 430m 1,8Mhash/s
Athlon X2 4850e, 2,2Mhash/s
Intel Core i5 430m 1,8Mhash/s
AMD Phenon II 920 = 4mHash/sec
AMD Phenon II 955 = 6mHash/sec
AMD Phenon II 955 = 6mHash/sec
Windows 7 32-bit
Intel Core2Duo E7300 @ 3600MHz
2 Gb RAM
GF 9800GT
in CPU miner mode i have 3300 khash/sec
in GPU CUDA client i have 18400 khash/sec
Intel Core2Duo E7300 @ 3600MHz
2 Gb RAM
GF 9800GT
in CPU miner mode i have 3300 khash/sec
in GPU CUDA client i have 18400 khash/sec
Machine 1:
Core2Duo @ 2.4 ghz: 3khash
CUDA client & 8800 GTS 512MB: 30khash
Machine 2:
Atom 330N + ION, CUDA client: 2khash
Core2Duo @ 2.4 ghz: 3khash
CUDA client & 8800 GTS 512MB: 30khash
Machine 2:
Atom 330N + ION, CUDA client: 2khash
My main desktop:
Windows 7 Pro
Intel Celeron Dual-Core 3200 @3.8ghz
2GB DDR2 Ram
Geforce 8800GTX
With the stock client I am getting 1300Khash/s.
With the x64bit optimized client I am getting 3300Khash/s
With OSX 10.6.3 and the cuda build on the same machine I get a peak of 5400Khash/s and a low of 4200Khash/s.
Windows 7 Pro
Intel Celeron Dual-Core 3200 @3.8ghz
2GB DDR2 Ram
Geforce 8800GTX
With the stock client I am getting 1300Khash/s.
With the x64bit optimized client I am getting 3300Khash/s
With OSX 10.6.3 and the cuda build on the same machine I get a peak of 5400Khash/s and a low of 4200Khash/s.
Phenom II X6 1090T @ 3.2ghz, WinXP 32bit:
~3600khash/sec
Edit: ~8650khash/sec with 0.3.6
Core 2 Quad Extreme Mobile @ 2.53ghz, Gentoo 32bit:
~2000khash/sec...but if the room is hot, the CPU will get up to 95C, it'll throttle and get ~1600khash/sec. I usually run it on 2 cores @ 1.6ghz, for ~630khash/sec
Edit: 2 cores @ 1.6ghz, getting ~1440khash/sec with 0.3.6
Core 2 Duo @ 2.53ghz, WinXP 32bit:
Was ~1200khash/sec, but fell back to ~800khash/sec for some reason and won't go higher?
Edit: ~2050khash/sec with 0.3.6...still slower by ratio than it was before for some reason
Some Celeron @ ~2ghz, WinXP 32bit:
~220khash/sec
Edit: ~550khash/sec with 0.3.6
Any 32-bit builds of the SSE client? Edit: Official build is quite fast now, but as everyone upgrades it won't matter
~3600khash/sec
Edit: ~8650khash/sec with 0.3.6
Core 2 Quad Extreme Mobile @ 2.53ghz, Gentoo 32bit:
~2000khash/sec...but if the room is hot, the CPU will get up to 95C, it'll throttle and get ~1600khash/sec. I usually run it on 2 cores @ 1.6ghz, for ~630khash/sec
Edit: 2 cores @ 1.6ghz, getting ~1440khash/sec with 0.3.6
Core 2 Duo @ 2.53ghz, WinXP 32bit:
Was ~1200khash/sec, but fell back to ~800khash/sec for some reason and won't go higher?
Edit: ~2050khash/sec with 0.3.6...still slower by ratio than it was before for some reason
Some Celeron @ ~2ghz, WinXP 32bit:
~220khash/sec
Edit: ~550khash/sec with 0.3.6
Any 32-bit builds of the SSE client? Edit: Official build is quite fast now, but as everyone upgrades it won't matter
Actually, I re-examined my changes based on your results and I think I may have messed up the rate calculation. Since it calculates four hashes per loop iteration I multiplied the increment to nHashCounter by four, but in retrospect it's already accounting for that by incrementing the nonce four times as quickly. Ergo, the rate was displayed as 4x higher than actual. For reference, I've generated 300 BTC (six blocks) since I started using the program on the 11th of this month, which works out to about one block out of every 400 (0.25%). Is that about what you're getting? It looks like your version should be a bit faster than mine, which is only to be expected--this was my first attempt at using SSE, or for that matter any kind of SIMD optimization.
I should've known it wouldn't be quite so simple.
Oh yeah, I had to review the khash/s code a few times to get it right. At one point it displayed 12000 but I somehow didn't believe it
I settled for this: in each thread, for each hash that I calculate, increase a counter. Every couple iterations save the khash/s *for this thread* in an array. Then every 30 seconds one thread sums up all the khash/s values and prints the total.
I don't think pure SSE can be exactly four times as fast as a well optimized C code, mostly because SSE lacks rotate instructions. Did you implement SHA completely in SSE or are you mixing SSE and C?
I implemented the rotates as ((x >> y) | (x << (32-y))), using SSE opcodes for the shifts. It's implemented completely in C, using GCC's vector extensions--no direct assembly code. I did use intrinsics for the shift operations, since the shift operators aren't implemented for vectors. The rest looks much like the original version.
Yep, that's more or less what I did. Except I used intrinsics instead of the gcc vector extension, I think that should be more portable. It was pretty easy, I took an existing implementation as a base and then only had to change some macros. Comparing my SSE version with the base yields a speedup of (only) 2.5x. It's not 4x, mainly because the lack of rotate operations in SSE. Packing and unpacking also cause a small decrease in speed.
I also heard that some compilers can generate suboptimal, sometimes even outright wrong, code from intrinsics. I was advised to stay away from them and use pure assembler instead.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
2 threads: ~7700 khash/s
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
I tried to implement your idea and my SSE code is almost exactly 4x as fast as the vanilla code (~2000 khash/s with one thread, up from ~500). However, when running two threads I only get ~3000 khash/s. There is room to optimize my code, but still, the improvement is way lower that yours.
Actually, I re-examined my changes based on your results and I think I may have messed up the rate calculation. Since it calculates four hashes per loop iteration I multiplied the increment to nHashCounter by four, but in retrospect it's already accounting for that by incrementing the nonce four times as quickly. Ergo, the rate was displayed as 4x higher than actual. For reference, I've generated 300 BTC (six blocks) since I started using the program on the 11th of this month, which works out to about one block out of every 400 (0.25%). Is that about what you're getting? It looks like your version should be a bit faster than mine, which is only to be expected--this was my first attempt at using SSE, or for that matter any kind of SIMD optimization.
I should've known it wouldn't be quite so simple.
I don't think pure SSE can be exactly four times as fast as a well optimized C code, mostly because SSE lacks rotate instructions. Did you implement SHA completely in SSE or are you mixing SSE and C?
I implemented the rotates as ((x >> y) | (x << (32-y))), using SSE opcodes for the shifts. It's implemented completely in C, using GCC's vector extensions--no direct assembly code. I did use intrinsics for the shift operations, since the shift operators aren't implemented for vectors. The rest looks much like the original version.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
2 threads: ~7700 khash/s
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
I tried to implement your idea and my SSE code is almost exactly 4x as fast as the vanilla code (~2000 khash/s with one thread, up from ~500). However, when running two threads I only get ~3000 khash/s. There is room to optimize my code, but still, the improvement is way lower that yours.
I don't think pure SSE can be exactly four times as fast as a well optimized C code, mostly because SSE lacks rotate instructions. Did you implement SHA completely in SSE or are you mixing SSE and C?
I upgraded to the x64 optimized client on a box that I run on rare occasions:
Windows XP Pro x64, Intel Xeon X5550 @ 2.67GHz, 8 cores. - 10,400 khash/sec in the display, 9,000 in the hashmeter log.
The rate with stock client used to be about 4,300 khash/sec.
Windows XP Pro x64, Intel Xeon X5550 @ 2.67GHz, 8 cores. - 10,400 khash/sec in the display, 9,000 in the hashmeter log.
The rate with stock client used to be about 4,300 khash/sec.
OK, now for some absolutely incredible performance.
Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Grab SHA state caching Bitcoin here
Wow, this is the biggest jump I've ever seen. Nearly a 250% increase in speed from the stock version, amazing. Now let's see how stable it is Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Grab SHA state caching Bitcoin here
Windows 7 64-bit
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
Bitcoin 64-bit
Ubuntu 10.04 64-bit
AMD Phenom II X4 810 2.61Ghz
2450 khash/sec
So, somewhat faster than in Windows 7. However, ubuntu lags a lot more than Windows does when Bitcoin is going fullbore.
Windows 7 64-bit
AMD Phenom II X4 810 2.61Ghz
I get 4200 - 4400 khash/sec using the SHA state cashing build above (Intel build).
Using the VS build I still get 3100 khash/sec.
Core 2 Duo 6600 (2.4 GHz, 4MB cache)
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
What is this custom SSE hash code?
Now, now. If I told you that then I would lose my advantage.
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
Core 2 Duo 6600 (2.4 GHz, 4MB cache)
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
What is this custom SSE hash code?
Now, now. If I told you that then I would lose my advantage.
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
Core 2 Duo 6600 (2.4 GHz, 4MB cache)
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
What is this custom SSE hash code?
Core 2 Duo 6600 (2.4 GHz, 4MB cache)
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
EDIT: For reference, I was getting about 875 khash/s (two threads) with the stock client and platform-specific compile options (-O3 -march=nocona -msse -msse2 -mfpmath=sse,387). Reorganizing sha.cpp, within the bounds of plain C code, pushed that up to ~1000 khash/s.
2GB RAM
Debian Linux, kernel 2.6.34.1
BitCoin 0.3.0 Beta (32-bit x86), with custom SSE hash code
Very responsive. No significant change in interactive response.
1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
EDIT: For reference, I was getting about 875 khash/s (two threads) with the stock client and platform-specific compile options (-O3 -march=nocona -msse -msse2 -mfpmath=sse,387). Reorganizing sha.cpp, within the bounds of plain C code, pushed that up to ~1000 khash/s.
dual Intel Xeon 5570
. 8 cores (hyperthreaded to 16) @ 5%-10% used
. 32GB memory @ 20% used
. Windows Server 2008 x64 with Hyper-V
. guest Windows Server 2008 x64
. 4 cores @ 100%
. 4GB memory @ 24% used
. Bitcoin x64
. 8 connections
. 68,226 blocks
. ~2,250 khash/s
. system very responsive
. 8 cores (hyperthreaded to 16) @ 5%-10% used
. 32GB memory @ 20% used
. Windows Server 2008 x64 with Hyper-V
. guest Windows Server 2008 x64
. 4 cores @ 100%
. 4GB memory @ 24% used
. Bitcoin x64
. 8 connections
. 68,226 blocks
. ~2,250 khash/s
. system very responsive
I've been comparing various setups on the same server, namely ...
Quad-Core AMD Opteron 2376
8GB memory
In all cases, I'm accessing the net via anonymous VPN.
I get the best results with Ubuntu 10.04 Desktop, installed via wubi on a 1TB WD RE3 7200rpm SATA ...
Ubuntu 10.04 Desktop x86
Bitcoin x86
15 connections
67,556 blocks
~1,900 khash/s
4 cores @ 100%
system very responsive
Ubuntu 10.04 Desktop x64
Bitcoin x64
15 connections
67,689 blocks
~2,150 khash/s
4 cores @ 100%
system very responsive
I've also looked at various VMs running on Windows Server 2008 x64 Standard with Hyper-V. All of the guests live on the 1TB WD RE3 7200rpm SATA, and all have 4 CPUs and 4GB memory. I get ...
Windows Server 2008 x64 Standard guest
apparently para-virtualized
Bitcoin x64
8 connections
67,561 blocks
~1,700 khash/s = 89% of native
4 cores @ 100%
system very responsive
Windows 7 x64 guest
apparently not para-virtualized
Bitcoin x64
8 connections
appears stuck at 1,581 blocks
~1,270 khash/s
4 cores @ 100%
system very responsive
Windows XP SP3 x86 guest
apparently not para-virtualized
Bitcoin x86
8 connections
67,578 blocks
~1,700 khash/s
4 cores @ 100%
system very responsive
Ubuntu 10.04 x86 guest
apparently totally not para-virtualized
Bitcoin x86
15 connections
67,609 blocks
300-400 khash/s
4 cores @ 100%
system sluggish (even without Bitcoin)
More results coming soon
Quad-Core AMD Opteron 2376
8GB memory
In all cases, I'm accessing the net via anonymous VPN.
I get the best results with Ubuntu 10.04 Desktop, installed via wubi on a 1TB WD RE3 7200rpm SATA ...
Ubuntu 10.04 Desktop x86
Bitcoin x86
15 connections
67,556 blocks
~1,900 khash/s
4 cores @ 100%
system very responsive
Ubuntu 10.04 Desktop x64
Bitcoin x64
15 connections
67,689 blocks
~2,150 khash/s
4 cores @ 100%
system very responsive
I've also looked at various VMs running on Windows Server 2008 x64 Standard with Hyper-V. All of the guests live on the 1TB WD RE3 7200rpm SATA, and all have 4 CPUs and 4GB memory. I get ...
Windows Server 2008 x64 Standard guest
apparently para-virtualized
Bitcoin x64
8 connections
67,561 blocks
~1,700 khash/s = 89% of native
4 cores @ 100%
system very responsive
Windows 7 x64 guest
apparently not para-virtualized
Bitcoin x64
8 connections
appears stuck at 1,581 blocks
~1,270 khash/s
4 cores @ 100%
system very responsive
Windows XP SP3 x86 guest
apparently not para-virtualized
Bitcoin x86
8 connections
67,578 blocks
~1,700 khash/s
4 cores @ 100%
system very responsive
Ubuntu 10.04 x86 guest
apparently totally not para-virtualized
Bitcoin x86
15 connections
67,609 blocks
300-400 khash/s
4 cores @ 100%
system sluggish (even without Bitcoin)
More results coming soon
Windows 7 64-bit
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
Bitcoin 64-bit
Ubuntu 10.04 64-bit
AMD Phenom II X4 810 2.61Ghz
2450 khash/sec
So, somewhat faster than in Windows 7. However, ubuntu lags a lot more than Windows does when Bitcoin is going fullbore.
Bitcoin 32-bit
Ubuntu 10.04 64-bit
AMD Phenom II X4 810 2.61Ghz
2150 khash/sec
Bitcoin 64-bit is faster than Bitcoin 32-bit by 300khash/sec, or one old laptop!
Windows 7 64-bit
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
Bitcoin 64-bit
Ubuntu 10.04 64-bit
AMD Phenom II X4 810 2.61Ghz
2450 khash/sec
So, somewhat faster than in Windows 7. However, ubuntu lags a lot more than Windows does when Bitcoin is going fullbore.
2x Quad-Core Xeon E5335 @ 2 GHz
24GB FB-DIMM DDR2 667
4150 khash/s
I'm using the binaries straight from the site. I'll probably compile it later today and see if I can squeeze out a bit more performance.
24GB FB-DIMM DDR2 667
4150 khash/s
I'm using the binaries straight from the site. I'll probably compile it later today and see if I can squeeze out a bit more performance.
Hi all, I'm getting 3440 khash/sec on my HP Z600 desktop with the following specs:
- OS: Windows 7 Professional 64-bit
- Processor: Intel Xeon E5520 @ 2.26 GHz (2 processors)
- RAM: 4GB
Fedora 13 64-bit
Intel Core i7 930 @ 2.8GHz
4 Cores, Hyper Threading on but using only 4 threads.
Uncertain on temps as of yet.
2800kh/s
Intel Core i7 930 @ 2.8GHz
4 Cores, Hyper Threading on but using only 4 threads.
Uncertain on temps as of yet.
2800kh/s
Windows 7 64-bit
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
AMD Phenom II X4 810 2.61Ghz
2000 khash/sec
CPU temperature stabilises at 61C
MB temperature at 40C
I noticed something funny: After running for a long while, the khash/sec went down to 1750-1800. Is this normal? I see the same thing happening on my laptop where it went down to 275 after staying at 300 - 310 for a while.
Here is my set up.
Windows 7 64-bit
Intel Core 2 Duo P7450
2 cores
2.13 GHz
3 GB RAM
749 khashs/sec
Windows 7 64-bit
Intel Core 2 Duo P7450
2 cores
2.13 GHz
3 GB RAM
749 khashs/sec
Ubuntu 10.04
AMD Phenom II X4 920
4 cores
2.8 GHz
8 GB RAM
2718 khashs/sec
the bitcoin process runs on all cores but is "niced" to yield cycles to ordinary processes
AMD Phenom II X4 920
4 cores
2.8 GHz
8 GB RAM
2718 khashs/sec
the bitcoin process runs on all cores but is "niced" to yield cycles to ordinary processes
Hello everyone, first post here. Currently only have bitcoin running on my eee-1000 but after I upgrade my desktop I will have a node running there as well. My eee is running:
intel atom N270 1.6 GHZ dual core.
1.0 GB of ram, about 3/4 of which is free/cache under normal operations.
currently getting between 160 and 180 khash's per second with both cores running.
-Buck
intel atom N270 1.6 GHZ dual core.
1.0 GB of ram, about 3/4 of which is free/cache under normal operations.
currently getting between 160 and 180 khash's per second with both cores running.
-Buck
I'm sorry. It could very well be that your hyper-v is running linux in full-virtualization mode (full is bad). If you ran the client OS in para-virtualization mode, then it would run near full speed. I am not sure if hyper-v supports that or what. Linux is happy to run in para-virtualization mode, so most VM systems can do that just fine.
Yes, that's the problem. Microsoft's para-virtualization support for Linux is minimal. It supposedly works for Red Hat and Debian (
) but I've had no joy with Ubuntu.Perhaps I'll set up some Red Hat VMs. There's another project that needs a virtual network of Red Hat VMs.
Or perhaps Win XP VMs, if I can dig up enough full-install packages.
Thanks, all, for your help.
I'm sorry. It could very well be that your hyper-v is running linux in full-virtualization mode (full is bad). If you ran the client OS in para-virtualization mode, then it would run near full speed. I am not sure if hyper-v supports that or what. Linux is happy to run in para-virtualization mode, so most VM systems can do that just fine.
Hyper-v is a microsoft product. That is your answer. It runs windows fine I'm sure, but it is your problem, not VM technology itself.
For example, I run bitcoin under Xen (linux/linux) and get khash/sec numbers that run with any I've seen posted.
Theoretically, I wouldn't think VM would affect bitcoin performance (coin mining at least) more than maybe a minute amount. The hashing code has zero system calls that need to be passed outside the virtual host, there is no overhead, especially in any good VM system like Xen that utilizes Thread Local Storage, Etc...
(not saying Xen is the best, only that bitcoin should run undetectably less good inside a VM as out; it does for me.)
For example, I run bitcoin under Xen (linux/linux) and get khash/sec numbers that run with any I've seen posted.
Theoretically, I wouldn't think VM would affect bitcoin performance (coin mining at least) more than maybe a minute amount. The hashing code has zero system calls that need to be passed outside the virtual host, there is no overhead, especially in any good VM system like Xen that utilizes Thread Local Storage, Etc...
(not saying Xen is the best, only that bitcoin should run undetectably less good inside a VM as out; it does for me.)
What's the VM bottleneck for Bitcoin? Is it CPU virtualization?
Ubuntu on Hyper-V is particularly slow, I admit. Win 7 x64, OTOH, screams. Damn.
Ubuntu on Hyper-V is particularly slow, I admit. Win 7 x64, OTOH, screams. Damn.
Why would we want to slow Bitcoin down?
Wouldn't it suck if NSA (or Google) cornered Bitcoin market? 
Well, running Bitcoin in an VM slows it down, significantly.
It's better to run it directly on the host operating system.
I suggest you do that.
Why is bitcoin so slow on VMs? Is it intentional, to prevent corporate/government cornering? Or It's better to run it directly on the host operating system.
I suggest you do that.
Why would we want to slow Bitcoin down?
No see, Virtual Machines can cause quite some overhead. And Bitcoin can really use all the resources it can get to generate higher.
As with any computer program, or even any real world system, everything is based around bottlenecks.
The slowest part in a machine determines the actual speed.
More on that here: http://en.wikipedia.org/wiki/Bottleneck
Well, running Bitcoin in an VM slows it down, significantly.
It's better to run it directly on the host operating system.
I suggest you do that.
Why is bitcoin so slow on VMs? Is it intentional, to prevent corporate/government cornering? Or It's better to run it directly on the host operating system.
I suggest you do that.
Edit:
Ubuntu 10.04 Server x64
Gateway DX4710
Intel Core2 Quad Q6600
5.5GB real memory
4 CPUs
2,472 khash/s
My mini-cluster of Intel(R) Core(TM)2 Quad CPU Q8400 on FreeBSD 8.0/amd64
hashmeter 32 CPUs 20,704 khash/s
(2588 khash/s per node!! GO TEAM FREEBSD! Roast those penguins!
)
hashmeter 32 CPUs 20,704 khash/s
(2588 khash/s per node!! GO TEAM FREEBSD! Roast those penguins!
)
With the default build (Linux x86_64)
Desktop (Xeon x3350 @ 3.2Ghz, 4GB RAM):
4 cores - ~ 3300 khash/s
Laptop (ASUS w/ Core2 Quad Q9000 @ 2GHz):
4 cores - ~ 2000 khash/s
Desktop (Xeon x3350 @ 3.2Ghz, 4GB RAM):
4 cores - ~ 3300 khash/s
Laptop (ASUS w/ Core2 Quad Q9000 @ 2GHz):
4 cores - ~ 2000 khash/s
Thanks, Xunie. The host isn't secure, for many reasons (MS knows me well, basically). The VM is running encrypted filesystem, and connects via private VPN.
I'm also playing with Ubuntu 10.04 Server on old gaming machine. I just need to figure out command line access, because there's no GUI.
I'm also playing with Ubuntu 10.04 Server on old gaming machine. I just need to figure out command line access, because there's no GUI.
Hello, all I'm new to Bitcoin. I'm running client on Ubuntu 10.04 x86 VM with two CPUs and 2.5GB memory. The VM's running in Hyper-V on Windows Server 2008 x64, on old Dell SC1435 with Quad-Core AMD Operon 2376 and 8BG memory.
It's been up for two days, has 15 connections, and currently sees 65,564 blocks. This morning, it generated "50", and tells me that they'll mature in 9 more blocks. That seems more-or-less normal, yes?
What's odd is that it's running at 300-500 khash/s when otherwise idle, but is using only about 1% host CPU on average, with occasional bursts to 10%-20%. The bursts seem to correlate with disk and network activity, which makes sense.
Anyway, I'm curious why I'm not seeing higher khash/s, given that there's plenty of resources available.
Could it be because the VM is running without Linux integration services (which I haven't managed to install successfully)? Or could it be because I'm not port forwarding? And FWIW, I can't do that because I'm connecting through OpenVPN.
How can I increase resource utilization? Alternatively, I'm sure that Ubuntu would be happy with one CPU and 1GB memory. Would running four such VMs be workable?
Thank you. This is fun.
I'm new to Bitcoin. I'm running client on Ubuntu 10.04 x86 VM with two CPUs and 2.5GB memory. The VM's running in Hyper-V on Windows Server 2008 x64, on old Dell SC1435 with Quad-Core AMD Operon 2376 and 8BG memory.It's been up for two days, has 15 connections, and currently sees 65,564 blocks. This morning, it generated "50", and tells me that they'll mature in 9 more blocks. That seems more-or-less normal, yes?
What's odd is that it's running at 300-500 khash/s when otherwise idle, but is using only about 1% host CPU on average, with occasional bursts to 10%-20%. The bursts seem to correlate with disk and network activity, which makes sense.
Anyway, I'm curious why I'm not seeing higher khash/s, given that there's plenty of resources available.
Could it be because the VM is running without Linux integration services (which I haven't managed to install successfully)? Or could it be because I'm not port forwarding? And FWIW, I can't do that because I'm connecting through OpenVPN.
How can I increase resource utilization? Alternatively, I'm sure that Ubuntu would be happy with one CPU and 1GB memory. Would running four such VMs be workable?
Thank you. This is fun.
Well, running Bitcoin in an VM slows it down, significantly.
It's better to run it directly on the host operating system.
I suggest you do that.
Hello, all I'm new to Bitcoin. I'm running client on Ubuntu 10.04 x86 VM with two CPUs and 2.5GB memory. The VM's running in Hyper-V on Windows Server 2008 x64, on old Dell SC1435 with Quad-Core AMD Operon 2376 and 8BG memory.
It's been up for two days, has 15 connections, and currently sees 65,564 blocks. This morning, it generated "50", and tells me that they'll mature in 9 more blocks. That seems more-or-less normal, yes?
What's odd is that it's running at 300-500 khash/s when otherwise idle, but is using only about 1% host CPU on average, with occasional bursts to 10%-20%. The bursts seem to correlate with disk and network activity, which makes sense.
Anyway, I'm curious why I'm not seeing higher khash/s, given that there's plenty of resources available.
Could it be because the VM is running without Linux integration services (which I haven't managed to install successfully)? Or could it be because I'm not port forwarding? And FWIW, I can't do that because I'm connecting through OpenVPN.
How can I increase resource utilization? Alternatively, I'm sure that Ubuntu would be happy with one CPU and 1GB memory. Would running four such VMs be workable?
Thank you. This is fun.
I'm new to Bitcoin. I'm running client on Ubuntu 10.04 x86 VM with two CPUs and 2.5GB memory. The VM's running in Hyper-V on Windows Server 2008 x64, on old Dell SC1435 with Quad-Core AMD Operon 2376 and 8BG memory.It's been up for two days, has 15 connections, and currently sees 65,564 blocks. This morning, it generated "50", and tells me that they'll mature in 9 more blocks. That seems more-or-less normal, yes?
What's odd is that it's running at 300-500 khash/s when otherwise idle, but is using only about 1% host CPU on average, with occasional bursts to 10%-20%. The bursts seem to correlate with disk and network activity, which makes sense.
Anyway, I'm curious why I'm not seeing higher khash/s, given that there's plenty of resources available.
Could it be because the VM is running without Linux integration services (which I haven't managed to install successfully)? Or could it be because I'm not port forwarding? And FWIW, I can't do that because I'm connecting through OpenVPN.
How can I increase resource utilization? Alternatively, I'm sure that Ubuntu would be happy with one CPU and 1GB memory. Would running four such VMs be workable?
Thank you. This is fun.
Heh. I'm using a HP Pavilion 8670c with 384MB RAM and a 600MHz Pentium III. I'm only getting 50 khash per second.
AMD-64 X2 TK-53 1.7Ghz
1 Core: 310 khash/sec
2 Cores: 590 khash/sec (and an overheating laptop)
1 Core: 310 khash/sec
2 Cores: 590 khash/sec (and an overheating laptop)
Intel Core i5-450M (2.4Ghz)
4GBs RAM
*One Core => 350-450 khash/sec
*Two Cores => 600-850 khash/sec
*Three Cores => 750 - 900khash/sec
*Four Cores => 800-900 khash/sec
Using the regular build, 0.3 on Win7/64bit
4GBs RAM
*One Core => 350-450 khash/sec
*Two Cores => 600-850 khash/sec
*Three Cores => 750 - 900khash/sec
*Four Cores => 800-900 khash/sec
Using the regular build, 0.3 on Win7/64bit
Really sorry about this but there was a typo in the patch.. I replaced the original version with a fixed one. The original patch was actually not incrementing the nonce so it messed up the generation 
new patch: http://heliacal.net/~solar/bitcoin/bitcoin-svn-79-perfcounter-2010-06-02.patch
Laszlo and I talked about this on IRC. I made a slightly cleaned up version against r80 of the SVN (no differences, but it might be a hair faster). You can get it here:new patch: http://heliacal.net/~solar/bitcoin/bitcoin-svn-79-perfcounter-2010-06-02.patch
http://www.alloscomp.com/bitcoin/bitcoin-svn-80-perfcounter-cleaned-2010-06-07.patch
Or you can just get the combined patch that also includes the net.h workaround and some RPC extensions:
http://www.alloscomp.com/bitcoin/bitcoin-svn-80-combined-2010-06-07.patch
Really sorry about this but there was a typo in the patch.. I replaced the original version with a fixed one. The original patch was actually not incrementing the nonce so it messed up the generation
new patch: http://heliacal.net/~solar/bitcoin/bitcoin-svn-79-perfcounter-2010-06-02.patch
new patch: http://heliacal.net/~solar/bitcoin/bitcoin-svn-79-perfcounter-2010-06-02.patch
Sure. My computers ran all last night without generating again.
http://validity.alloscomp.com/bitcoin/vps.debug.log.bz2 (2.1MiB compressed)
http://validity.alloscomp.com/bitcoin/laptop.debug.log.gz (489KiB compressed)
Thanks.
http://validity.alloscomp.com/bitcoin/vps.debug.log.bz2 (2.1MiB compressed)
http://validity.alloscomp.com/bitcoin/laptop.debug.log.gz (489KiB compressed)
Thanks.
Can you post it on a web server or something? It sounds pretty large. I could take a look but it's probably hard to find anything among all the spam.
I'm on campus internet. It's pretty reliable. It occasionally asks me to reauthenticate with the master server, but that's fairly rare. The VPS is el-cheepo, but it never drops for more than a second or two. Would it help for me to post or link my debug.log?
The debug.log is truncated when you restart the app, not sure if it does it periodically too.. are you perhaps getting disconnected/reconnected frequently or having really high latency? A poor connection could prevent you from generating, though I wouldn't think you would be having that issue at the VPS.
Athlon FX-55 (socket 939) on linux
**Perf - thread 1 : 575k iter/sec
**Perf - total : 575k iter/sec (1 threads)
**Perf - thread 1 : 575k iter/sec
**Perf - total : 575k iter/sec (1 threads)
That seems odd.. are you seeing any instances of 'proof-of-work' if you grep debug.log?
No, I'm not seeing that on either. On my workstation, the debug.log file has for some reason been clipped at the beginning. It's around 4.8 MiB. On my VPS, it's 20MiB and going strong.
That seems odd.. are you seeing any instances of 'proof-of-work' if you grep debug.log?
I haven't generated a block since 6/3/2010 while running my VPS (up to 2280 khps) 24/7 and my laptop (1200 khps) every night. I'm rather disappointed.
You should compile for 32 bit windows (mingw).. 64 bit would just make it use more memory but you'll have to build all the dependencies that way too, if it's even possible with wxWidgets and stuff..
Win7 64-Bit here.
Make sure you guys try compiling with -O2 instead of -O0 (check your makefiles). It improved performance a lot for me.
Laszio, I tried that but it failed. I'll see if I can't address the specific error. Line 15 in net.h failed to compile.Quote from: SmokeTooMuch
someone make a windows binary for noobs/lazy people like me ^^
I can try if nobody else replies and this doesn't get accepted into mainline. Not sure what the Windows dependencies are or if I can cross-compile. Win64 or 32?
E2200 C2D 2Ghz CPU
**Perf - thread 1 : 495k iter/sec
**Perf - thread 2 : 495k iter/sec
**Perf - total : 990k iter/sec (2 threads)
**Perf - thread 1 : 495k iter/sec
**Perf - thread 2 : 495k iter/sec
**Perf - total : 990k iter/sec (2 threads)
Make sure you guys try compiling with -O2 instead of -O0 (check your makefiles). It improved performance a lot for me.
someone make a windows binary for noobs/lazy people like me ^^
Hello all! This thread is exactly what the title says: a place to post about the node(s) that you are running, including their performance and hardware.
To find out your performance, you'll need to build from source with laszlo's patch. The performance in hashes / second will be listed in the UI where it used to say "Generating..." and will spam your debug.log.
I'm currently running Bitcoin on three machines (and I tested it on a fourth, but that one is for a business, so I can't keep it running).
My Workstation
Specs:
HP HDX 16t - 16" laptop
Intel Core 2 Duo P8700 (x64) @ 2.53GHz w/ 3072KB cache
4GiB DDR2 RAM
nVidia GeForce GT 130M (OpenCL needs to get its act together!)
Ubuntu 10.04 LTS 64-bit (2.6.32-22)
Performance:
**Perf - thread 3 : 446k iter/sec
**Perf - thread 4 : 451k iter/sec
**Perf - total : 897k iter/sec (2 threads)
My Home Server
Specs:
1400MHz Intel Celeron w/ 512KB L2 Cache
512MiB of (ancient) RAM
Debian testing 32-bit (not sure the kernel version)
Performance:
**Perf - total : 169k iter/sec (1 threads)
Puny!
My Xen VPS
Specs:
Not 100% sure about this, but it's using 4 cores.
256MiB of (fast) RAM
Ubuntu 10.04 LTS 64-bit (not sure the kernel version)
Performance:
**Perf - thread 1 : 436k iter/sec
**Perf - thread 2 : 410k iter/sec
**Perf - thread 3 : 419k iter/sec
**Perf - thread 4 : 429k iter/sec
**Perf - total : 1694k iter/sec (4 threads)
So, anybody else?
To find out your performance, you'll need to build from source with laszlo's patch. The performance in hashes / second will be listed in the UI where it used to say "Generating..." and will spam your debug.log.
I'm currently running Bitcoin on three machines (and I tested it on a fourth, but that one is for a business, so I can't keep it running).
My Workstation
Specs:
HP HDX 16t - 16" laptop
Intel Core 2 Duo P8700 (x64) @ 2.53GHz w/ 3072KB cache
4GiB DDR2 RAM
nVidia GeForce GT 130M (OpenCL needs to get its act together!)
Ubuntu 10.04 LTS 64-bit (2.6.32-22)
Performance:
**Perf - thread 3 : 446k iter/sec
**Perf - thread 4 : 451k iter/sec
**Perf - total : 897k iter/sec (2 threads)
My Home Server
Specs:
1400MHz Intel Celeron w/ 512KB L2 Cache
512MiB of (ancient) RAM
Debian testing 32-bit (not sure the kernel version)
Performance:
**Perf - total : 169k iter/sec (1 threads)
Puny!
My Xen VPS
Specs:
Not 100% sure about this, but it's using 4 cores.
256MiB of (fast) RAM
Ubuntu 10.04 LTS 64-bit (not sure the kernel version)
Performance:
**Perf - thread 1 : 436k iter/sec
**Perf - thread 2 : 410k iter/sec
**Perf - thread 3 : 419k iter/sec
**Perf - thread 4 : 429k iter/sec
**Perf - total : 1694k iter/sec (4 threads)
So, anybody else?
Jump to: