Ninjastic
Search content
Sort by
Showing 11 of 11 results by SawEfDir
Post
Topic
Board Mining software (miners)
Re: New demonstration CPU miner available
by
SawEfDir
on 30/03/2011, 17:02:33 UTC
Quote from: chromicant on March 27, 2011, 04:03:30 PM
Ok. Took a look at the logs. Seems like configure is not doing the yasm test correctly. Can you run yasm --version and open an issue on my Github page for cpuminer?

https://github.com/chromicant/cpuminer/issues
It seems the yasm version installed on my system was to old. I've thought I've installed version 1.1.0, but it actually was 0.8.0.
Debian unstable does only provide yasm 0.8.0. One can install 1.1.0 using the debian-multimedia.org repositories, though.

Thanks for you help.
Post
Topic
Board Mining software (miners)
Re: New demonstration CPU miner available
by
SawEfDir
on 27/03/2011, 14:31:04 UTC
Oh indeed, thanks for the hint:

config.log: http://pastebin.com/stxRvch7
configure stdout: http://pastebin.com/dbLQsjzF
make stdout: http://pastebin.com/dTV252An
Post
Topic
Board Mining software (miners)
Re: New demonstration CPU miner available
by
SawEfDir
on 27/03/2011, 12:36:45 UTC
I'm having troubles getting the new sse2_amd64 algo compiled on my amd64 debian unstable system. I'm using the source from the git repo, commit 69529c38594f7bd56b50b9effed5a45125ccba3e
Though .configure seems to find yasm, make doesn't seem to compile it properly like shown in other forum posts. Trying minerd --algo sse_amd64 fails with minerd displaying the help page. Other algos seem to work ok. Debian unstable uses gcc-4.5 by default.

Unfortunately, the forum won't let me attach any files because the upload folder is full, and I don't want to clutter the post with long log file outputs.

Is there any extra option must set for ./configure in order to get the sse2_amd64 compiled in?
Post
Topic
Board Mining software (miners)
Re: New demonstration CPU miner available
by
SawEfDir
on 16/01/2011, 07:07:45 UTC
Quote from: lfm on January 15, 2011, 10:51:15 PM
which looks like a 32 bit word swap but the byteswap involved is hidden

If this was not done right you would not have gotten the 50.00 btc at the end.

If you reverse the hash from cpuminer, the nibbles in each word are reversed. You would need to reverse the nibbles in each word, as well, in order to get the right hash. I guess the hash calculated is still correct, but it makes for bad surprises checking the minerd's output, getting hashes that seem to hit the target but actually don't.
Post
Topic
Board Mining software (miners)
Re: New demonstration CPU miner available
by
SawEfDir
on 15/01/2011, 22:19:53 UTC
something doesn't seem to be quite right with algo_via on 64bit yet

here's the output of cpuminer for a positive hash that was found running on testnet:
Code:
DBG: found zeroes in hash:
52a65c69ea7bfda3788ee2337f9bece38dbdc6d918c4e16c05f567b700000000
PROOF OF WORK FOUND?  submitting...
PROOF OF WORK RESULT: true (yay!!!)

here is the correspoding output from bitcoins testnet debug log
Code:
BitcoinMiner:
proof-of-work found
  hash: 0000000005f567b718c4e16c8dbdc6d97f9bece3788ee233ea7bfda352a65c69
target: 0000000015ebbe00000000000000000000000000000000000000000000000000
CBlock(hash=0000000005f567b718c4, ver=1, hashPrevBlock=00000000144f6debddf8, hashMerkleRoot=d645677c76, nTime=1294828227, nBits=1c15ebbe, nNonce=14019820, vtx=1)
  CTransaction(hash=d645677c76, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, -1), coinbase 04beeb151c0174)
    CTxOut(nValue=50.00000000, scriptPubKey=04bfa0f2be2ed07c434e900ec80e09)
  vMerkleTree: d645677c76
01/12/11 10:30 generated 50.00

it seems the byte swapping isn't working fully correctly yet, any hints?
Post
Topic
Board Mining software (miners)
Re: New demonstration CPU miner available
by
SawEfDir
on 02/01/2011, 01:08:25 UTC
I've tried the following patch on a VIA Nano L2200 @ 1600 MHz on a Debian unstable amd64 system.

