pooler (OP)
|
|
June 03, 2012, 09:46:26 AM |
|
Is this normal? [...] Using minerd.exe --url http://lc.ozco.in:9332/ --userpass *removed*.*removed*:*removed* --threads 4 --algo sha256d You are connecting to a Litecoin pool (lc.ozco.in) but then you tell the miner to use the Bitcoin algorithm (--algo sha256d) instead of the Litecoin one. Please make up your mind. It is important to understand that the --algo option doesn't work the same way as it did in the original cpuminer by jgarzik. In the original version you had a bunch of implementations of the same algorithm (SHA-256d) to choose from, while here you have two completely different algorithms, which are not interchangeable. If you try to use "--algo=sha256d" to mine Litecoins all you will get is invalid shares.
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
pekv2
|
|
June 03, 2012, 04:36:57 PM |
|
Is this normal? [...] Using minerd.exe --url http://lc.ozco.in:9332/ --userpass *removed*.*removed*:*removed* --threads 4 --algo sha256d You are connecting to a Litecoin pool (lc.ozco.in) but then you tell the miner to use the Bitcoin algorithm (--algo sha256d) instead of the Litecoin one. Please make up your mind. It is important to understand that the --algo option doesn't work the same way as it did in the original cpuminer by jgarzik. In the original version you had a bunch of implementations of the same algorithm (SHA-256d) to choose from, while here you have two completely different algorithms, which are not interchangeable. If you try to use "--algo=sha256d" to mine Litecoins all you will get is invalid shares. Like stated, I've never litecoin mined, I am new to it, meaning new to know what the switches are for. I was using the "--algo=sha256d" because from a small look at the end of this thread was the only switch I found. Could you add this switch to the OP? "--algo scrypt" stating this is the correct switch to use with litecoin & not to use the --algo sha256d. Other than that I am mining at 20 KH/s with my i3-2100 & I am sure the ram helps a lot which I got tight timings ram which is this set here F3-12800CL8D-8GBXM, set @ 8-8-8-23 in the bios. Using minerd.exe --url http://lc.ozco.in:9332/ --userpass ajshdjshajsh.1:1234 --threads 4 --algo scrypt . Thanks, Pooler for this lovely program for ones that cannot GPU mine bitcoins. Two thumbs up.
|
|
|
|
pooler (OP)
|
|
June 03, 2012, 04:57:54 PM |
|
Could you add this switch to the OP? "--algo scrypt" stating this is the correct switch to use with litecoin & not to use the --algo sha256d.
"--algo scrypt" is the default, you don't need to specify it. The "--algo sha256d" option was only added in version 2.2. Other than that I am mining at 20 KH/s with my i3-2100 & I am sure the ram helps a lot which I got tight timings ram which is this set here F3-12800CL8D-8GBXM, set @ 8-8-8-23 in the bios.
Well, to be honest I doubt RAM can affect the miner's performance. All the memory used by the miner should fit into L2 cache.
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
pekv2
|
|
June 03, 2012, 05:04:52 PM |
|
Well, to be honest I doubt RAM can affect the miner's performance. All the memory used by the miner should fit into L2 cache.
I am not speaking of memory in terms but talking about the memory timings, tighter-lower ram timings = greater performance in any application . If you have several different sticks of ram "value to performance" and test it with the same processor, I bet you will see a noticable increase of mining with performance ram.
|
|
|
|
pieppiep
|
|
June 03, 2012, 05:41:46 PM |
|
Well, to be honest I doubt RAM can affect the miner's performance. All the memory used by the miner should fit into L2 cache.
I am not speaking of memory in terms but talking about the memory timings, tighter-lower ram timings = greater performance in any application . If you have several different sticks of ram "value to performance" and test it with the same processor, I bet you will see a noticable increase of mining with performance ram. No, you won't see an increase if the memory you need is smaller than cache size because the memory won't be read because the cache knows whats in it.
|
|
|
|
Pontius
|
|
June 05, 2012, 02:04:10 PM |
|
pooler, there seems to be a problem with cpuminer when connecting (mining): [2012-06-05 14:35:55] HTTP request failed: The requested URL returned error: 503 [2012-06-05 14:36:25] Long-polling activated for <pool id> [2012-06-05 14:41:59] HTTP request failed: The requested URL returned error: 503 [2012-06-05 14:43:22] HTTP request failed: necessary data rewind wasn't possible [2012-06-05 14:43:22] json_rpc_call failed, retry after 30 seconds [2012-06-05 14:44:23] HTTP request failed: necessary data rewind wasn't possible [2012-06-05 14:44:23] json_rpc_call failed, retry after 30 seconds [2012-06-05 14:45:32] HTTP request failed: The requested URL returned error: 503 [2012-06-05 14:46:02] Long-polling activated for <pool id> I tried with three different pools (OzCoin, MaxBTC, BTCGuild) and three different miners (cpuminer, cgminer, ufasoft) and I get those HTTP errors only with cpuminer. Setups to reproduce this: minerd -V cpuminer 2.2.1 libcurl/7.22.0 GnuTLS/2.12.14 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 minerd -V cpuminer 2.2.1 libcurl/7.21.7 OpenSSL/0.9.7a zlib/1.2.1.2 libidn/0.5.6 Any idea what's going on here?
|
|
|
|
pooler (OP)
|
|
June 05, 2012, 08:22:44 PM |
|
Pontius, that's strange. I have briefly tested Bitcoin mining at OzCoin and BTCGuild and everything seems to work fine. Do you get the error as soon as you start the miner, or only after some time?
By the way, I ignore what those pools' particular software mean by 503, but usually status code 503 means "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server".
I would try running the miner with the protocol dump turned on (-P flag), maybe that could provide some clue as to what's going on.
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
Pontius
|
|
June 06, 2012, 08:45:17 AM Last edit: June 06, 2012, 12:54:19 PM by Pontius |
|
No, this doesn't occur at startup but during runtime (might be after a few seconds, might be after minutes of mining). * Re-using existing connection! (#0) with host <proxy name> * Connected to <proxy name> (proxy ip) port 8080 (#0) * Server auth using Basic with user 'pontius.X' > POST http://eu.ozco.in HTTP/1.1 Authorization: Basic xxxx Host: eu.ozco.in Accept-Encoding: deflate, gzip Proxy-Connection: Keep-Alive Content-Type: application/json Content-Length: 45 User-Agent: cpuminer 2.2.1 X-Mining-Extensions: midstate
< HTTP/1.1 200 OK < X-Long-Polling: /LP < X-Blocknum: 183252 < Server: ecoinpool/0.3.17 < Date: Wed, 06 Jun 2012 08:32:48 GMT < Content-Type: application/json < Cache-Control: proxy-revalidate < Content-Length: 374 < Proxy-Connection: Keep-Alive < Connection: Keep-Alive < * Recv failure: Connection reset by peer * Closing connection #0 [2012-06-06 10:31:59] HTTP request failed: Recv failure: Connection reset by peer * Connection #0 to host <proxy name> left intact [2012-06-06 10:32:00] JSON protocol response: { "error": null, "result": { "data": "00000001528fa730126f0141b1f42c33b968e0d3cde2e9e171c4a221000007fa00000000c65a5758e232e448e1d1848014c1da7ce2d2604e5466c0342b402d7440d8fcef4fcf15991a0a8b5f0000000000000080000000000000000000000000000000 0000000000000000000000000000000000000000000000000080020000", "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000" }, "id": 0 } [2012-06-06 10:32:00] JSON protocol request: {"method": "getwork", "params": [], "id":0} And here's another one: * Connection died, retrying a fresh connect * necessary data rewind wasn't possible * Closing connection #0 * Issue another request to this URL: 'http://eu.ozco.in' * About to connect() to proxy <proxy name> port 8080 (#0) * Trying <proxy ip>... * TCP_NODELAY set * connected * Connected to <proxy name> <proxy ip> port 8080 (#0) * Server auth using Basic with user 'pontius.X' > POST http://eu.ozco.in HTTP/1.1 Authorization: Basic xxxxxx Host: eu.ozco.in Accept-Encoding: deflate, gzip Proxy-Connection: Keep-Alive Content-Type: application/json Content-Length: 45 User-Agent: cpuminer 2.2.1 X-Mining-Extensions: midstate
* Operation timed out after 30001 milliseconds with 0 bytes received * Closing connection #0 [2012-06-06 14:44:27] HTTP request failed: necessary data rewind wasn't possible [2012-06-06 14:44:27] json_rpc_call failed, retry after 30 seconds [2012-06-06 14:44:57] JSON protocol request: {"method": "getwork", "params": [], "id":0} This one looks like a proxy issue. But if so why is this only with cpuminer?
|
|
|
|
pooler (OP)
|
|
June 06, 2012, 07:06:15 PM |
|
Pontius: regarding 503 errors, they must be generated by the proxy you're connecting through. I contacted p2k, the author of the ecoinpool software used by OzCoin, and he said that under no circumstance the server emits 503 errors. This one looks like a proxy issue. But if so why is this only with cpuminer?
That is the question. Just for testing, I tried mining against eu.ozco.in through a public proxy server for a few hours, but I got no errors. At this point I wonder if this is an issue with the particular proxy you're connecting to. Is it a public one, or is there any way I could connect to it to do some direct testing?
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
Pontius
|
|
June 07, 2012, 05:55:45 AM |
|
Oh, sorry for the confusion, I guess I forgot to mention that the 503 only occur while mining with MaxBTC. Here's a dump with HTTP/503: * Re-using existing connection! (#0) with host <proxy name> * Connected to <proxy name> (<proxy ip>) port 8080 (#0) * Server auth using Basic with user 'pontius-X' > POST http://pool.maxbtc.com HTTP/1.1 Authorization: Basic xxxxxxx Host: pool.maxbtc.com Accept-Encoding: deflate, gzip Proxy-Connection: Keep-Alive Content-Type: application/json Content-Length: 45 User-Agent: cpuminer 2.2.1 X-Mining-Extensions: midstate
< HTTP/1.1 200 ok < Content-Type: application/json < X-Long-Polling: /LP < X-Roll-NTime: Y < Date: Thu, 07 Jun 2012 05:42:29 GMT < Cache-Control: proxy-revalidate < Content-Length: 591 < Proxy-Connection: Keep-Alive < Connection: Keep-Alive < * Connection #0 to host <proxy name> left intact [2012-06-07 07:42:29] JSON protocol response: { "id": 0, "result": { "target": "000000000000000000000000000000000000000000000000ffffffff00000000", "midstate": "9fa7831e50c9e43a92f2aaa7e86cbf2d62836150ac678514ab5d31a9838a633d", "hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010 000", "data": "00000001407cc21cd077099d5c944dbce6384bf58e2c129d23a490d20000043100000000cbc3af0622980995aa5f88581cea83e60ba4774cb8cfd331f92d6b 176d23ae834fd03f3e1a0a8b5f00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000" }, "error": null } * The requested URL returned error: 503 * Closing connection #0 [2012-06-07 07:42:30] HTTP request failed: The requested URL returned error: 503 [2012-06-07 07:42:30] JSON protocol request: {"method": "getwork", "params": [], "id":0}
About the proxy - it is a NetCache NetApp/6.0.5 and is non-public, no chance for you to use it.
|
|
|
|
pooler (OP)
|
|
June 07, 2012, 10:57:26 AM |
|
Pontius, have you tried disabling long polling to see if you still get the same kind of errors?
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
Pontius
|
|
June 07, 2012, 02:12:09 PM |
|
Pontius, have you tried disabling long polling to see if you still get the same kind of errors?
Running with "--no-longpoll" gives no HTTP errors at all. But also no shares (neither valid or invalid but zero shares, even when playing with the scantime).
|
|
|
|
pooler (OP)
|
|
June 07, 2012, 07:08:16 PM |
|
Running with "--no-longpoll" gives no HTTP errors at all. But also no shares (neither valid or invalid but zero shares, even when playing with the scantime).
That is the strangest thing of all, and even though I tried I cannot reproduce the problem. With or without long polling, with or without a proxy, I always get shares. It is possible that some of the shares are detected to be stale and are not submitted, but unless the server (or the proxy) is very slow to respond that shouldn't happen frequently. Try using the -D option to see if that is the case. Now, let me try to make a list of the various errors that have been reported. HTTP request failed: The requested URL returned error: 503
I tried mining at MaxBTC for a couple hours, but I was unable to reproduce the problem. I'll keep trying. HTTP request failed: Recv failure: Connection reset by peer
If we are to believe libcurl, this means that the connection was closed by the remote server. I don't think there's much the miner can do to avoid the error, apart from silently ignoring it. Maybe I should consider doing that for the long polling connection? HTTP request failed: necessary data rewind wasn't possible
Under "normal" conditions, data rewind shouldn't be needed: it is usually only necessary for resuming interrupted uploads or for multi-pass authentication. I suppose the "Operation timed out after 30001 milliseconds with 0 bytes received" error is linked to this. Implementing data rewind is pretty simple in our case, and cannot do any harm, so I will try to implement it and see if anything changes.
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
pooler (OP)
|
|
June 07, 2012, 09:11:44 PM |
|
Version 2.2.2- Modest speedups for all x86-64 processors, ranging in most cases from 1% to 3%; about 4% for AMD K8, and about 8% for Intel Atom.
- On Windows, thread priority is now set instead of process priority. This should solve most problems concerning system responsiveness.
- scrypt is now about 12% faster on ARM11.
- Fixed a bug that only made one CPU core accessible on Android.
- A new option (--background) is available to start minerd as a daemon on *nix systems.
The source code is, as always, available at GitHub. Windows binaries are available here. Please note that I have updated DLLs to the latest version of libcurl; older DLLs are no longer needed. Thanks go to guruvan, xurious and aaa801!
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
bulanula
|
|
June 07, 2012, 10:58:13 PM |
|
Version 2.2.2- Modest speedups for all x86-64 processors, ranging in most cases from 1% to 3%; about 4% for AMD K8, and about 8% for Intel Atom.
- On Windows, thread priority is now set instead of process priority. This should solve most problems concerning system responsiveness.
- scrypt is now about 12% faster on ARM11.
- Fixed a bug that only made one CPU core accessible on Android.
- A new option (--background) is available to start minerd as a daemon on *nix systems.
The source code is, as always, available at GitHub. Windows binaries are available here. Please note that I have updated DLLs to the latest version of libcurl; older DLLs are no longer needed. Thanks go to guruvan, xurious and aaa801! Will those speedups be visible while running on a 32 bit OS underneath ? In summary, any benefit upgrading to this version for mostly Intel 64 bit CPUs running on 32 bit Windows OSes ? Thanks !
|
|
|
|
pooler (OP)
|
|
June 07, 2012, 11:03:50 PM Last edit: June 07, 2012, 11:14:55 PM by pooler |
|
Will those speedups be visible while running on a 32 bit OS underneath ?
The short answer is: only for Intel Atom. Other CPUs running in 32-bit mode shouldn't see any significant difference in performance. Nevertheless, all Windows users are encouraged to upgrade, because of point #2 above: - On Windows, thread priority is now set instead of process priority. This should solve most problems concerning system responsiveness.
|
BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
|
|
|
Phraust
Full Member
Offline
Activity: 206
Merit: 100
Mostly Harmless...
|
|
June 08, 2012, 06:42:48 AM Last edit: June 08, 2012, 09:19:32 AM by Phraust |
|
Just compiled a version for OSX if anyone wants it: http://bitcoin.phraust.com/CPUMINER-2.2.2-OSX.zip**EDIT** Been running it for about 15 minutes now, it's running about 2-3 khps faster! yay! **EDIT-EDIT** With some help from pooler, I've recompiled it with the AVX instruction set, so it's even faster (was 2.4 kh per thread, now it's 3.7!!)
|
|
|
|
stoppots
|
|
June 09, 2012, 12:23:28 PM |
|
Version 2.2.2- On Windows, thread priority is now set instead of process priority. This should solve most problems concerning system responsiveness.
Would this change have any effect on a single GPU dedicated miner running win7. Would a certain number of threads be recommended to ensure the GPU miners performance is never degraded or interfered with? Currently on a quadcore I dedicate core #3 to phoenix and then allow minerd cores 0,1,2 for mining either litecoin or bitcoin. Anyone have any opinions on a more optimum setting?
|
|
|
|
bitcoinraffle.co
Member
Offline
Activity: 80
Merit: 10
BitcoinRaffle.co
|
|
June 10, 2012, 01:43:00 AM |
|
I'm getting this error on OS X: dyld: Library not loaded: /opt/local/lib/libidn.11.dylib Referenced from: /Users/longdongsilver/./minerd Reason: image not found Trace/BPT trap: 5
|
|
|
|
Phraust
Full Member
Offline
Activity: 206
Merit: 100
Mostly Harmless...
|
|
June 10, 2012, 09:36:59 AM |
|
I'm getting this error on OS X:
dyld: Library not loaded: /opt/local/lib/libidn.11.dylib Referenced from: /Users/longdongsilver/./minerd Reason: image not found Trace/BPT trap: 5
Are you using macports?
|
|
|
|
|