Bitcoin Forum
December 06, 2016, 12:27:15 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 »
  Print  
Author Topic: New demonstration CPU miner available  (Read 374976 times)
BitLex
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
December 16, 2010, 06:16:11 PM
 #61

Quote from: 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).

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481027235
Hero Member
*
Offline Offline

Posts: 1481027235

View Profile Personal Message (Offline)

Ignore
1481027235
Reply with quote  #2

1481027235
Report to moderator
1481027235
Hero Member
*
Offline Offline

Posts: 1481027235

View Profile Personal Message (Offline)

Ignore
1481027235
Reply with quote  #2

1481027235
Report to moderator
Azetab
Newbie
*
Offline Offline

Activity: 19


View Profile
December 16, 2010, 06:40:26 PM
 #62

Quote from: 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
Newbie
*
Offline Offline

Activity: 19


View Profile
December 17, 2010, 02:13:02 AM
 #63

when I run this I get a json_rpc_call failed, does anyone know why?
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
December 17, 2010, 03:23:01 AM
 #64

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
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 17, 2010, 03:27:08 AM
 #65

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.


Quote from: 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 :-).

Thanks!

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 17, 2010, 06:02:08 AM
 #66

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Raulo
Full Member
***
Offline Offline

Activity: 238


View Profile
December 18, 2010, 01:28:51 PM
 #67

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.

1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
LZ
Staff
Legendary
*
Offline Offline

Activity: 1456


Satoshi everywhere!


View Profile WWW
December 18, 2010, 07:54:44 PM
 #68

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! Cheesy

"Never invest unless you can afford to lose your entire investment." © S3052
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 18, 2010, 09:35:39 PM
 #69

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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 18, 2010, 09:44:49 PM
 #70

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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
kseistrup
Hero Member
*****
Offline Offline

Activity: 565


Unselfish actions pay back better


View Profile WWW
December 18, 2010, 09:50:05 PM
 #71

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,

Klaus Alexander Seistrup
http://about.me/kseistrup
kseistrup
Hero Member
*****
Offline Offline

Activity: 565


Unselfish actions pay back better


View Profile WWW
December 19, 2010, 08:30:57 AM
 #72

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

Klaus Alexander Seistrup
http://about.me/kseistrup
Raulo
Full Member
***
Offline Offline

Activity: 238


View Profile
December 19, 2010, 10:07:12 AM
 #73

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

1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
December 19, 2010, 12:04:56 PM
 #74

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
Full Member
***
Offline Offline

Activity: 238


View Profile
December 19, 2010, 01:09:09 PM
 #75

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.

1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
romkyns
Newbie
*
Offline Offline

Activity: 19


View Profile
December 19, 2010, 01:44:40 PM
 #76

Seems to work! Smiley 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! Cheesy)

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
Legendary
*
Offline Offline

Activity: 1470


View Profile
December 19, 2010, 06:07:47 PM
 #77

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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Azetab
Newbie
*
Offline Offline

Activity: 19


View Profile
December 19, 2010, 06:18:26 PM
 #78

Seems to work! Smiley 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! Cheesy)

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
Full Member
***
Offline Offline

Activity: 196



View Profile
December 20, 2010, 02:03:14 AM
 #79

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
Full Member
***
Offline Offline

Activity: 169


View Profile
December 20, 2010, 02:11:15 AM
 #80

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

U may thank me here: 14Js1ng1SvYBPgUJnjNAEPYH4d6SHF79UF
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!