The speed increase is almost negligible. I've compiled minerd with using -O3, and with the patch, I'm getting really close to
1700kh/s. Without the patch, I'm getting about 1680. Using the builtin seems to gain 1% speed or so.

I've tried it on the testnet and got a good hash really quickly, so it seems to work ok.

Code:
diff --git a/miner.h b/miner.h
index 7979dc0..eda9498 100644
--- a/miner.h
+++ b/miner.h
@@ -22,15 +22,9 @@
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
 #endif
 
-#define ___constant_swab32(x) ((uint32_t)(                       \
-        (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) |            \
-        (((uint32_t)(x) & (uint32_t)0x0000ff00UL) <<  8) |            \
-        (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >>  8) |            \
-        (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24)))
-
 static inline uint32_t swab32(uint32_t v)
 {
-       return ___constant_swab32(v);
+       return __builtin_bswap32(v);
 }
 
 extern bool opt_debug;
Post
Topic
Board Mining software (miners)
Re: New demonstration CPU miner available
by
SawEfDir
on 24/12/2010, 12:58:41 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: anyone tried running with VIA Padlock extensions?
by
SawEfDir
on 22/12/2010, 17:23:29 UTC
Quote from: SawEfDir on December 12, 2010, 05:36:14 PM
I'll try other algos now, to see if this behaviour is independent of the selected algorithm or not.

The -4way algo does seem to work alright and successfully generated a few coins within a day or so.

It seems there something wrong with the padlock code for the VIA Nano, at least in 64bit mode.
Post
Topic
Board Development & Technical Discussion
Re: anyone tried running with VIA Padlock extensions?
by
SawEfDir
on 12/12/2010, 17:36:14 UTC
I've tried that patch to main.cpp you suggested. Here the output from minerd:

Code:
DBG: found zeroes in hash:
7e242ac3d2f4298e502efd7e4b3677cc287114488e1c77c4a1406cba00000000
HashMeter(0): 7994345 hashes, 1587.98 khash/sec
PROOF OF WORK FOUND?  submitting...
PROOF OF WORK RESULT: false (booooo)

The output from patched bitcoind is this:

Code:
proof-of-work check FAILED...
  hash: 9c581ce97e417b9ea6ffb2502041a46ad740a74567e55bbd636d8944cc552995
target: 0000000045120800000000000000000000000000000000000000000000000000

FYI, I'm using bitcoin on a amd64 Debian unstable machine. Both bitcoind and minerd were compiled natively for amd64.

I'll try other algos now, to see if this behaviour is independent of the selected algorithm or not.
Post
Topic
Board Development & Technical Discussion
Re: anyone tried running with VIA Padlock extensions?
by
SawEfDir
on 03/12/2010, 21:07:38 UTC
Thanks for the info. I'll let the testnet client run for the night. What generate setting should bitcoind have? setgenerate set to true with limit to zero processors, or should setgenerate be set to false?
Post
Topic
Board Development & Technical Discussion
Re: anyone tried running with VIA Padlock extensions?
by
SawEfDir
on 03/12/2010, 19:08:28 UTC
I've tried the cpuminer version 0.2.1 on a VIA Nano machine. I used the "via" algo with a bitcoin running on the testnet. The miner worked, but the results generated seemed to be wrong, debug output pasted in below.
The system is a 64bit Debian unstable machine with a VIA VB8001 motherboards. It's running a stepping 2 VIA Nano. The kernel seems to do a workaround for Nanos with that stepping, perhaps something needs to be done in the miner code, as well.

Code:
HashMeter(0): 16777216 hashes, 1589.69 khash/sec
DBG: found zeroes in hash:
9ec42e51b34b69fc2f7209f3e334afcfa563d1da21647832cd2b312c00000000
HashMeter(0): 6644792 hashes, 1606.76 khash/sec
PROOF OF WORK FOUND?  submitting...
DBG: sending RPC call:
{"method": "getwork", "params": [ "000000016f643cccfaa9574cd1a3369a23da6452fcf296587e4da572a008520300000001f1071376c66751bede719672dd1e9e3b2a3daeec709fc5bcaede21364748d93a4cf93ea21d05106000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000" ], "id":1}
PROOF OF WORK RESULT: false (booooo)