New demonstration CPU miner available - page 4.

jgarzik

legendary

Activity: 1596

Merit: 1091

A user randomly emailed the following sha256 core update:
http://yyz.us/bitcoin/sha256_xmm_amd64_atom.asm

Quote from: Neil_Kettle

Jeff - attached is a somewhat faster sse2_64 core, well, at least for the cpu's I've tested!

An example on an Intel Atom D525 (dual core),

[2011-06-14 14:18:42] 2 miner threads started, using SHA256 'sse2_64'algorithm.
[2011-06-14 14:18:56] thread 0: 16777216 hashes, 1047.98 khash/sec

[2011-06-14 14:18:19] 2 miner threads started, using SHA256 'sse2_64_atom' algorithm.
[2011-06-14 14:18:31] thread 0: 16777216 hashes, 1234.20 khash/sec

It should be faster on all Intel cpu's by quite some margin, up to 20% in my tests.

Anybody want to test this, and prove his assertions?

d3m0n1q_733rz

sr. member

Activity: 378

Merit: 250

Hey guys, it's a major work in progress, but I seem to be getting a segmentation fault I was wondering if someone could point out to me. I'm trying to optimize some of the xmm moves through the edi/esi cache, but I'm a noob at this so it's more for fun and learning at the moment than anything else. The code requires SSE4.1 to run correctly. I have SSE4.1 in case someone asks, so that's not the problem.
I've tried using LFENCE since it's going to be multi-threaded, but I've probably made a noob mistake there too. Anyhow, here's my non-working code for the moment. I've made changes to LAB_CALC, loading the init values into the hash, and stopped part-way through LAB_LOOP. It's still very much a work in progress, but I expect to see at least some speed-up once I get it working.

Code:

;; SHA-256 for X86-64 for Linux, based off of:

; (c) Ufasoft 2011 http://ufasoft.com mailto:[email protected]
; Version 2011
; This software is Public Domain

; SHA-256 CPU SSE cruncher for Bitcoin Miner

ALIGN 32
BITS 64

%define hash rdi
%define data rsi
%define init rdx

extern g_4sha256_k

global CalcSha256_x64
; CalcSha256 hash(rdi), data(rsi), init(rdx)
CalcSha256_x64:

push rbx

LAB_NEXT_NONCE:
mov r11, data
; mov rax, pnonce
; mov eax, [rax]
; mov [rbx+3*16], eax
; inc eax
; mov [rbx+3*16+4], eax
; inc eax
; mov [rbx+3*16+8], eax
; inc eax
; mov [rbx+3*16+12], eax

mov rcx, 64*4 ;rcx is # of SHA-2 rounds
mov rax, 16*4 ;rax is where we expand to

LAB_SHA:
push rcx
lea rcx, qword [r11+rcx*4]
lea r11, qword [r11+rax*4]
LAB_CALC:
LFENCE
movdqa xmm0, [r11-15*16]
movdqa [edi], xmm0
; (Rotr32(w_15, 7) ^ Rotr32(w_15, 18) ^ (w_15 >> 3))
psrld xmm0, 3
movdqa [edi+32], xmm0
movntdqa xmm2, [esi]
movntdqa xmm1, [esi+32]
pslld xmm2, 14
psrld xmm1, 4
pxor xmm0, xmm1
pxor xmm0, xmm2
pslld xmm2, 11
psrld xmm1, 11
pxor xmm0, xmm1
pxor xmm0, xmm2

paddd xmm0, [r11-16*16]

movdqa xmm3, [r11-2*16]
movdqa xmm2, xmm3 ; (Rotr32(w_2, 17) ^ Rotr32(w_2, 19) ^ (w_2 >> 10))
psrld xmm3, 10
movdqa xmm1, xmm3
pslld xmm2, 13
psrld xmm1, 7
pxor xmm3, xmm1
pxor xmm3, xmm2
pslld xmm2, 2
psrld xmm1, 2
pxor xmm3, xmm1
pxor xmm3, xmm2
paddd xmm0, xmm3

