Works here, cryptopp_asm32 works 20% faster than 'c', so its about the same speed as the bitcoin standard client on windows 7-64. This is the fastest client so far.
1200 khash per core, on both 2.66 intel quad core and 2.66 intel core duo, per core that is.
Topic: New demonstration CPU miner available - page 22. (Read 386150 times)
Lastly, algorithm cryptopp_asm32 consistently generates proof of work that gets rejected with a "Boo" message.
I'm seeing the same problem. I've had many rejects and no successes using cryptopp_asm32 and have had many successes and very few rejects using the default algorithm. I'm using version 0.3.1. Has anyone had any success using cryptopp_asm32?
Weird. Running it with 4 threads is causing my GPU hash rate to bog down. That doesn't seem right. Why would the 2 be connected. The certainly are though because it sped up again when I shut the CPU miner down. That never happened when I was using the bitcoin client to generate. I'll try it with 2 threads and see what happens.
I just set this miner up and it appears to be working. However it is only running at about a third to a quarter of the hash speed I get when running the bitcoin client. It says it only has 1 miner thread started, do I need to increase that number in order for it to up it's speed?
I have a quad-core processor running Win7 64 if that matters.
I have a quad-core processor running Win7 64 if that matters.
Rise your 'threads' parameter to 4. Also play with 'algo' parameter, this can help a lot.
Yeah, there it is.
I tried that before and it was just doing the same thing. However there were some json_rpc_call failed messages that must have been 3 of the threads not starting right away. This time they all hooked on.
Thanks.
It does, you should check the command line options, they'll allow you to specify the number of threads you want running, usually one per core.
Also you can try the other options and see what works best for you.
Also you can try the other options and see what works best for you.
I just set this miner up and it appears to be working. However it is only running at about a third to a quarter of the hash speed I get when running the bitcoin client. It says it only has 1 miner thread started, do I need to increase that number in order for it to up it's speed?
I have a quad-core processor running Win7 64 if that matters.
I have a quad-core processor running Win7 64 if that matters.
Rise your 'threads' parameter to 4. Also play with 'algo' parameter, this can help a lot.
I just set this miner up and it appears to be working. However it is only running at about a third to a quarter of the hash speed I get when running the bitcoin client. It says it only has 1 miner thread started, do I need to increase that number in order for it to up it's speed?
I have a quad-core processor running Win7 64 if that matters.
I have a quad-core processor running Win7 64 if that matters.
DerrikeG, what is your CPU manufacturer and model name?
Can you try this? http://yyz.us/bitcoin/cpuminer-installer-0.3.1-i486.zip
The default cpuminer is built "-march=i686", which means the compiler generates and optimizes for Intel chips i686 and later. Some VIA chips lack a few key CPU instructions such as 'cmov' that the compiler generates, and as a result, minerd.exe binaries on these older VIA CPUs will probably crash.
No luck. Additionally, 4way on that build behaves like via does (doesn't work, quits instantly). C goes slower than usual. Cryptopp too. Cryptopp_asm32 clocks in where it used to, though. The default cpuminer is built "-march=i686", which means the compiler generates and optimizes for Intel chips i686 and later. Some VIA chips lack a few key CPU instructions such as 'cmov' that the compiler generates, and as a result, minerd.exe binaries on these older VIA CPUs will probably crash.
I can't get via to work, it just starts and ends without any messages, even when -d and -P flags are provided. Running the windows build on windows XP.
Can you try this? http://yyz.us/bitcoin/cpuminer-installer-0.3.1-i486.zip
The default cpuminer is built "-march=i686", which means the compiler generates and optimizes for Intel chips i686 and later. Some VIA chips lack a few key CPU instructions such as 'cmov' that the compiler generates, and as a result, minerd.exe binaries on these older VIA CPUs will probably crash.
Version 0.3.1 released. Changes:
- Critical fix for sha256_via
- Retry JSON-RPC failures (see --retry, under "minerd --help" output)
SHA1: c8da4ed8d73d71a73795b153f4ea157041cc51ba cpuminer-installer-0.3.1.zip
MD5: 69c228d4846e9940e3129a395a947080 cpuminer-installer-0.3.1.zip
Still don't know if sha256_via actually works -- testnet or pool testers requested.
I can't get via to work, it just starts and ends without any messages, even when -d and -P flags are provided. Running the windows build on windows XP.- Critical fix for sha256_via
- Retry JSON-RPC failures (see --retry, under "minerd --help" output)
SHA1: c8da4ed8d73d71a73795b153f4ea157041cc51ba cpuminer-installer-0.3.1.zip
MD5: 69c228d4846e9940e3129a395a947080 cpuminer-installer-0.3.1.zip
Still don't know if sha256_via actually works -- testnet or pool testers requested.
Also, what is (if there is any) the sleep time between retries? Is there a way to set it to retry indefinitely with a reasonable amount of time between attempts? Supplying the retry command at all causes it to instantly crash for me.
Version 0.3.1 released. Changes:
- Critical fix for sha256_via
- Retry JSON-RPC failures (see --retry, under "minerd --help" output)
SHA1: c8da4ed8d73d71a73795b153f4ea157041cc51ba cpuminer-installer-0.3.1.zip
MD5: 69c228d4846e9940e3129a395a947080 cpuminer-installer-0.3.1.zip
Still don't know if sha256_via actually works -- testnet or pool testers requested.
- Critical fix for sha256_via
- Retry JSON-RPC failures (see --retry, under "minerd --help" output)
SHA1: c8da4ed8d73d71a73795b153f4ea157041cc51ba cpuminer-installer-0.3.1.zip
MD5: 69c228d4846e9940e3129a395a947080 cpuminer-installer-0.3.1.zip
Still don't know if sha256_via actually works -- testnet or pool testers requested.
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
Code:
diff --git a/cpu-miner.c b/cpu-miner.c
index ac151f6..138ec9c 100644
--- a/cpu-miner.c
+++ b/cpu-miner.c
@@ -319,7 +319,7 @@ static void *miner_thread(void *thr_id_int)
#ifdef WANT_VIA_PADLOCK
case ALGO_VIA:
- rc = scanhash_via(work.midstate, work.data + 64,
+ rc = scanhash_via(work.midstate, work.data,
work.hash1, work.hash,
&hashes_done);
break;
diff --git a/sha256_via.c b/sha256_via.c
index 45e6821..ef2c102 100644
--- a/sha256_via.c
+++ b/sha256_via.c
@@ -35,7 +35,7 @@ bool scanhash_via(const unsigned char *midstate, const unsigne
unsigned char data[128] __attribute__((aligned(128)));
unsigned char tmp_hash1[32] __attribute__((aligned(128)));
uint32_t *hash32 = (uint32_t *) hash;
- uint32_t *nonce = (uint32_t *)(data + 12);
+ uint32_t *nonce = (uint32_t *)(data + 64 + 12);
uint32_t n = 0;
unsigned long stat_ctr = 0;
int i;
index ac151f6..138ec9c 100644
--- a/cpu-miner.c
+++ b/cpu-miner.c
@@ -319,7 +319,7 @@ static void *miner_thread(void *thr_id_int)
#ifdef WANT_VIA_PADLOCK
case ALGO_VIA:
- rc = scanhash_via(work.midstate, work.data + 64,
+ rc = scanhash_via(work.midstate, work.data,
work.hash1, work.hash,
&hashes_done);
break;
diff --git a/sha256_via.c b/sha256_via.c
index 45e6821..ef2c102 100644
--- a/sha256_via.c
+++ b/sha256_via.c
@@ -35,7 +35,7 @@ bool scanhash_via(const unsigned char *midstate, const unsigne
unsigned char data[128] __attribute__((aligned(128)));
unsigned char tmp_hash1[32] __attribute__((aligned(128)));
uint32_t *hash32 = (uint32_t *) hash;
- uint32_t *nonce = (uint32_t *)(data + 12);
+ uint32_t *nonce = (uint32_t *)(data + 64 + 12);
uint32_t n = 0;
unsigned long stat_ctr = 0;
int i;
...
Lastly, algorithm cryptopp_asm32 consistently generates proof of work that gets rejected with a "Boo" message.
Lastly, algorithm cryptopp_asm32 consistently generates proof of work that gets rejected with a "Boo" message.
This would be normal. Only 1/difficulty (1 in 12253) of the initial proof of work gets a yay, the rest get boo.
If "d" in minerd mean daemon, then it must have ability to detach terminal. I think it must be first in TODO.
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
Seems to work! 
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!
)
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.
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!
)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.
Current git version will retry, if JSON-RPC call fails.
Seems to work! 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!)
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.
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!
)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'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.
Jump to: