New demonstration CPU miner available

[BitLex]

i need a portable file to run on certain computers

just "install" it once and copy the folder to your thumbdrive, works fine for me (note that i only used 0.2.1, newer versions slow 4way down on my phenomX3).

[Azetab]

i need a portable file to run on certain computers

just "install" it once and copy the folder to your thumbdrive, works fine for me (note that i only used 0.2.1, newer versions slow 4way down on my phenomX3).

oh didnt know i could do that thanks!

[Azetab]

when I run this I get a json_rpc_call failed, does anyone know why?

[slush]

Hi jgarzik, as I promised somewhere on this forum, I'm sending you my first reward from cooperative mining, because your code helped me a lot to understand, how mining works inside. So 38 BTC is yours, enjoy :-).

[jgarzik]

when I run this I get a json_rpc_call failed, does anyone know why?

The miner is unable to connect to the URL you gave it, for some reason.

Hi jgarzik, as I promised somewhere on this forum, I'm sending you my first reward from cooperative mining, because your code helped me a lot to understand, how mining works inside. So 38 BTC is yours, enjoy :-).

Thanks!

[jgarzik]

Updated first post with a release tarball for Linux/BSD, so that people don't have to bother with autotools and the git repo.

Recommend avoiding gcc 4.5.x at the moment.

[Raulo]

I like the miner for its simplicity (and is also a bit faster than standard bitcoin program).

While using this miner in the pooled mining I came across a few problems and I'd like to offer suggestions.

First one is in the code that reads the work

Code:

             val = json_rpc_call(rpc_url, userpass, rpc_req);
             if (!val) {
             fprintf(stderr, "json_rpc_call failed\n");
             return NULL;
            }

If there is a network or server problem, the client will fail and it happens quite frequently with pooled mining. I changed return NULL; to some sleep and
put it in a loop to wait until the network is up again. After such modification (and similar in submit_work) the client survived several server restarts.

Another suggestion is in the 4way code. The code will not compile with Intel Compiler due to non-standard use of bit operations. If you change the lines that define macros to:

Code:

static inline __m128i Ch(const __m128i b, const __m128i c, const __m128i d) {
    return _mm_xor_si128(_mm_and_si128(b,c),_mm_andnot_si128(b,d));
}

static inline __m128i Maj(const __m128i b, const __m128i c, const __m128i d) {
    return _mm_xor_si128(_mm_xor_si128(_mm_and_si128(b,c),_mm_and_si128(b,d)),_mm_and_si128(c,d));
}

static inline __m128i ROTR(__m128i x, const int n) {
    return _mm_or_si128(_mm_srli_epi32(x, n),_mm_slli_epi32(x, 32 - n));
}

static inline __m128i SHR(__m128i x, const int n) {
    return _mm_srli_epi32(x, n);
}

/* SHA256 Functions */
#define BIGSIGMA0_256(x)    (_mm_xor_si128(_mm_xor_si128(ROTR((x), 2),ROTR((x), 13)),ROTR((x), 22)))
#define BIGSIGMA1_256(x)    (_mm_xor_si128(_mm_xor_si128(ROTR((x), 6),ROTR((x), 11)),ROTR((x), 25)))


#define SIGMA0_256(x)       (_mm_xor_si128(_mm_xor_si128(ROTR((x), 7),ROTR((x), 18)), SHR((x), 3 )))
#define SIGMA1_256(x)       (_mm_xor_si128(_mm_xor_si128(ROTR((x),17),ROTR((x), 19)), SHR((x), 10)))

it will compile with both gcc and icc. I hoped for a significant speed-up but for me Intel compiler is only about 10% faster on only one of my machines (Core i5) and slower on Core 2 and Opteron.  Nevertheless, the code is more universal. Isn't a similar code used also in the main bitcoin cruncher?

Last issue is very mysterious and I may have come across a strange race-condition bug in GLIBC (or something else) on my Cent OS. The program randomly segfaulted in multithreaded mode while working fine in single-threaded one and working OK on my another Ubuntu machine. Long story short, it seems it was related in name resolving and  I (hopefully) solved the problem by compiling libcurl with --enable-ares, which uses an asynchronous name resolution.

[LZ]

HP Mini 2133 (1 thread)
--algo c ~140-150 khps
--algo 4way ~165-175 khps
--algo via ~800-1200 khps
--algo cryptopp ~115-125 khps

It's great! Thanks!

[jgarzik]

New version 0.3 released (see top post for URLs).

Changes:

• Add crypto++ 32bit assembly implementation
• show version upon 'minerd --help'
• work around gcc 4.5.x bug that killed 4way performance

SHA1: e748faf3272a766f6de3e99ad1b6e434a0f3d023  cpuminer-installer-0.3.zip
MD5: c1fc335c2548afa726ac49871ff73d08  cpuminer-installer-0.3.zip

[jgarzik]

Note that older versions are moved, with each new release, to http://yyz.us/bitcoin/old/

[kseistrup]