paddd xmm0, [r11-7*16]
movdqa [r11], xmm0
add r11, 16
cmp r11, rcx
jb LAB_CALC
pop rcx

mov rax, 0

; Load the init values of the message into the hash.

movd xmm0, dword [rdx+4*4] ; xmm0 == e
pshufd xmm0, xmm0, 0
movdqa [edi], xmm0
movd xmm3, dword [rdx+3*4] ; xmm3 == d
pshufd xmm3, xmm3, 0
movdqa [edi+32], xmm3
movd xmm4, dword [rdx+2*4] ; xmm4 == c
pshufd xmm4, xmm4, 0
movdqa [edi+64], xmm4
movd xmm5, dword [rdx+1*4] ; xmm5 == b
pshufd xmm5, xmm5, 0
movdqa [edi+96], xmm5
movd xmm7, dword [rdx+0*4] ; xmm7 == a
pshufd xmm7, xmm7, 0
movdqa [edi+112], xmm7
movd xmm8, dword [rdx+5*4] ; xmm8 == f
pshufd xmm8, xmm8, 0
movdqa [edi+160], xmm8
movd xmm9, dword [rdx+6*4] ; xmm9 == g
pshufd xmm9, xmm9, 0
movdqa [edi+192], xmm9
movd xmm10, dword [rdx+7*4] ; xmm10 == h
pshufd xmm10, xmm10, 0
movdqa [edi+224], xmm10

LAB_LOOP:

;; T t1 = h + (Rotr32(e, 6) ^ Rotr32(e, 11) ^ Rotr32(e, 25)) + ((e & f) ^ AndNot(e, g)) + Expand32(g_sha256_k[j]) + w[j]

movdqa xmm6, [rsi+rax*4]
paddd xmm6, g_4sha256_k[rax*4]
add rax, 4

paddd xmm6, xmm10 ; +h

movntdqa xmm1, [esi]
movntdqa xmm2, [esi+192]
pandn xmm1, xmm2 ; ~e & g

movdqa [edi+96], xmm2 ; makes xmm2 the cache location in place of xmm9
movntdqa xmm10, [esi+192] ; h = g
movntdqa xmm2, [esi+160] ; f
movntdqa xmm9, [esi+160] ; g = f

pand xmm2, xmm0 ; e & f
pxor xmm1, xmm2 ; (e & f) ^ (~e & g)
movdqa xmm8, xmm0 ; f = e

paddd xmm6, xmm1 ; Ch + h + w[i] + k[i]

movdqa xmm1, xmm0
psrld xmm0, 6
movdqa xmm2, xmm0
pslld xmm1, 7
psrld xmm2, 5
pxor xmm0, xmm1
pxor xmm0, xmm2
pslld xmm1, 14
psrld xmm2, 14
pxor xmm0, xmm1
pxor xmm0, xmm2
pslld xmm1, 5
pxor xmm0, xmm1 ; Rotr32(e, 6) ^ Rotr32(e, 11) ^ Rotr32(e, 25)
paddd xmm6, xmm0 ; xmm6 = t1

movdqa xmm0, xmm3 ; d
paddd xmm0, xmm6 ; e = d+t1

movdqa xmm1, xmm5 ; =b
movdqa xmm3, xmm4 ; d = c
movdqa xmm2, xmm4 ; c
pand xmm2, xmm5 ; b & c
pand xmm4, xmm7 ; a & c
pand xmm1, xmm7 ; a & b
pxor xmm1, xmm4
movdqa xmm4, xmm5 ; c = b
movdqa xmm5, xmm7 ; b = a
pxor xmm1, xmm2 ; (a & c) ^ (a & d) ^ (c & d)
paddd xmm6, xmm1 ; t1 + ((a & c) ^ (a & d) ^ (c & d))

movdqa xmm2, xmm7
psrld xmm7, 2
movdqa xmm1, xmm7
pslld xmm2, 10
psrld xmm1, 11
pxor xmm7, xmm2
pxor xmm7, xmm1
pslld xmm2, 9
psrld xmm1, 9
pxor xmm7, xmm2
pxor xmm7, xmm1
pslld xmm2, 11
pxor xmm7, xmm2
paddd xmm7, xmm6 ; a = t1 + (Rotr32(a, 2) ^ Rotr32(a, 13) ^ Rotr32(a, 22)) + ((a & c) ^ (a & d) ^ (c & d));

cmp rax, rcx
jb LAB_LOOP

; Finished the 64 rounds, calculate hash and save

movd xmm1, dword [rdx+0*4]
pshufd xmm1, xmm1, 0
paddd xmm7, xmm1

movd xmm1, dword [rdx+1*4]
pshufd xmm1, xmm1, 0
paddd xmm5, xmm1

movd xmm1, dword [rdx+2*4]
pshufd xmm1, xmm1, 0
paddd xmm4, xmm1

movd xmm1, dword [rdx+3*4]
pshufd xmm1, xmm1, 0
paddd xmm3, xmm1

movd xmm1, dword [rdx+4*4]
pshufd xmm1, xmm1, 0
paddd xmm0, xmm1

movd xmm1, dword [rdx+5*4]
pshufd xmm1, xmm1, 0
paddd xmm8, xmm1

movd xmm1, dword [rdx+6*4]
pshufd xmm1, xmm1, 0
paddd xmm9, xmm1

movd xmm1, dword [rdx+7*4]
pshufd xmm1, xmm1, 0
paddd xmm10, xmm1

debug_me:
movdqa [rdi+0*16], xmm7
movdqa [rdi+1*16], xmm5
movdqa [rdi+2*16], xmm4
movdqa [rdi+3*16], xmm3
movdqa [rdi+4*16], xmm0
movdqa [rdi+5*16], xmm8
movdqa [rdi+6*16], xmm9
movdqa [rdi+7*16], xmm10

LAB_RET:
pop rbx
ret

Mind you, it does compile so it's not THAT bad anymore. I figured out that Linux code is much simpler than Windows.

d3m0n1q_733rz

sr. member

Activity: 378

Merit: 250

Well, I think I've realized some of them are going to be 32 bit values instead of 16, but even with the code modified to allow for it, I'm running into problems. I want to toss as many of the operations into the cache efficiently as I can. I also realized that I'll need to initialize two 128 bit caches to make room for all 10 xmm values. I tell you, I'm realizing that 64-bit programming is a brand new ballgame for me. But I said I would try tossing the code into the buffer and that's what I'm going to do even
;if it kills me fi.
if it takes all night fi. Tongue

hehe batch

When you start mixing batch and assembly, you know you need sleep.

d3m0n1q_733rz

sr. member

Activity: 378

Merit: 250

Hey, I was looking through the Ufasoft SSE2_64 code to see if I could make any SSE updates and I'm having difficulty understanding some of it since it's not commented. I was wondering if you might be able to help me out. I don't really know the rules for SSE4.1's movntdqa command and seem to have made a boo-boo. Here's the code I've modified so far and tested compilation for which didn't work. Could you point out my error?

Code:

LAB_CALC:
movntdqa xmmword ptr [edi], [r11-15*16]
movdqa xmm0, xmmword ptr [edi]
movdqa xmm2, xmmword ptr [edi] ; (Rotr32(w_15, 7) ^ Rotr32(w_15, 18) ^ (w_15 >> 3))
psrld xmm0, 3
movdqa xmm1, xmm0
pslld xmm2, 14
psrld xmm1, 4
pxor xmm0, xmm1
pxor xmm0, xmm2
pslld xmm2, 11
psrld xmm1, 11
pxor xmm0, xmm1
pxor xmm0, xmm2

I think it's because I'm trying to move the value of [r11-15*16] into the cache which is a round-about way of performing an operation on the data which may not be permitted. Thanks!

I wanted to add that I'm pretty new to coding as well, and the Intel data sheet is clear as mud on specifics and anything that isn't literal. So I'm sorry if my code has something literal in it that shouldn't be.

ancow

full member

Activity: 373

Merit: 100

Quote from: d3m0n1q_733rz on June 17, 2011, 12:36:39 AM

So then, what exactly does scantime do? It says that my CPU cores are performing around the same computations per sec. From what I can tell, it only changes how often it tells me how many computations it has computed. Am I missing something here? And, if so, what is generally a good value to set this for? I have it set for about 15 sec and it seems to be working well.

It determines the amount of time spent on whatever work the server sent you and is only relevant when you're not using long polling. The point behind scantime is that if you find a share for a block that has been solved, the share is wasted. So for a server that doesn't support long polling (i.e. telling you when a block is solved), you're getting an arbitrarily large amount of work. And the longer it takes for you to solve the block, the higher the chances for finding a stale share.

The problem with such low values is pretty much that you're increasing the network load for yourself and the server and the server's overall load because it has to calculate another workload for you. Basically, with a scantime of 2s you're doing a (really small) DOS attack on the server.
Also, you're spending some of your CPU resources on getting the work, etc., so you're wasting valuable hashing power on overhead.

dserrano5

legendary

Activity: 1974

Merit: 1029

Yes. That's called "long polling". In cpuminer's output, the lines "LONGPOLL detected new block" tell that a block has been solved.

cynikal

newbie

Activity: 14

Merit: 0

pardon the n00b question but, does cpuminer have any facility to detect when the current block's been solved (so that it can drop what it's doing and begin new getwork() or is that what the scan time discussion is addressing?

i'm wondering if cpuminer is (or can be made) intelligent enough to not continue to working on the old block, submitting stale shares somehow.. (i'm thinking of setting up pushpoold if that'd help).

d3m0n1q_733rz

sr. member

Activity: 378

Merit: 250

So then, what exactly does scantime do? It says that my CPU cores are performing around the same computations per sec. From what I can tell, it only changes how often it tells me how many computations it has computed. Am I missing something here? And, if so, what is generally a good value to set this for? I have it set for about 15 sec and it seems to be working well.

jgarzik

legendary

Activity: 1596

Merit: 1091

Setting scantime far too low will probably cost you money. At some point overhead becomes more significant than hashing, as cpuminer is not fully pipelined.

rocksalt

newbie

Activity: 51

Merit: 0

Quote from: ancow on June 15, 2011, 07:20:15 AM

Quote from: rocksalt on June 15, 2011, 04:36:15 AM

Shameless bump here... I've still been unable to get cpuminer to work on btcguild, no matter what settings i choose, the silly thing still throws the errors.... is anyone using cpu miner on btcguild ?

Quote from: rocksalt on June 11, 2011, 02:24:28 AM

Im now discovering a different issue Tongue

minerd.exe --algo cryptopp_asm32 --s 2 --url http://btcguild.com/ --userpass xxxx:xxx this runs when i tried it on deepbit, local miner and a few others....

however on btcguild i get the following error

[2011-06-12 10:02:16] 1 miner threads started, using SHA256 'cryptopp_asm32' algorithm.
[2011-06-12 10:02:20] JSON decode failed(1): '[' or '{' expected near '<'
[2011-06-12 10:02:20] json_rpc_call failed, retry after 30 seconds

its only happening with btcguild though, not any of the other mining pools i tested with.

anyone come accross this before ??

Win7
Intel Dual Core
Nvidia GTX470OC

Quote from: djinfected on June 03, 2011, 12:01:51 AM

Code:

F:\CPU-miner>cd "F:\CPU-miner"

