Bitcoin Forum
April 24, 2014, 01:58:58 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   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 305408 times)
jgarzik
Staff
Hero Member
*****
Offline Offline

Activity: 1260


View Profile

Ignore
November 27, 2010, 12:32:04 AM
 #21

Quote
I'd be interested to see how well this works on Vista, XP, 7, ...
complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP,
am i missing something?

Updated the installer at http://yyz.us/bitcoin/cpuminer-installer.zip

Does the problem still exist?

EDIT:  Here are the checksums for the latest Windows installer zipfile...
     Size: 1978933 bytes
     SHA1: fdea8a045db5e09b7441a4059fbdba186490e742  
     MD5: e60dbfb7c3b458c2a98e71cb295f9b7d  

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

Posts: 1398347938

View Profile Personal Message (Offline)

Ignore
1398347938
Reply with quote  #2

1398347938
Report to moderator
1398347938
Hero Member
*
Offline Offline

Posts: 1398347938

View Profile Personal Message (Offline)

Ignore
1398347938
Reply with quote  #2

1398347938
Report to moderator
1398347938
Hero Member
*
Offline Offline

Posts: 1398347938

View Profile Personal Message (Offline)

Ignore
1398347938
Reply with quote  #2

1398347938
Report to moderator
Unbeatable Service & Product Support
Grab Your Miners at GAWMiners.com
Order Before April 25th to receive
Double your Hashing Power for 1 week!

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

Posts: 1398347938

View Profile Personal Message (Offline)

Ignore
1398347938
Reply with quote  #2

1398347938
Report to moderator
1398347938
Hero Member
*
Offline Offline

Posts: 1398347938

View Profile Personal Message (Offline)

Ignore
1398347938
Reply with quote  #2

1398347938
Report to moderator
1398347938
Hero Member
*
Offline Offline

Posts: 1398347938

View Profile Personal Message (Offline)

Ignore
1398347938
Reply with quote  #2

1398347938
Report to moderator
BitLex
Staff
Hero Member
*****
Offline Offline

Activity: 868


View Profile WWW

Ignore
November 27, 2010, 12:50:02 AM
 #22

yay! now it works.

running at ~50% on dual-, 30-40% on a triple-core only (at default settings), but it works.
gonna play with settings later.

jgarzik
Staff
Hero Member
*****
Offline Offline

Activity: 1260


View Profile

Ignore
November 27, 2010, 12:52:44 AM
 #23

Note that the khash/sec calculations are known to be buggy, so you cannot trust those numbers Sad  Will try to fix that soonish, so people may accurately compare numbers with other installations.

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

Activity: 868


View Profile WWW

Ignore
November 27, 2010, 01:28:24 AM
 #24

--threads scales nicely with cores, unfortunately it drags GPU-miners down (a lot) when running on all cores,
but i guess most GPU miners won't care about one CPU more or less anyway.  Grin

--algo=4way pretends to work, burns CPU and stuff, but only shows 0.00khash/s all time and some PROOF...false msgs, so i think it doesn't.

--url works just fine, all my (non-client) miners are connected to a single node

tested on 64bit XP & 7

jgarzik
Staff
Hero Member
*****
Offline Offline

Activity: 1260


View Profile

Ignore
November 27, 2010, 04:25:07 AM
 #25

Updated the git repo (Linux) and http://yyz.us/bitcoin/cpuminer-installer.zip (Windows) to fix hash meter problems.

Size: 1858209
SHA1: c9c2695b7f6708956dfe9b06e02a28fdc0cf46c9
MD5: 144e2c7d61d739a267bb623122e103e7

--algo=4way pretends to work, burns CPU and stuff, but only shows 0.00khash/s all time and some PROOF...false msgs, so i think it doesn't.

I fixed the 0.00 khash/s problem, but it looks like the algorithm might be returning incorrect hashes.  I marked it "EXPERIMENTAL" in --help for now.

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

Activity: 1260


View Profile

Ignore
November 27, 2010, 06:32:26 AM
 #26

Added VIA padlock support, in git.

