New demonstration CPU miner available

[jgarzik]

cpu-miner.c:43: error: ‘SCHED_IDLE’ undeclared (first use in this function)

Your OS needs to update /usr/include/sched.h to include this definition.

If you add
   #include <linux/sched.h>

does it fix the problem for you?

[1714209179]

1714209179

[1714209179]

1714209179

[1714209179]

1714209179

[1714209179]

1714209179

[1714209179]

1714209179

[-ck]

I added some ifdefs to cope with distributions that still have older headers so if you grab my latest git tree (from the master branch) it should build for you.

[jgarzik]

Version 1.0.2 released.

Changes:

Christian Ludwig (2):
      Fix libcurl include path
      configure.ac: Beautify yasm test output

Jeff Garzik (3):
      only read processor count via sysconf on non-Windows platforms
      Fix number-of-threads init logic on Windows
      Version 1.0.2.

ckolivas (2):
      Linux + x86_64 optimisations.
      Cope with older linux kernel headers that don't have the newer scheduling

[hugolp]

I added some ifdefs to cope with distributions that still have older headers so if you grab my latest git tree (from the master branch) it should build for you.

Thanks. Git branch is working now. A small contribution is going your way.

[c_k]

Success!

I can now compile the latest code, thank you so much for your swift fix there team

Is the 4way algorithm still the best?

[hugolp]

Success!

I can now compile the latest code, thank you so much for your swift fix there team

Is the 4way algorithm still the best?

Im trying it with an Atom 330 that is reported to have SS2, but I get better results with c and cryptopp (almost identical results with both).

[-ck]

I added some ifdefs to cope with distributions that still have older headers so if you grab my latest git tree (from the master branch) it should build for you.

Thanks. Git branch is working now. A small contribution is going your way.

Sweet, I appreciate the gesture and it makes me want to work on the code more, thanks!

[rocksalt]

hi all... im experimenting with using this on a few different types on machines and i havn't found anything for the following question:

is there a way to throttle the minderd.exe process to say take only 35% of cpu when busy? and maybe 90% when idle ?
is there a switch?? i can open numbers of threads, but i can't actually find a away of controlling those threads.

The reason is i'd like to deploy this on a lot of workstations im looking after, roughly about 5k of them, but i need to keep control over what and how they are utilising the cpu usage.

[-ck]

hi all... im experimenting with using this on a few different types on machines and i havn't found anything for the following question:

is there a way to throttle the minderd.exe process to say take only 35% of cpu when busy? and maybe 90% when idle ?
is there a switch?? i can open numbers of threads, but i can't actually find a away of controlling those threads.

The reason is i'd like to deploy this on a lot of workstations im looking after, roughly about 5k of them, but i need to keep control over what and how they are utilising the cpu usage.

No there is not... yet(?) The threads run at ultra-low priority and should not have any impact on the machine at all except in terms of power usage and heat generation. Of course they may be issues in their own right. Is there really a demand for this?

[dserrano5]

[...] power usage and heat generation. Of course they may be issues in their own right. Is there really a demand for this?

I for one would like to have it. I would have been a long time user of BOINC if it weren't for this.

[-ck]

[...] power usage and heat generation. Of course they may be issues in their own right. Is there really a demand for this?

I for one would like to have it. I would have been a long time user of BOINC if it weren't for this.

Yeah but you do realise that at the current level of difficulty (which will increase soon), it would take a modern cpu over 50 years to solve one block successfully? Slow it down even more and it's... never. Of course you could use them to add MH/s but even then 1GHz of modern CPU adds about 1MH/s, so a throttled 3Ghz machine would only give you just 1 MH/s per core. Which really is... nothing by today's standards and will be even less as time goes on.

Now if that doesn't deter you, then sure there are ways I can implement this crudely on linux. I haven't got a clue how to do it for other OSs, nor do I care to figure it out.

[rocksalt]

[...] power usage and heat generation. Of course they may be issues in their own right. Is there really a demand for this?

I for one would like to have it. I would have been a long time user of BOINC if it weren't for this.

Yeah but you do realise that at the current level of difficulty (which will increase soon), it would take a modern cpu over 50 years to solve one block successfully? Slow it down even more and it's... never. Of course you could use them to add MH/s but even then 1GHz of modern CPU adds about 1MH/s, so a throttled 3Ghz machine would only give you just 1 MH/s per core. Which really is... nothing by today's standards and will be even less as time goes on.

Now if that doesn't deter you, then sure there are ways I can implement this crudely on linux. I haven't got a clue how to do it for other OSs, nor do I care to figure it out.

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.

[ancow]

Now if that doesn't deter you, then sure there are ways I can implement this crudely on linux. I haven't got a clue how to do it for other OSs, nor do I care to figure it out.

Personally, I don't think building throttling into the program is the best way to do this, especially on Linux. You can use frequency scaling and CPU throttling. 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.

Also, at least with some distros, there's a tool called "cpulimit" that will periodically put your process to sleep and then wake it again that could achieve the desired effect.

[-ck]

I agree with ancow. The tools to do this exist already. Since cpuminer will run idle and niced priority, setting an ondemand cpu frequency governor with ignore nice load will do precisely what you want.

[hugolp]

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.

[dserrano5]

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!

[dserrano5]

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.

[ancow]

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

[dserrano5]

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 .

[-ck]

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).