F:\CPU-miner>minerd.exe --user djinfected --pass dji12406btio --url http://minin
g.bitcoin.cz/ --algo 4way
[2011-06-03 00:00:51] 1 miner threads started, using SHA256 '4way' algorithm.
[2011-06-03 00:00:53] JSON decode failed(1): '[' or '{' expected near '<'
[2011-06-03 00:00:53] json_rpc_call failed, retry after 30 seconds

I don't understand what this means. I get this with the default algo too.

Quote from: ancow on June 03, 2011, 12:13:04 AM

It looks to me like you're getting an HTML response instead of a JSON one. Something to ask your pool admin about (or double-check the URL you're passing, especially if the pool doesn't use the standard port).

Apart from the obvious "this has already been answered here", are you sure you know what you're doing? Setting the scantime to two seconds doesn't seem very prudent to me... (although that setting is probably ignored, assuming your pool supports long polling)

And finally, such questions are better asked in the pool threads.

yeah i know 2 seconds is quite aggressive, I've tested it all the way up to 10 seconds in 2 sec intervals.. hasn't made any impact when I've used to against other pools

i've tried btcguild.com:8332 and ipaddress:8332... still the html response thing.. ill follow that up and see... interestingly, im also getting something similar with bitcoin-miner, so im now assuming its a pool issue and not a minder issue. Thanks for the help though

ancow

full member

Activity: 373

Merit: 100

Quote from: rocksalt on June 15, 2011, 04:36:15 AM

Shameless bump here... I've still been unable to get cpuminer to work on btcguild, no matter what settings i choose, the silly thing still throws the errors.... is anyone using cpu miner on btcguild ?

Quote from: rocksalt on June 11, 2011, 02:24:28 AM

Im now discovering a different issue Tongue

minerd.exe --algo cryptopp_asm32 --s 2 --url http://btcguild.com/ --userpass xxxx:xxx this runs when i tried it on deepbit, local miner and a few others....

however on btcguild i get the following error

[2011-06-12 10:02:16] 1 miner threads started, using SHA256 'cryptopp_asm32' algorithm.
[2011-06-12 10:02:20] JSON decode failed(1): '[' or '{' expected near '<'
[2011-06-12 10:02:20] json_rpc_call failed, retry after 30 seconds

its only happening with btcguild though, not any of the other mining pools i tested with.

anyone come accross this before ??

Win7
Intel Dual Core
Nvidia GTX470OC

Quote from: djinfected on June 03, 2011, 12:01:51 AM

Code:

F:\CPU-miner>cd "F:\CPU-miner"

F:\CPU-miner>minerd.exe --user djinfected --pass dji12406btio --url http://minin
g.bitcoin.cz/ --algo 4way
[2011-06-03 00:00:51] 1 miner threads started, using SHA256 '4way' algorithm.
[2011-06-03 00:00:53] JSON decode failed(1): '[' or '{' expected near '<'
[2011-06-03 00:00:53] json_rpc_call failed, retry after 30 seconds

I don't understand what this means. I get this with the default algo too.

Quote from: ancow on June 03, 2011, 12:13:04 AM

It looks to me like you're getting an HTML response instead of a JSON one. Something to ask your pool admin about (or double-check the URL you're passing, especially if the pool doesn't use the standard port).

Apart from the obvious "this has already been answered here", are you sure you know what you're doing? Setting the scantime to two seconds doesn't seem very prudent to me... (although that setting is probably ignored, assuming your pool supports long polling)

And finally, such questions are better asked in the pool threads.

rocksalt

newbie

Activity: 51

Merit: 0

Shameless bump here... I've still been unable to get cpuminer to work on btcguild, no matter what settings i choose, the silly thing still throws the errors.... is anyone using cpu miner on btcguild ?

Quote from: rocksalt on June 11, 2011, 02:24:28 AM

Im now discovering a different issue Tongue

