An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only)

[Ifaistos]

Started playing around with the recent cpuminer (2.3.2) and litecoin/scrypt on a old spare quad Xeon server i have
I noticed that the performance on the older Xeon@3Ghz is not in par with my quad core2 Q6600@3Ghz
Both machines have 8Gigs of ram, Ubuntu X64 and cpuminer was compiled on each machine

The Q6600 gives me around 6.5 khash/s per core while the Xeon 1.60 khash/s
cpuinfo reports pretty similar bogomips although this is not a true performance measure

i.e Q6600

processor   : 1
vendor_id   : GenuineIntel
cpu family   : 6
model      : 15
model name   : Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
stepping   : 11
cpu MHz      : 3000.000
cache size   : 4096 KB
physical id   : 0
siblings   : 4
core id      : 1
cpu cores   : 4
apicid      : 1
initial apicid   : 1
fpu      : yes
fpu_exception   : yes
cpuid level   : 10
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
bogomips   : 5994.00
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Xeon

processor   : 1
vendor_id   : GenuineIntel
cpu family   : 15
model      : 4
model name   : Intel(R) Xeon(TM) CPU 3.00GHz
stepping   : 3
cpu MHz      : 2992.877
cache size   : 2048 KB
physical id   : 3
siblings   : 2
core id      : 0
cpu cores   : 1
apicid      : 7
initial apicid   : 7
fpu      : yes
fpu_exception   : yes
cpuid level   : 5
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips   : 5985.52
clflush size   : 64
cache_alignment   : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

The only major difference i can think off is that the Q6600 uses DDR2 while the Xeon older server DDR memory, but i really wonder if that alone could account for the huge performance difference,since both have rather large caches.

One other strange thing i noticed is that cpuminer uses roughly 75% of the core's "power" (Top shows 75% nice 25% idle) in both cases
(Was expecting to  see a 100% nice on the core it was running)

My interest is purely from a dev standpoint as with the the GPU's doing most of the work, the few khash difference per cpu core is nothing in a production system.

[pooler]

Started playing around with the recent cpuminer (2.3.2) and litecoin/scrypt on a old spare quad Xeon server i have
I noticed that the performance on the older Xeon@3Ghz is not in par with my quad core2 Q6600@3Ghz
Both machines have 8Gigs of ram, Ubuntu X64 and cpuminer was compiled on each machine

The Q6600 gives me around 6.5 khash/s per core while the Xeon 1.60 khash/s
[...]

You didn't mention the exact model of the Xeon, but judging from the cpuinfo report you provided it looks like it's an old Netburst-based processor, which would partially explain why it is so slow. Does it support hyperthreading by any chance? Have you tried running a single thread to see if the per-thread speed is higher?

While I'm here, here's a non-exhaustive list of things that can significantly influence your hash rate:

• running in 32 or 64 bit mode;
• CPU microarchitecture (Netburst, Core 2, Nehalem, Sandy Bridge, Haswell, ...);
• CPU cache size and speed;
• CPU clock frequency;
• hyperthreading;
• the CPU time used by concurrently running applications.

On the other hand, all other things being equal, the following do (should) not influence the hash rate:

