New demonstration CPU miner available

[kseistrup]

main.cpp?  There's no such file in the cpuminer directory…

I think he's asking you to patch the Bitcoin client to which you are connecting your CPU miner, not the miner itself.

You're right, I missed that… 

Cheers,

[jgarzik]

What does this bitcoin patch print out for you, when using cryptopp_asm32?

http://yyz.us/bitcoin/patch.bitcoin-pow-fail

main.cpp?  There's no such file in the cpuminer directory…

"bitcoin patch" == a patch to bitcoin, not cpuminer.

[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

Good catch.  This seems to imply that sha256_via has never actually worked.  I pushed the following change out to git... can anyone test the latest git on testnet and verify that a proof-of-work is actually found?  This bitcoind patch may help debugging: http://yyz.us/bitcoin/patch.bitcoin-pow-fail

ok it seems the via c7 hash is NOT working right. the bitcoin patch puts out this:

proof-of-work check FAILED...
  hash: 0690332bc5f9d16e9071934f5bccdb1a1b9a7265a2cdfc2a59bd9f72c6e137a5
target: 0000000045120800000000000000000000000000000000000000000000000000

which doest match the minerd:

DBG: found zeroes in hash:
ca71e510100ee12f70ff852e168f332cf155c60fc8eac979d5080c3600000000

at all.

Im not sure if its one of the byteswap loops or the asm() compiling wrong or what. Ill try to figure it out.

[lfm]

I think the problem for via is we have to move the (byte swapped) nonce back into the data_in parameter to return it.


yes now I get

proof-of-work check FAILED...
  hash: 00000000b91b13334f2636c2e0350bcb9592884ffe5af36e1f13a49e16f081fa
target: 0000000045120800000000000000000000000000000000000000000000000000

with

DBG: found zeroes in hash:
16f081fa1f13a49efe5af36e9592884fe0350bcb4f2636c2b91b133300000000

which matches correctly now when you do the byte swaps and all makes sense

[jgarzik]

I think the problem for via is we have to move the (byte swapped) nonce back into the data_in parameter to return it.

Indeed.  cpuminer 0.3.2 is out there, with another sha256_via fix attempt.

Via CPU owners, please report feedback.

[lfm]

I think the problem for via is we have to move the (byte swapped) nonce back into the data_in parameter to return it.

Indeed.  cpuminer 0.3.2 is out there, with another sha256_via fix attempt.

Via CPU owners, please report feedback.

I got a (yay!!) block on testnet with 0.3.2. I think we can declare it works. For via C7. Can someone else try Nano?

[SawEfDir]

Output of good hash found on VIA Nano running on Debian Sid amd64:

Code:

DBG: found zeroes in hash:
4ec9d2d025d0efbfb8c014783dba964ddfb9e9f337d72c62038bd65d00000000
HashMeter(0): 5887329 hashes, 1635.98 khash/sec
PROOF OF WORK FOUND?  submitting...
PROOF OF WORK RESULT: true (yay!!!)

It seems algo-via works on VIA Nano now, thanks a lot.

[slush]

There are few reports from users that cryptopp_asm32 is not working correctly for them. Is it known issue?

[jgarzik]

Version 0.3.3 is out there, with a critical one-line fix for cryptopp_asm algo.

SHA1: a7c0822c3ab0f9f2089fbc65cdbe2506789e4241  cpuminer-installer-0.3.3.zip
MD5: 2df889eebf752b5f35293e4cbe53f7e8  cpuminer-installer-0.3.3.zip

[Cdecker]

I can confirm the cryptopp_asm algo to be working and also got the shortest ever waiting time for a yay

Code:

$  ./minerd --userpass user:pass --url http://mining.bitcoin.cz:8332 --threads 2 --algo cryptopp_asm32
2 miner threads started, using SHA256 'cryptopp_asm32' algorithm.
DBG: found zeroes in hash:
78bf640434f5b45f8095269ed74d04ce23ea3fdaf6e16f0233006b8400000000
HashMeter(1): 1336480 hashes, 887.16 khash/sec
PROOF OF WORK FOUND?  submitting...
PROOF OF WORK RESULT: true (yay!!!)

[jgarzik]

All I get on Trisquel GNU/Linux is:

JSON key 'midstate' not found
JSON inval midstate
JSON-decode of work failed, retry after 30 seconds

What does 'getwork' return for you, if you issue it manually?

It sounds like there is a problem with your bitcoin client's JSON-RPC server.  Maybe password is incorrect, or rpcallowip option is misused?

[slush]

For info: I made little tweak on pool side; it returns json rpc error in case of site maintenance (instead of 500 Server Error and some HTML stuff). I believe this is more correct for miners, but it may lead to errors like 'midstate not found', because on getwork there is simply result:null and some error text.

[jgarzik]

For info: I made little tweak on pool side; it returns json rpc error in case of site maintenance (instead of 500 Server Error and some HTML stuff). I believe this is more correct for miners, but it may lead to errors like 'midstate not found', because on getwork there is simply result:null and some error text.

Just pushed the following to cpuminer.git...

commit 9e5a173c3845fb7b5d316b0455352a08847b8c23
Author: Jeff Garzik <jeff@garzik.org>
Date:   Tue Dec 28 15:22:53 2010 -0500

    Improve JSON-RPC result/error checking, and improve error diagnostic output.

[jgarzik]

Version 0.5 is released.  See top post for URLs.  Changes:
- Exit program, when all threads have exited
- Improve JSON-RPC failure diagnostics and resilience
- Add --quiet option, to disable hashmeter output.

SHA1: 59a6b409c016468fb195619e46efe14db2f1aca8  cpuminer-installer-0.5.zip
MD5: 9d3fca8067ed4a3de9fb1df9d066c7be  cpuminer-installer-0.5.zip

The new logic to wait for thread exit should work just fine under Windows.  Let me know if version 0.5 behaves strangely under Windows, doing things like exiting immediately.

[Rai]

Running on Windows 7 Ultimate with an Intel Core 2 Duo 2.4 ghz
It seems to exit immediately, but it could just be exiting properly too fast for me to notice.  Is there a way to tell if it is exiting properly?

[jgarzik]

Running on Windows 7 Ultimate with an Intel Core 2 Duo 2.4 ghz
It seems to exit immediately, but it could just be exiting properly too fast for me to notice.  Is there a way to tell if it is exiting properly?

What arguments are you passing to minerd?  Have you verified that version 0.3.3 works with the same command line?

The purpose of a miner is to continue running into infinity, so it should only exit if downloading work via JSON-RPC is repeatedly failing.

[Rai]

minerd.exe -a cryptopp_asm32 --url http://mining.bitcoin.cz:8332 --userpass MyUserName:MyPassword

Version 0.5 works, it gets good proofs, and I didn't change the command line from 0.3.3.  I just can't tell if it exits correctly, which is what you were asking about if I'm reading your post correctly.  

The new logic to wait for thread exit should work just fine under Windows.  Let me know if version 0.5 behaves strangely under Windows, doing things like exiting immediately.

I eventually have to stop it myself to shut the machine down from time to time, and I cannot tell if it's stopping the threads the way they're supposed to.  Also, I'm not specifying a number of threads over 1 because I'm also running a GPU miner, and running 2 or more threads makes the GPU miner lose performance, so this miner just provides 1200 supplemental khps.

[jgarzik]

It is supposed to exit immediately upon Ctrl-C.

Rai said "it exits immediately", which I interpreted to mean "exits as soon as it is run, without calculating any hashes."  That would be a huge problem, indicating that cpuminer no longer did any useful work! Rai clarified in a later post.

Everything appears to be working correctly on Windows.

[nanotube]

running ./configure for the .5 release, i get this:

Code:

configure: error: Missing required libcurl >= 7.10.1

this is on ubuntu lucid 32bit, with libcurl 7.19.7-1ubuntu1 installed.
any thoughts on why it'd think 7.19.7 is not >= 7.10.1 ?

[jgarzik]

running ./configure for the .5 release, i get this:

Code:

configure: error: Missing required libcurl >= 7.10.1

this is on ubuntu lucid 32bit, with libcurl 7.19.7-1ubuntu1 installed.
any thoughts on why it'd think 7.19.7 is not >= 7.10.1 ?

maybe curl-config is broken or missing?  You could try passing --with-libcurl={directory} to configure.