minerd.exe --algo cryptopp_asm32 --s 2 --url http://btcguild.com/ --userpass xxxx:xxx this runs when i tried it on deepbit, local miner and a few others....

however on btcguild i get the following error

[2011-06-12 10:02:16] 1 miner threads started, using SHA256 'cryptopp_asm32' algorithm.
[2011-06-12 10:02:20] JSON decode failed(1): '[' or '{' expected near '<'
[2011-06-12 10:02:20] json_rpc_call failed, retry after 30 seconds

its only happening with btcguild though, not any of the other mining pools i tested with.

anyone come accross this before ??

Win7
Intel Dual Core
Nvidia GTX470OC

dserrano5

legendary

Activity: 1974

Merit: 1029

Quote from: -ck on June 14, 2011, 06:40:37 PM

However you do realise that when it says processor 7, it means processors 0-7 which means you have 8?

Yes. I don't own that machine and I feel better leaving at least one processor free of load, even if minerd is niced. Thanks for your input

.

Quote from: -ck on June 14, 2011, 06:57:44 PM

/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load

Great!!

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dserrano5 on June 14, 2011, 08:23:49 AM

Quote from: ancow on June 14, 2011, 07:31:00 AM

Also, you can set your frequency governor to ignore niced processes (at least for ondemand and conservative), keeping the CPU speed down when nothing else needs the higher frequency. Works quite well for me.

Ah, didn't know this. Will look into it, thank you!

The toggle you wish to modify is this:
/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load

Setting it to 1 will prevent CPUs from ramping up in speed when the workload is running at low priority.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dserrano5 on June 14, 2011, 03:53:59 PM

I just downloaded and built cpuminer-1.0.2. I expected to see some improvements thanks to ckolivas' affinity changes (assuming they have made it into the release), but I'm surprised to find I'm getting the same speed:

Code:

processor : 7
physical id : 1
core id : 3

"siblings" and "cpu cores" both have the value 4 in all entries.

Indeed the changes are unlikely to make any sort of drastic throughput improvement. The advantage of the new build is it automatically detects the number of processors and set the threads accordingly, chooses the best algorithm by default and then binds the threads to each CPU. CPU affinity does not have drastic effects on throughput unless you have a complicated cache arrangement in your hardware (such as NUMA or multiple physical CPUs) and the workload has a large cache footprint. sha256 calculations (which is all that mining is) do not have a large cache footprint. However you do realise that when it says processor 7, it means processors 0-7 which means you have 8? I didn't realise that jgarzik didn't incorporate the new total throughput counter which is in my git tree. It will allow you to really get a hold of what your throughput is rather than trying to examine each thread at a time.

Oh and the CPU affinity is disabled when the number of threads is not a multiple of the number of CPUs (8, 16, 24 etc. in your case).

dserrano5

legendary

Activity: 1974

Merit: 1029

I suspected it, and saw it confirmed when I didn't specify number of threads and read the lines in the log file. Nothing new here but thanks for pointing it out anyway Wink

.

ancow

full member

Activity: 373

Merit: 100

Just to make sure you understand this, specifying the amount of threads will disable the CPU affinity stuff (as I understand the code).

dserrano5

legendary

Activity: 1974

Merit: 1029

I just downloaded and built cpuminer-1.0.2. I expected to see some improvements thanks to ckolivas' affinity changes (assuming they have made it into the release), but I'm surprised to find I'm getting the same speed:

Code:

$ grep CFLAGS_value */config.log
cpuminer-1.0.1/config.log:ac_cv_env_CFLAGS_value='-O3 -Wall -msse2'
cpuminer-1.0.2/config.log:ac_cv_env_CFLAGS_value='-O3 -Wall -msse2'
$ tail */my-log
==> cpuminer-1.0.1/my-log <==
[2011-06-14 18:57:05] thread 5: 161767000 hashes, 2694.78 khash/sec
[2011-06-14 18:58:00] thread 1: 160434868 hashes, 2684.82 khash/sec
[2011-06-14 18:58:00] thread 4: 162531240 hashes, 2694.68 khash/sec
[2011-06-14 18:58:05] thread 2: 160738332 hashes, 2678.31 khash/sec
[2011-06-14 18:58:05] thread 3: 162845920 hashes, 2687.02 khash/sec
[2011-06-14 18:58:06] thread 6: 161633936 hashes, 2691.05 khash/sec
[2011-06-14 18:58:06] thread 0: 162323744 hashes, 2687.43 khash/sec
[2011-06-14 18:58:06] thread 5: 161767000 hashes, 2694.55 khash/sec
[2011-06-14 18:59:00] thread 1: 160434868 hashes, 2693.92 khash/sec
[2011-06-14 18:59:01] thread 4: 162531240 hashes, 2684.48 khash/sec

==> cpuminer-1.0.2/my-log <==
[2011-06-14 21:30:10] thread 0: 40046392 hashes, 2687.31 khash/sec
[2011-06-14 21:30:10] thread 2: 32207448 hashes, 2687.27 khash/sec
[2011-06-14 21:30:10] thread 1: 49517220 hashes, 2687.39 khash/sec
[2011-06-14 21:31:12] thread 4: 158828460 hashes, 2687.11 khash/sec
[2011-06-14 21:31:12] thread 6: 161129456 hashes, 2679.90 khash/sec
[2011-06-14 21:31:13] thread 3: 164484744 hashes, 2686.09 khash/sec
[2011-06-14 21:31:13] thread 0: 160185568 hashes, 2685.15 khash/sec
[2011-06-14 21:31:14] thread 2: 161037240 hashes, 2685.64 khash/sec
[2011-06-14 21:31:14] thread 5: 164770840 hashes, 2687.16 khash/sec
[2011-06-14 21:31:16] thread 1: 165057400 hashes, 2684.58 khash/sec
$ grep -vE 'url|user|pass' cpuminer-1.0.2/cfg.json
{
   "algo" : "sse2_64",
   "threads" : "7",
   "retry-pause" : "25"
}
$ diff -u cpuminer-1.0.*/cfg.json
$ _

I tried removing the line that specifies 7 threads but that makes no difference (except for the log messages "Binding thread %d to cpu %d"). Am I omitting some step? The CPU is a "Intel(R) Xeon(R) CPU E5420 @2.50GHz". This is the layout of the CPUs/cores:

Code:

$ grep -E '^processor|^physical|^core.id|^$' /proc/cpuinfo
processor : 0
physical id : 0
core id : 0

processor : 1
physical id : 1
core id : 0

processor : 2
physical id : 0
core id : 2

processor : 3
physical id : 1
core id : 2

processor : 4
physical id : 0
core id : 1

processor : 5
physical id : 1
core id : 1

processor : 6
physical id : 0
core id : 3

processor : 7
physical id : 1
core id : 3

"siblings" and "cpu cores" both have the value 4 in all entries.

dserrano5

legendary

Activity: 1974

Merit: 1029

Quote from: ancow on June 14, 2011, 07:31:00 AM

Also, you can set your frequency governor to ignore niced processes (at least for ondemand and conservative), keeping the CPU speed down when nothing else needs the higher frequency. Works quite well for me.

Ah, didn't know this. Will look into it, thank you!

hugolp

legendary

Activity: 1148

Merit: 1001

Radix-The Decentralized Finance Protocol

Quote from: rocksalt on June 14, 2011, 07:27:31 AM

I was more thinking that even at a low hash rate, 5k of PC's all connecting to one or two pools, would equate out to maybe about 300GH/s... kind of like distributed processing. Not only does this happen, but at a low cpu usage, it can run all the time in the background and the users won't be affected.

But your electric bill will.

Unless of course you are doing it at work or something like that.

Topic: New demonstration CPU miner available - page 4. (Read 386150 times)