Completely untested -- I don't have the hardware.

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

Activity: 1260


View Profile

Ignore
November 27, 2010, 09:08:02 AM
 #27

Ok, I think I've fixed 4way.  The 4way scanhash was only patching the base nonce into the data block, rather than the nonce successfully found using the vector SSE2 code.  The code now seems to be successfully finding hashes with a large amount of zero bits.

Version 0.2 has been pushed out to git repo, and Windows installer has been updated.  See top of thread for updated URLs. See NEWS file or git repo for full list of changes.

SHA1: 61809a3f09363ab9d83e7b727909e70d2e1a3f8c  cpuminer-installer-0.2.zip
MD5: bdcf1b956688f46cd8591656887cb3a6  cpuminer-installer-0.2.zip

Edit:  just generated a testnet block w/ 4way.  Looks like it's working.

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

Activity: 1260


View Profile

Ignore
November 27, 2010, 10:09:51 AM
 #28

Curious users may find the following patch useful for observing bitcoin miner proof-of-work results.  Current miners seem to work like this:
  • Increment nonce in block header
  • Double-SHA256 hash the block header
  • If some number of high bits are zero, stop hashing, and perform an exhaustive proof-of-work validation check:  Decompose the sha256 hash result into a 256-bit integer, and compare that integer with the target.
  • Otherwise, loop back to step #1.

The net result is that it is entirely normal to stop hashing, perform proof-of-work validation, and fail.

The following simple patch will log such failures to the debug log. Again, it is normal to see these sorts of events pop up occasionally.

Code:
diff --git a/main.cpp b/main.cpp
index acfcbc9..1c5ca69 100644
--- a/main.cpp
+++ b/main.cpp
@@ -3273,8 +3273,11 @@ bool CheckWork(CBlock* pblock, CReserveKey& reservekey)
     uint256 hash = pblock->GetHash();
     uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
 
-    if (hash > hashTarget)
+    if (hash > hashTarget) {
+           printf("proof-of-work check FAILED...\n  hash:   %s\n  target: %s\n"
+                  hash.GetHex().c_str(), hashTarget.GetHex().c_str());
         return false;
+    }
 
     //// debug print
     printf("BitcoinMiner:\n");

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

Activity: 868


View Profile WWW

Ignore
November 27, 2010, 11:08:15 AM
 #29

some more tests with v0.2

AMD X3 720 @2.8GHz winXPx64
threads=1
c=1020khash/s -> 4way=2400khash/s

default client-miner gets ~3800khash/s on this machine, so if your HashMeter is a bit less wildly inaccurate now, 4way runs almost twice as fast.


AMD X2 BE-2350 @2.36GHz win7x64
therads=1
c=860khash/s -> 4way=1060khash/s

default client-miner gets ~2000khash/s here, still a little improvement, but far from the one above.

teknohog
Sr. Member
****
Offline Offline

Activity: 273



View Profile WWW

Ignore
November 27, 2010, 11:22:31 AM
 #30

EDIT:  If you lack jansson, current cpuminer.git will build an in-tree version.  Thus, you may opt to fix the problem by... removing jansson from your system.

Cheers, this is now faster than mainline on an Atom D510 Smiley While a GPU miner is hogging one core, mainline gives about 305 khash/s, and cpuminer gives about 480. Both of these are using several threads for HT, which actually makes a huge difference.

One reason may be that the mainline client segfaults with -march=atom (gcc 4.5.1), but for cpuminer it works fine. Since the Atom has an in-order architecture, this again makes a big difference.

So Lazy, Obviously True Hodler Sf67i4Xeqkn7mMcJ2nNT7uPUZXnoeqWfZh
jgarzik
Staff
Hero Member
*****
Offline Offline

Activity: 1260


View Profile

Ignore
November 27, 2010, 06:32:15 PM
 #31

AMD X3 720 @2.8GHz winXPx64
c=1020khash/s -> 4way=2400khash/s

default client-miner gets ~3800khash/s on this machine

AMD X2 BE-2350 @2.36GHz win7x64
c=860khash/s -> 4way=1060khash/s