I started mining with cpuminer/minerd a few days ago, and to keep the dæmon in the air I'm using Gerrit Pape's “runit” (an equivalent to DJB's dæmontools).  However, since stdout is fully buffered by default I don't see any informative output until stdout's buffer is full.  By making stdout line buffered each HashMeter line can be read as it happens.  Here's a tiny patch:

Code:

diff --git a/cpu-miner.c b/cpu-miner.c
index 5371296..82c1355 100644
--- a/cpu-miner.c
+++ b/cpu-miner.c
@@ -402,6 +402,7 @@ static void parse_cmdline(int argc, char *argv[])
 int main (int argc, char *argv[])
 {
 	int i;
+        int dummy = setvbuf(stdout, (char *) NULL, _IOLBF, 0);
 
 	/* parse command line */
 	parse_cmdline(argc, argv);

Cheers,

[kseistrup]

Code:

             val = json_rpc_call(rpc_url, userpass, rpc_req);
             if (!val) {
             fprintf(stderr, "json_rpc_call failed\n");
             return NULL;
            }

If there is a network or server problem, the client will fail and it happens quite frequently with pooled mining. I changed return NULL; to some sleep and
put it in a loop to wait until the network is up again. After such modification (and similar in submit_work) the client survived several server restarts.

Could you post an example, please?

Cheers,
Klaus

[Raulo]

Could you post an example, please?

I made an infinite loop but it might be a good idea to set up a retry counter.

Code:

          /* obtain new work from bitcoin */
             do {
             val = json_rpc_call(rpc_url, userpass, rpc_req);
             if (!val) {
                           fprintf(stderr, "json_rpc_call failed. sleeping 60s\n");
                           sleep(60);
                          }
             } while (!val);

You should also do the same around fprintf("submit_work json_rpc_call failed\n") with maybe a shorter sleep(10).

[slush]

I made an infinite loop but it might be a good idea to set up a retry counter.

Code:

             val = json_rpc_call(rpc_url, userpass, rpc_req);
             if (!val) {
                           fprintf(stderr, "json_rpc_call failed. sleeping 60s\n");
                           sleep(60);
                          }

I'm not so familiar with miner sources, but don't forget server can sometimes return 'false' when PoW not meet server's target. Doesn't your patch deadlock script for ages in this case?

[Raulo]

I'm not so familiar with miner sources, but don't forget server can sometimes return 'false' when PoW not meet server's target. Doesn't your patch deadlock script for ages in this case?

I'm not 100% sure there is no possibility of deadlock in any situation but in this case, no. json_rpc_call returns non-null pointer on successful communication. Even if communication results in 'false' result, this check will pass.

I tested the patched version on pooled mining (where success is frequent) and standalone mining (where the result usually does not pass the target) and it does not deadlock.

[romkyns]

Seems to work! Algo results on Q6600: c: 920, 4way: ~600, cryptopp: ~600, cryptopp_asm32: 1050. This is for a single thread.

I wish the way you logged information was compatible with file redirection. I run my miners in the background and redirect all output to a file. Most implementations log the data just fine, but yours outputs nothing.

For example:

   poclbm.exe --user=... --pass=... --host=...  >file

this outputs *nothing* in the console, but saves progress in "file". This is the expected behaviour for console programs.

   minerd.exe --algo cryptopp_asm32 --url [...] --userpass [...] >file

this prints progress info to the console, and creates an empty file.

(also, since I'm firing off requests... a zip package (no installer) would be most appreciated! )

Thanks for your effort!

---------

There's something dodgy with using multiple threads: one of the threads doesn't start, and the CPU usage is correspondingly below the expected amount. E.g. "starting 3 threads", but only 2 cores are used, only 2 threads report khash/sec, and only 2 threads are doing work according to ProcessExplorer.

Lastly, algorithm cryptopp_asm32 consistently generates proof of work that gets rejected with a "Boo" message.

[jgarzik]

Current git version will retry, if JSON-RPC call fails.

[Azetab]

Seems to work! Algo results on Q6600: c: 920, 4way: ~600, cryptopp: ~600, cryptopp_asm32: 1050. This is for a single thread.

I wish the way you logged information was compatible with file redirection. I run my miners in the background and redirect all output to a file. Most implementations log the data just fine, but yours outputs nothing.

For example:

   poclbm.exe --user=... --pass=... --host=...  >file

this outputs *nothing* in the console, but saves progress in "file". This is the expected behaviour for console programs.

   minerd.exe --algo cryptopp_asm32 --url [...] --userpass [...] >file

this prints progress info to the console, and creates an empty file.

(also, since I'm firing off requests... a zip package (no installer) would be most appreciated! )

Thanks for your effort!

---------

There's something dodgy with using multiple threads: one of the threads doesn't start, and the CPU usage is correspondingly below the expected amount. E.g. "starting 3 threads", but only 2 cores are used, only 2 threads report khash/sec, and only 2 threads are doing work according to ProcessExplorer.

Lastly, algorithm cryptopp_asm32 consistently generates proof of work that gets rejected with a "Boo" message.

I have this same problem, I have a Q9550, and with 4 threads, only 2 cores are used, and my khash/sec does not appear to be utilizing all four threads.

[lfm]

another fix for Via padlock, the 64 byte offset to the data parameter in the sha256 calls should not be used for via or it should be subtracted back out in the sha256_via.c

[adv]

If "d" in minerd mean daemon, then it must have ability to detach terminal. I think it must be first in TODO.