• the amount or speed of RAM;
• the operating system (as long as it provides full support for the capabilities of the CPU it's running on).

[Ifaistos]

I think you are probably right about being a old core/family with 2 hyperthreaded cores (i'll check tomorrow)

While I'm here, here's a non-exhaustive list of things that can significantly influence your hash rate:
running in 32 or 64 bit mode;
CPU microarchitecture (Netburst, Core 2, Nehalem, Sandy Bridge, Haswell, ...);
CPU cache size and speed;
CPU clock frequency;
hyperthreading;
the CPU time used by concurrently running applications.

As the gear-heads would say "There is no replacement for displacement" 

Any idea on why top shows 25% idle (even for 1 thread) ?
Started looking over the code now that i am back home, hopefully if i get some time i could add some powerpc stuff i am more familiar with

[K1773R]

I think you are probably right about being a old core/family with 2 hyperthreaded cores (i'll check tomorrow)

While I'm here, here's a non-exhaustive list of things that can significantly influence your hash rate:
running in 32 or 64 bit mode;
CPU microarchitecture (Netburst, Core 2, Nehalem, Sandy Bridge, Haswell, ...);
CPU cache size and speed;
CPU clock frequency;
hyperthreading;
the CPU time used by concurrently running applications.

As the gear-heads would say "There is no replacement for displacement" 

Any idea on why top shows 25% idle (even for 1 thread) ?
Started looking over the code now that i am back home, hopefully if i get some time i could add some powerpc stuff i am more familiar with

powerpc ASM? if so that would be fun to test on some older machines

[pooler]

Is having a lower scantime better when solo mining?

If you are solo mining you may want to set it to a lower value than the default (5 seconds), provided that the *coin daemon is running locally. That can lower the probability of your solutions getting rejected.
If you are mining at a pool, the option is completely ignored by the miner, as better solutions (long polling or Stratum) will then be available.

[pooler]

When I add the -H option, it shows the output of the hash generate (whether it's rejected/accepted), correct?

There is no -H option... unless you're referring to some other fork of cpuminer?
Anyway, the cpuminer discussed in this thread always displays whether a submitted solution (share or block) is accepted ("yay!!!") or rejected ("booooo").

[K1773R]

When I add the -H option, it shows the output of the hash generate (whether it's rejected/accepted), correct?

There is no -H option... unless you're referring to some other fork of cpuminer?
Anyway, the cpuminer discussed in this thread always displays whether a submitted solution (share or block) is accepted ("yay!!!") or rejected ("booooo").

its the quarkcoin miner fork:

Code:

-H, --hashdebug       enable hash debug output

[auctioneeeeer]

I noticed when scantime was 1 the threads/khash updated fast. When I had it set to 99 it updated MUCH slower, but I got more of the following with -H:

[2013-08-17 20:03:10] DEBUG: hash > target (false positive)
Hash:   000000c097ceb4fc80c0f2b4f5df5e5e5485e27f7ba0e128fe32db6c9c9ef33c
Target: 00000001d5780000000000000000000000000000000000000000000000000000

Any ideas?

Pretty sure those are orphans.  Also, sent you a 5555 qrk for your advice in the other thread.  Thanks again.

[pooler]

I noticed when scantime was 1 the threads/khash updated fast. When I had it set to 99 it updated MUCH slower, but I got more of the following with -H:

[2013-08-17 20:03:10] DEBUG: hash > target (false positive)
Hash:   000000c097ceb4fc80c0f2b4f5df5e5e5485e27f7ba0e128fe32db6c9c9ef33c
Target: 00000001d5780000000000000000000000000000000000000000000000000000

Any ideas?

Assuming you're using the fork mentioned by K1773R, what -H does is enabling some debug output. (So if I got this right it's basically a limited version of the --debug/-D option available with the cpuminer discussed here.)

Thread hash rate is updated when work is refreshed, so obviously with a lower scan time the hash rate will be updated more frequently. (Again, this only applies to solo mining.)
This is irrelevant with respect to mining speed. The only reason why you may want to lower the scan time is to avoid working on stale data, in case the network is producing blocks quickly.

Pretty sure those are orphans.

If the hash is higher than the target it can't be an orphan, all you have is a false positive which should not even be considered as a block candidate. So for instance the false positive mentioned by yourofl10 should not have been submitted upstream by the miner, and should therefore be neither accepted nor rejected.
No idea why the miner you are talking about generates false positives; it could be a wanted behavior (possibly a hack to generate hashes faster) or a bug. In either case, this is not the right thread to discuss this.

[vodz]

My micro optimizations:
http://ftp://ftp.simtreas.ru/pub/my/cpuminer-2.3.2-vodz.tgz
* micro-json, micro-curl
* optimize for speed: hex2bin, bin2hex, stratum_recv_line, (le/be)32(enc/dec)
*                     stratum_handle_method, miner_thread, ssprintf,
*                     sha256_transform_swap
* pasted the code, added micro-configure, removed sha256d*, removed getwork
* added sha256_x86x64.asm by Ufasoft

This special for busybox version (mining from flash/floppy...)

[shawnim]

I am seeing "Stratum connection timed out" messages in the log and not getting credit on coinotron.
I am using pooler-cpuminer 2.3.2 Linux 64 bit binary on Ubuntu 13.04 on an i7 2670QM CPU.
I am minging ftc through the coinotron pool. (Although I see the same problem with ltc).
The log file shows:

Code:

[2013-08-24 00:09:05] Starting Stratum on stratum+tcp://coinotron.com:3337/
[2013-08-24 00:09:05] 6 miner threads started, using 'scrypt' algorithm.
[2013-08-24 00:09:06] Stratum detected new block
[2013-08-24 00:09:30] accepted: 1/1 (100.00%), 27.47 khash/s (yay!!!)
[2013-08-24 00:10:35] Stratum detected new block
[2013-08-24 00:12:35] Stratum connection timed out
[2013-08-24 00:12:35] Stratum connection interrupted
[2013-08-24 00:12:36] Stratum detected new block
[2013-08-24 00:14:36] Stratum connection timed out
[2013-08-24 00:14:36] Stratum connection interrupted

My config file is:

Code:

{
	"url" : "stratum+tcp://coinotron.com:3337/",
	"user" : "shawnim.ftcworker2",
	"pass" : "...XXX...",
	"threads" : "6",
	"quiet" : true
}

When I run with debug=true and protocol-dump=true, I also see:

Code:

[2013-08-24 13:43:17] Starting Stratum on stratum+tcp://coinotron.com:3337/
[2013-08-24 13:43:17] 6 miner threads started, using 'scrypt' algorithm.
* About to connect() to coinotron.com port 3337 (#0)
*   Trying 198.144.121.73...
* TCP_NODELAY set
* Adding handle: conn: 0x7f8cbc021330
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f8cbc021330) send_pipe: 1, recv_pipe: 0
* Connected to coinotron.com (198.144.121.73) port 3337 (#0)
* Connection #0 to host coinotron.com left intact
[2013-08-24 13:43:17] > {"id": 1, "method": "mining.subscribe", "params": ["cpuminer/2.3.2"]}
[2013-08-24 13:43:17] < {"error": null, "id": 1, "result": [["mining.notify", "f3f88c69421345caa15262c0f6935907"], "08039099", 4]}
[2013-08-24 13:43:17] Failed to get Stratum session id
[2013-08-24 13:43:17] > {"id": 2, "method": "mining.authorize", "params": ["shawnim.ftcworker2", "...XXX..."]}
[2013-08-24 13:43:18] < { "id": null, "method": "mining.set_difficulty", "params": [256]}
[2013-08-24 13:43:18] Stratum difficulty set to 256
[2013-08-24 13:43:18] < {"params": ["2506", "a0ca6326f90b50a687e03eabfb7f458c549dc144ae8abcf56db76568292d2787", "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2303311701062f503253482f04d21a195208", "092f7374726174756d2f000000000100c817a8040000001976a9140f0eeb3829239081e670b545bf6c6e6a4c15b1ba88ac00000000", [], "00000001", "1c0151e2", "52191ae1", true], "id": null, "method": "mining.notify"}
[2013-08-24 13:43:18] < {"error": null, "id": 2, "result": true}
[2013-08-24 13:43:18] DEBUG: job_id='2506' extranonce2=00000000 ntime=52191ae1
[2013-08-24 13:43:18] Stratum detected new block
[2013-08-24 13:43:18] < { "id": 9876, "method": "client.get_version", "params": []}
[2013-08-24 13:43:18] > {"id": 9876, "result": "cpuminer/2.3.2", "error": null}
[2013-08-24 13:43:19] thread 1: 4104 hashes, 6.23 khash/s
[2013-08-24 13:43:19] thread 0: 4104 hashes, 5.71 khash/s
[2013-08-24 13:43:19] thread 4: 4104 hashes, 4.37 khash/s
[2013-08-24 13:43:19] thread 2: 4104 hashes, 4.25 khash/s
[2013-08-24 13:43:19] thread 5: 4104 hashes, 4.11 khash/s
[2013-08-24 13:43:19] thread 3: 4104 hashes, 3.63 khash/s
...
[2013-08-24 13:48:23] thread 3: 255660 hashes, 2.25 khash/s
[2013-08-24 13:48:29] Stratum connection timed out
[2013-08-24 13:48:29] Stratum connection interrupted
[2013-08-24 13:48:29] thread 5: 163656 hashes, 2.24 khash/s
[2013-08-24 13:48:29] thread 4: 137388 hashes, 1.78 khash/s
[2013-08-24 13:48:29] thread 2: 62232 hashes, 2.23 khash/s
[2013-08-24 13:48:29] thread 1: 137988 hashes, 2.26 khash/s
[2013-08-24 13:48:29] thread 3: 20340 hashes, 3.24 khash/s
[2013-08-24 13:48:29] thread 0: 103812 hashes, 2.65 khash/s
* About to connect() to coinotron.com port 3337 (#1)
*   Trying 198.144.121.73...
* TCP_NODELAY set
* Adding handle: conn: 0x7f8cbc0201e0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 1 (0x7f8cbc0201e0) send_pipe: 1, recv_pipe: 0
* Connected to coinotron.com (198.144.121.73) port 3337 (#1)
* Connection #1 to host coinotron.com left intact
[2013-08-24 13:48:30] > {"id": 1, "method": "mining.subscribe", "params": ["cpuminer/2.3.2"]}
[2013-08-24 13:48:30] < {"error": null, "id": 1, "result": [["mining.notify", "81d0adb457f242d7b33fc8fb32f1d874"], "08039244", 4]}

I am able to successfully mine btc using the original cpuminer code that I compiled from source with the stratum proxy and slush's pool so I don't think it is a network issue on my part.

Anyone successfully mining scrypt currencies using pooler-cpuminer, stratum, and coinotron?
Any help or pointers greatly appreciated.
Shawn

[pooler]

I am seeing "Stratum connection timed out" messages in the log and not getting credit on coinotron.

This is a known issue with Coinotron (it was first reported here).
The problem is the following: the frequency at which Coinotron sends out notifications is proportional to the speed of each miner, and (since share difficulty is fixed at a relatively high value) slow miners can go 120 seconds without any communication with the server. When that happens, cpuminer thinks that the connection to the pool is dead, and tries to reconnect. This is the same logic used by cgminer/bfgminer, and I believe it makes sense, because it's up to the pool to refresh the work at regular intervals and ensure that new transactions are getting included in block candidates. Letting a miner work on data older than 2 minutes is not acceptable.

[shawnim]

Thanks for the quick reply and the pointer to the original discussion Pooler!
Since it has been 3 months, I guess Coinotron decided not to bother fixing it.
Can you recommend another pool for ltc/ftc mining with pooler-cpuminer?
Thanks!
Shawn

[pooler]

Can you recommend another pool for ltc/ftc mining with pooler-cpuminer?

All other pools I have tried seem to work fine with cpuminer. You can find a list of Litecoin pools here.

[gigica viteazu`]

For the fun of it I compiled cpuminer on Raspberry PI, which is overclocked to 800MHz

Scrypt mining runs at 0.36khs 

 

running on default (not overclocked) raspberry pi (archlinux)

Code:

[2013-08-29 11:30:21] 1 miner threads started, using 'scrypt' algorithm.
[2013-08-29 11:30:59] thread 0: 1662 hashes, 0.29 khash/s

[pooler]

Code:

./autogen.sh
configure.ac:13: installing './compile'
configure.ac:4: installing './config.guess'
configure.ac:4: installing './config.sub'
configure.ac:6: installing './install-sh'
configure.ac:6: installing './missing'
Makefile.am:12: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
Makefile.am: installing './INSTALL'
Makefile.am: installing './depcomp'
configure.ac:114: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Make sure you have installed the development package for libcurl (see first post).

By the way, installing from the tarball is the preferred method, as it's easier and more portable (it doesn't require you to run autotools).

[pooler]

Code:

./autogen.sh
configure.ac:13: installing './compile'
configure.ac:4: installing './config.guess'
configure.ac:4: installing './config.sub'
configure.ac:6: installing './install-sh'
configure.ac:6: installing './missing'
Makefile.am:12: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
Makefile.am: installing './INSTALL'
Makefile.am: installing './depcomp'
configure.ac:114: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Make sure you have installed the development package for libcurl (see first post).

By the way, installing from the tarball is the preferred method, as it's easier and more portable (it doesn't require you to run autotools).

I have libcurl installed. I'm guessing you used some deprecated feature that was removed in the latest version of the autotools.

I don't think there's a problem with your particular version of autotools. I've seen the above error message on some distros that fail to provide libcurl.m4 with the libcurl development package, and installing the file manually solved the issue. As you can see the error message is very cryptic, and that's one of the reasons why end users should prefer building from tarball.

[pooler]

I don't think there's a problem with your particular version of autotools. I've seen the above error message on some distros that fail to provide libcurl.m4 with the libcurl development package, and installing the file manually solved the issue. As you can see the error message is very cryptic, and that's one of the reasons why end users should prefer building from tarball.

I'm using Arch, and I'm not an end user.

You may want to check this yourself, but if I remember correctly Arch is one of those distros.
I'm on Gentoo right now, and have no problem building on it because Gentoo's curl package includes libcurl.m4.

[pooler]

You may want to check this yourself, but if I remember correctly Arch is one of those distros.
I'm on Gentoo right now, and have no problem building on it because Gentoo's curl package includes libcurl.m4.

According to this, it shouldn't be necessary: https://bugs.archlinux.org/task/24610
Thoughts?

Unfortunately different distros have different philosophies on this.
Jeff Garzik, the original author of cpuminer and pushpool, commented on this problem a long time ago, and I think he has a point there.
https://github.com/jgarzik/pushpool/pull/31

[pooler]

But even curl upstream recommends distributing their m4 file with your source.

While it's true that you _could_ rely on the target system to have these files on hand, you're then opening yourself up to differences in versioning that might cause a different breed of trouble for folks building from git. libtool and autohell is self contained in this manner, and we can confidently distribute a known good build system intact with the source. curl upstream even recommends distributing their m4 file with your source code.

That may be true, but I couldn't find an official source confirming this. Even more importantly, I couldn't find a reason why the m4 file shouldn't be distributed with libcurl itself, given that if I'm not mistaken it's maintained as part of libcurl.