default client-miner gets ~2000khash/s here, still a little improvement, but far from the one above.

It is strange that the default client-miner is so much faster for you.  Surely your bitcoin client is running multiple threads, to achieve 3800 khash/s, yes?

Thanks for reporting results!  cpuminer v0.2's hashmeter should be accurate.  Note that cpuminer prints out speed for each thread, not a total for all threads:

Code:
[jgarzik@bd cpuminer]$ ./minerd -t2 -a4way
2 miner threads started, using SHA256 '4way' algorithm.
HashMeter(0): 16777216 hashes, 1828.44 khash/sec
HashMeter(1): 16777216 hashes, 1832.77 khash/sec

"HashMeter(0)" is thread #0.  "HashMeter(1)" is thread #1.

Therefore, I am getting 3660 khash/sec in total.


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

Activity: 868


View Profile WWW

Ignore
November 27, 2010, 07:25:29 PM
 #32

Quote
Surely your bitcoin client is running multiple threads, to achieve 3800 khash/s, yes?
yes of course, it's 3800 running unlimited (=on all cores) on the AMD X3 bitcoin client,
thats a bit faster than your miner at default c=3x1020= 3060khash/s,
but only about half of what yours does at 4way=3x2400= 7200khash/s.
impressive!

on the older X2 the math goes
bitcoin client= 2000khash/s
jgarzik c=2x860= 1720khash/s
jgarzik 4way=2x1060= 2120khash/s
not that much, but still noticable.


and here's another one
Intel(R) Atom N270 @1600MHz (singlecore pretending to be 2) WinXP 32

bitcoin-client= 420khash/s (330 "limited to 1 core")

jgarzik's miner=
threads=1 c= 220khash/s
threads=2 c=2x164= 328khash/s


4way just slows it down to 196 on a single and 2x140 on 2threads.

farmer_boy
Jr. Member
*
Offline Offline

Activity: 56


View Profile

Ignore
November 28, 2010, 07:27:11 PM
 #33

The 4way implementation is slower on my IntelCore2Duo. The 'c' implementation is about 20% slower than the one in mainline. Still, I understood from the announcement that it was not actually the intention to go faster, but simply to show how to write one. In terms of work required to get this miner to work, it is the best miner sofar. It compiled out of the "box" (git).

I would consider this experiment to be a complete success.

What exactly happens when I send the KILL signal to the program? Is there any chance that bitcoins are lost for example? The same question applies to all miner programs.

Test sending bitcoins to this address: 1P2NYce9Gj2eDN1GQNYaxkjm1npvmdqY4F
jgarzik
Staff
Hero Member
*****
Offline Offline

Activity: 1260


View Profile

Ignore
November 28, 2010, 08:07:15 PM
 #34

The 4way implementation is slower on my IntelCore2Duo. The 'c' implementation is about 20% slower than the one in mainline.

What platform?  And, is it 32-bit or 64-bit?

I'm guessing my miner will be slower than mainline on 32-bit, because Crypto++ has a SHA256 32-bit assembly implementation, and I think mainline uses that on 32-bit platforms.

Quote
What exactly happens when I send the KILL signal to the program? Is there any chance that bitcoins are lost for example? The same question applies to all miner programs.

Miners submit work immediately, via HTTP JSON-RPC, as soon as they find a possible solution.  You'll only lose bitcoins if you KILL in a tiny window of opportunity where you found a solution and it has not yet submitted.

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

Activity: 56


View Profile

Ignore
November 28, 2010, 09:46:15 PM
 #35

The 4way implementation is slower on my IntelCore2Duo. The 'c' implementation is about 20% slower than the one in mainline.

What platform?  And, is it 32-bit or 64-bit?

I'm guessing my miner will be slower than mainline on 32-bit, because Crypto++ has a SHA256 32-bit assembly implementation, and I think mainline uses that on 32-bit platforms.

Quote
What exactly happens when I send the KILL signal to the program? Is there any chance that bitcoins are lost for example? The same question applies to all miner programs.

