Bitcoin Forum
March 29, 2024, 06:37:49 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
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 386157 times)
BitLex
Hero Member
*****
Offline Offline

Activity: 532
Merit: 505


View Profile
November 27, 2010, 12:50:02 AM
 #21

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.

The trust scores you see are subjective; they will change depending on who you have in your trust list.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711694269
Hero Member
*
Offline Offline

Posts: 1711694269

View Profile Personal Message (Offline)

Ignore
1711694269
Reply with quote  #2

1711694269
Report to moderator
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 27, 2010, 12:52:44 AM
 #22

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
BitLex
Hero Member
*****
Offline Offline

Activity: 532
Merit: 505


View Profile
November 27, 2010, 01:28:24 AM
 #23

--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 (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 27, 2010, 04:25:07 AM
 #24

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 27, 2010, 06:32:26 AM
 #25

Added VIA padlock support, in git.

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

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 27, 2010, 09:08:02 AM
 #26

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 27, 2010, 10:09:51 AM
 #27

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
BitLex
Hero Member
*****
Offline Offline

Activity: 532
Merit: 505


View Profile
November 27, 2010, 11:08:15 AM
 #28

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: 518
Merit: 252


555


View Profile WWW
November 27, 2010, 11:22:31 AM
 #29

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.

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 27, 2010, 06:32:15 PM
 #30

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
BitLex
Hero Member
*****
Offline Offline

Activity: 532
Merit: 505


View Profile
November 27, 2010, 07:25:29 PM
 #31

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

Activity: 56
Merit: 0


View Profile
November 28, 2010, 07:27:11 PM
 #32

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.
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 28, 2010, 08:07:15 PM
Last edit: December 06, 2010, 07:47:14 AM by jgarzik
 #33

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
farmer_boy
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
November 28, 2010, 09:46:15 PM
Last edit: November 29, 2010, 09:00:01 PM by farmer_boy
 #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 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...
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 29, 2010, 01:19:00 AM
 #35

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 29, 2010, 01:20:09 AM
 #36

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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
neptop
Sr. Member
****
Offline Offline

Activity: 314
Merit: 251


View Profile
November 29, 2010, 01:40:50 AM
 #37

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 (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 29, 2010, 02:27:42 AM
Last edit: November 29, 2010, 03:29:44 AM by jgarzik
 #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).

'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, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
teknohog
Sr. Member
****
Offline Offline

Activity: 518
Merit: 252


555


View Profile WWW
November 29, 2010, 01:48:54 PM
 #39

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.

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
jgarzik (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1091


View Profile
November 29, 2010, 05:21:55 PM
 #40

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

Fixed in git commit 145e5fe141857c0757fdb5bb6909583aa67691b1, just pushed to cpuminer.git.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
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:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!