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

cbuchner1

hero member

Activity: 756

Merit: 502

i think I know what's causing the program to hang after the "unable to parse newline terminated string" message. It's stratum_send_line holding the socket mutex while in an infinite loop trying to send data over an unresponsive/malfunctioning socket, while at the same time the stratum_disconnect() function tries to re-establish the socket after some kind of problem with the exisiting socket (timeout or not receiving any data).

It might make sense to try to fix this upstream in the cpuminer code, don't you think?

Pt0x

sr. member

Activity: 266

Merit: 250

Quote from: simpic on September 08, 2013, 02:17:18 PM

I discover this program today!
Finally i can use my old pc to mine alt coin!

Thank you.

You should mine Primecoins. Right now it´s the only altcoin that runs mostly on CPU. (There is a GPU miner but it needs to be optimized).

simpic

hero member

Activity: 1253

Merit: 811

I discover this program today!
Finally i can use my old pc to mine alt coin!

Thank you.

cassieheart

sr. member

Activity: 354

Merit: 250

Is there a x86 and x64 version already compiled where i can just enter my info save click and run ? I am lost when it comes to this stuff Wink

pooler

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

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

Quote from: falconindy

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.

pooler

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

Quote from: pooler on September 02, 2013, 05:37:05 AM

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

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

Quote from: pooler on September 02, 2013, 04:55:51 AM

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

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

Quote from: pooler on September 02, 2013, 04:41:38 AM

Quote from: ?? on ??

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

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

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

gigica viteazu`

sr. member

Activity: 458

Merit: 250

beast at work

Quote from: Nemo1024 on August 10, 2013, 02:05:25 PM

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

Scrypt mining runs at 0.36khs Grin

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

hero member

Activity: 842

Merit: 507

Quote from: shawnim on August 24, 2013, 08:22:37 PM

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.

shawnim

newbie

Activity: 4

Merit: 0

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

hero member

Activity: 842

Merit: 507

Quote from: shawnim on August 24, 2013, 06:19:34 PM

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

newbie

Activity: 4

Merit: 0

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

vodz

sr. member

Activity: 254

Merit: 250

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

pooler

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

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.

Quote from: auctioneeeeer on August 17, 2013, 03:14:01 PM

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.

auctioneeeeer

sr. member

Activity: 305

Merit: 250

Quote from: ?? on ??

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.

K1773R

legendary

Activity: 1792

Merit: 1008

/dev/null

Quote from: pooler on August 17, 2013, 02:26:49 PM

Quote from: ?? on ??

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

pooler

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

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

pooler

hero member

Activity: 842

Merit: 507

Quote from: ?? on ??

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.

Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only) - page 37. (Read 1958546 times)