Miners submit work immediately, via HTTP JSON-RPC, as soon as they find a possible solution.  You'll only lose bitcoins if you KILL in a rare situation where you found a solution and it has not yet submitted.
Platform: 64 bit Linux. It might be better to catch the KILL SIGNAL complete the current work and even catch this unlikely case. OTOH, it might not be worth the effort, since the chance of creating one is so small...

Test sending bitcoins to this address: 1P2NYce9Gj2eDN1GQNYaxkjm1npvmdqY4F
jgarzik
Staff
Hero Member
*****
Offline Offline

Activity: 1260


View Profile

Ignore
November 29, 2010, 01:19:00 AM
 #36

Platform: 64 bit Linux.

Strange.  I wouldn't have thought the mainline implementation would be that much faster on 64-bit.

Quote
It might be better to catch the KILL SIGNAL complete the current work and even catch this unlikely case. OTOH, it might not be worth the effort, since the change of creating one is so small...

At some point you have to surrender to the fact that killing the miner means possibly missing a solution that would have been found, if you only gave it another microsecond to run...  Smiley

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

Activity: 1260


View Profile

Ignore
November 29, 2010, 01:20:09 AM
 #37

Just added the Crypto++ implementation of SHA256 to cpuminer.git.  C only, though I would eventually like to add asm for 32-bit.

sha.cpp, converted to C, seems slower than cpuminer's current "c" algorithm.

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

Activity: 313


View Profile

Ignore
November 29, 2010, 01:40:50 AM
 #38

I think miners should retry connection every now and then if the master is not available, so you don't have to care if it is temporary down (i.e. while updating).

BitCoin address: 1E25UJEbifEejpYh117APmjYSXdLiJUCAZ
jgarzik
Staff
Hero Member
*****
Offline Offline

Activity: 1260


View Profile

Ignore
November 29, 2010, 02:27:42 AM
 #39

I think miners should retry connection every now and then if the master is not available, so you don't have to care if it is temporary down (i.e. while updating).

'getwork' miners (such as mine) already do this.  The basic algorithm looks like this:
  • 1. Connect to bitcoin via TCP, obtain work
  • 2. Work on work (no TCP connection required, needed, or used)
  • 3. If solution found, connect to bitcoin via TCP and submit solution
  • 4. Go to step #1.

If bitcoin is down when a solution is found, presumably the solution will be invalid by the time bitcoin comes back up, so the "retry" with solution seems less than useful.  A "retry" is really just going back to obtain more work (step #1).

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

Activity: 273



View Profile WWW

Ignore
November 29, 2010, 01:48:54 PM
 #40

This has happened to me every time a hash with zeros is found on my 64-bit Atom system:

Code:
DBG: found zeroes in hash:
d624b64665519a6e0c74eeca4e00a5be937086db86f106b0ed6e759400000000
HashMeter(2): 8150287 hashes, 123.22 khash/sec
PROOF OF WORK FOUND?  submitting... 
*** buffer overflow detected ***: ./minerd terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f6a2387f847]
/lib/libc.so.6(+0xe56c0)[0x7f6a2387d6c0]
/lib/libc.so.6(+0xe4a39)[0x7f6a2387ca39]
/lib/libc.so.6(_IO_default_xsputn+0x81)[0x7f6a23809651]
/lib/libc.so.6(_IO_vfprintf+0x3f6f)[0x7f6a237ddbef]
/lib/libc.so.6(__vsprintf_chk+0x9d)[0x7f6a2387cadd]
/lib/libc.so.6(__sprintf_chk+0x7f)[0x7f6a2387ca1f]
./minerd[0x401958]
/lib/libpthread.so.0(+0x6c1a)[0x7f6a23b04c1a]
/lib/libc.so.6(clone+0x6d)[0x7f6a2386992d]

I mentioned the problems with -march=atom CFLAGS previously, but this does not go away when changing the -march.

So Lazy, Obviously True Hodler Sf67i4Xeqkn7mMcJ2nNT7uPUZXnoeqWfZh
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!