Topic: DiabloMiner GPU Miner - page 46. (Read 866596 times)
It seems to be using both pools I put in, roughly equally. I was expecting it to be failover (or is btcmine just failing a lot?)
-u username -p password -o us.btcguild.com, pit.deepbit.net -r 8332 -v 2 -w 128 -f1
or
-u username1, username2 -p password1, password2 -o us.btcguild.com, pit.deepbit.net -r 8332, 8332 -v 2, 2 -w 128, 128 -f 1, 1
Only commas, no spaces after the commas since the command line would interpret everything after those as a new parameter.or
-u username1, username2 -p password1, password2 -o us.btcguild.com, pit.deepbit.net -r 8332, 8332 -v 2, 2 -w 128, 128 -f 1, 1
Code:
-u username1,username2 -p password1,password2 -o us.btcguild.com,pit.deepbit.net -r 8332,8332 -v 2 -w 128 -f 1
-u username -p password -o us.btcguild.com, pit.deepbit.net -r 8332 -v 2 -w 128 -f1
or
-u username1, username2 -p password1, password2 -o us.btcguild.com, pit.deepbit.net -r 8332, 8332 -v 2, 2 -w 128, 128 -f 1, 1
Only commas, no spaces after the commas since the command line would interpret everything after those as a new parameter.or
-u username1, username2 -p password1, password2 -o us.btcguild.com, pit.deepbit.net -r 8332, 8332 -v 2, 2 -w 128, 128 -f 1, 1
-u username -p password -o us.btcguild.com, pit.deepbit.net -r 8332 -v 2 -w 128 -f1
or
-u username1, username2 -p password1, password2 -o us.btcguild.com, pit.deepbit.net -r 8332, 8332 -v 2, 2 -w 128, 128 -f 1, 1
Only commas, no spaces after the commas since the command line would interpret everything after those as a new parameter. or
-u username1, username2 -p password1, password2 -o us.btcguild.com, pit.deepbit.net -r 8332, 8332 -v 2, 2 -w 128, 128 -f 1, 1
Update: Multiple pool support, use commas
So is this the backup pool option? If the information is the same do we still have to retype it? What about port number and all the settings? I guess my question is if all we want is to enter a new backup pool (sometimes I even have same username and password) is that the only thing we have to put a comma for? I know this is kind of a dumb question, but I think in order to test it I would have to have my primary pool go down to see if secondary kicks in, which I am not in control of and not fond of having happen. Also, if primary goes down and it switches to secondary will it just keep going on secondary even if primary comes back? If secondary goes down will it try primary again?-u username -p password -o us.btcguild.com, pit.deepbit.net -r 8332 -v 2 -w 128 -f1
or
-u username1, username2 -p password1, password2 -o us.btcguild.com, pit.deepbit.net -r 8332, 8332 -v 2, 2 -w 128, 128 -f 1, 1
I just got this log, but it is the first time out of ~5 runs that this happened. I suspect that it is because deepbit kept timing out and one of the executions was null when the LP response came in.
EDIT:
It just happened again, same situation, similar log.
Code:
[11.07.11 20:22:54] Started
[11.07.11 20:22:54] Connecting to: http://pit.deepbit.net:8332/, http://swepool.net:8337/
[11.07.11 20:22:55] Using Apple OpenCL 1.0 (Dec 23 2010 17:30:26)
[11.07.11 20:22:55] Added GeForce 9400 (#1) (2 CU, local work size of 128)
[11.07.11 20:22:56] DEBUG: swepool.net: Enabling long poll support
[11.07.11 20:22:56] DEBUG: swepool.net: Enabling roll ntime support
[11.07.11 20:23:24] ERROR: Cannot connect to pit.deepbit.net: connect timed out
[11.07.11 20:23:38] DEBUG: swepool.net: Long poll returned
Exception in thread "DiabloMiner LongPollAsync for swepool.net" java.lang.NullPointerException
at com.diablominer.DiabloMiner.DiabloMiner.forceUpdate(DiabloMiner.java:536)
at com.diablominer.DiabloMiner.DiabloMiner$NetworkState$LongPollAsync.run(DiabloMiner.java:919)
at java.lang.Thread.run(Thread.java:680)
[11.07.11 20:23:55] ERROR: Cannot connect to pit.deepbit.net: connect timed out
[11.07.11 20:24:27] ERROR: Cannot connect to pit.deepbit.net: connect timed out
[11.07.11 20:24:58] ERROR: Cannot connect to pit.deepbit.net: connect timed out
EDIT:
It just happened again, same situation, similar log.
You can post completely arbitrary data, and it will still respond with a JSON-RPC response. Or you can post nothing. It is clearly not JSON-RPC.
Probably a case of "be strict in what you send, but generous in what you receive". And good practice too for some piece of pool software, considering there are so many ways to interpret the LP spec. The LP spec doesn't say "the LP request is not a JSON RPC request" explicitly. If it did, then, yes, I could get away with doing GET. Receiving a JSON RPC response is questionable at best in the case that this is true (although normal JSON over HTTP obviously is GETtable).
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
I agree. It's not much of a spec. It's more like, 5 half-assed written paragraphs. But that's fine. We do with it what we can.
Perhaps the problem is you shouldn't consider LP as JSON-RPC. Maybe it's not. After all, if it was, it would not specifically mention GET. It's just a hack. I don't see any other way to interpret it. It's a GET request whose response is a JSON-RPC method response packet, completely outside of the normal JSON-RPC flow.
It should also be noted that no matter what you POST to it, it works. You can post completely arbitrary data, and it will still respond with a JSON-RPC response. Or you can post nothing. It is clearly not JSON-RPC.
Update: Fix up the X-Switch-To code
Update: Multiple pool support, use commas
You initialise the networkStates array with a length of 0 if the url command line option is not used, resulting in an ArrayIndexOutOfBoundsException on line 427:Code:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:427)
at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:133)
Code:
-dd -o "swepool.net" -r 8337 -p "mypwd" -u "myuser" -w 128
Code:
Exception in thread "DiabloMiner GetWorkAsync for swepool.net" java.lang.NullPointerException
at java.io.StringReader.(StringReader.java:33)
at org.codehaus.jackson.JsonFactory.createJsonParser(JsonFactory.java:427)
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1285)
at org.codehaus.jackson.map.ObjectMapper.readTree(ObjectMapper.java:1007)
at com.diablominer.DiabloMiner.DiabloMiner$NetworkState.doJSONRPC(DiabloMiner.java:688)
at com.diablominer.DiabloMiner.DiabloMiner$NetworkState$GetWorkAsync.run(DiabloMiner.java:815)
at java.lang.Thread.run(Thread.java:680)
A little more testing without the url option might be in order...
... shit. I know exactly what I did too.
Note to self: Don't code for a few hours, then release it.
Update: Fixed the obvious bug.
Update: Multiple pool support, use commas
You initialise the networkStates array with a length of 0 if the url command line option is not used, resulting in an ArrayIndexOutOfBoundsException on line 427:Code:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:427)
at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:133)
Code:
-dd -o "swepool.net" -r 8337 -p "mypwd" -u "myuser" -w 128
Code:
Exception in thread "DiabloMiner GetWorkAsync for swepool.net" java.lang.NullPointerException
at java.io.StringReader.(StringReader.java:33)
at org.codehaus.jackson.JsonFactory.createJsonParser(JsonFactory.java:427)
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1285)
at org.codehaus.jackson.map.ObjectMapper.readTree(ObjectMapper.java:1007)
at com.diablominer.DiabloMiner.DiabloMiner$NetworkState.doJSONRPC(DiabloMiner.java:688)
at com.diablominer.DiabloMiner.DiabloMiner$NetworkState$GetWorkAsync.run(DiabloMiner.java:815)
at java.lang.Thread.run(Thread.java:680)
A little more testing without the url option might be in order...
The LP spec doesn't say "the LP request is not a JSON RPC request" explicitly. If it did, then, yes, I could get away with doing GET. Receiving a JSON RPC response is questionable at best in the case that this is true (although normal JSON over HTTP obviously is GETtable).
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
Agreed, this would be questionable at best. The JSON-RPC spec clearly states "A response may only be sent in reply to a request." Just to see what happens, I modified the miner to actually use GET without a request body on the LP connection. The response from pushpool is still a JSON-RPC response, just as if it had received the request:
Code:
GET /LP HTTP/1.1
Authorization: Basic a2FvX2dwdTpmUjMzbDAwN3I=
Accept-Encoding: gzip,deflate
Content-Type: application/json
Cache-Control: no-cache
User-Agent: Java/1.6.0_26
Host: pit.x8s.de:8337
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
HTTP/1.1 200 ok
Content-Type: application/json
X-Roll-NTime: Y
Date: Mon, 11 Jul 2011 11:54:01 GMT
Content-Length: 591
{"id":1,"error":null,"result":{"midstate":"d3eed22cc5909d76ac118412da850d8dfabc49687f1674fbcc73cecc45166cbd","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"00000001faca27b55e2524d24df3ab7ef9392b5c85a11bb006de813b000001d00000000035940bd70e45c1e87c69af951db0705d893945dda73c0202ad691730070e15044e1ae4571a0abbcf00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
Bottom line: It seems that pools really don't care one way or another. So let's stick with proper JSON-RPC.
Update: Multiple pool support, use commas
Quote
3) Miner starts a request to long polling URL with GET
So yes "" does make sense because the pool can just check wether it's a GET or POST request...
ANY client that EVER uses GET for JSON RPC is wrong. Read the HTTP spec, GETs should never have message bodies. DiabloMiner follows the HTTP specification and uses POST for all requests.
If you want LP to work, it must be a unique URL.
Try running DM with -dd, you'll see a matching flood of LP returned messages because your server is not holding the LP request open correctly.
Could you at least try reading my whole post? This has nothing todo with longpoll anymore because i implemented it differently...
proff:
Print the responses to those requests including the HTTP status codes.
Quote
ANY client that EVER uses GET for JSON RPC is wrong. Read the HTTP spec, GETs should never have message bodies. DiabloMiner follows the HTTP specification and uses POST for all requests.
You are correct regarding the HTTP spec, of course. The LP specification is rather ambiguous at this point. However, a GET would actually make sense when the reply is a JSON-RPC notification (id: null). Then the procedure would be like this:
- The client does a simple GET on the LP URL, indicating its interest in "interruption" by notification
- Once the network finds a new block, the server replies with the fresh hash, as if the client just issued a getwork request
- The client aborts/discards the obsolete calculation and starts on the received fresh one - no need for a getwork on the main connection!
- The client re-reisters for "interruption" by starting again with the first GET step.
Of course this is just my interpretation of the LP spec. But it seems that at least poclbm agrees with me, from a quick glance at the sources.
Anyway, thanks for this nice piece of software, keep up the good work!
The LP spec doesn't say "the LP request is not a JSON RPC request" explicitly. If it did, then, yes, I could get away with doing GET. Receiving a JSON RPC response is questionable at best in the case that this is true (although normal JSON over HTTP obviously is GETtable).
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
Quote
Something is extremely wrong with OSX. Its saying its executing kernels, but then not, and then doesn't emit any errors.
DM will wildly spin like that when kernels take zero time to execute. Problem is, the implementation MUST emit errors.
I so very much hate OSX.
DM will wildly spin like that when kernels take zero time to execute. Problem is, the implementation MUST emit errors.
I so very much hate OSX.
Well, yeah, OSX is special. I am experiencing the same problem with the master of DiabloMiner. Strangely enough, a previous version (the one packaged as a Mac App) works nicely! Playing around a bit, I found the problem seems to have occurred between these git commits:
Quote
commit 354b53286af2e982e5c8aa030784a785ebc5032b
Date: Sat Jun 25 02:17:14 2011 -0400
Switched to an unholy union of the current kernel and phatk. Dear Lord,
forgive me for I have sinned.
commit 2d0ed8523c17d011ae5e755936baab01becab171
Date: Fri Jun 24 01:22:45 2011 -0400
Move execution threads to 2 down from 3 since getwork can no longer
block execution threads
Date: Sat Jun 25 02:17:14 2011 -0400
Switched to an unholy union of the current kernel and phatk. Dear Lord,
forgive me for I have sinned.
commit 2d0ed8523c17d011ae5e755936baab01becab171
Date: Fri Jun 24 01:22:45 2011 -0400
Move execution threads to 2 down from 3 since getwork can no longer
block execution threads
I branched from the "pre-phatk" checkout and patched all later non-kernel changes into it. Works great!
So the new kernel must at least be part of the issue. Figures, poclbm with phatk actually freezes my WindowServer, grrr.
But you're right, OSX really should do a better job at error reporting. With the way it behaves now, I have no idea how to fix this.
Oh well, praise git. I'll stick with my branch for now.
Quote
ANY client that EVER uses GET for JSON RPC is wrong. Read the HTTP spec, GETs should never have message bodies. DiabloMiner follows the HTTP specification and uses POST for all requests.
You are correct regarding the HTTP spec, of course. The LP specification is rather ambiguous at this point. However, a GET would actually make sense when the reply is a JSON-RPC notification (id: null). Then the procedure would be like this:
- The client does a simple GET on the LP URL, indicating its interest in "interruption" by notification
- Once the network finds a new block, the server replies with the fresh hash, as if the client just issued a getwork request
- The client aborts/discards the obsolete calculation and starts on the received fresh one - no need for a getwork on the main connection!
- The client re-reisters for "interruption" by starting again with the first GET step.
Of course this is just my interpretation of the LP spec. But it seems that at least poclbm agrees with me, from a quick glance at the sources.
Anyway, thanks for this nice piece of software, keep up the good work!
This is indeed the same interpretation i had of it, which Phoenix also seems to follow... The GET request is indeed without a body so one might even be bold enough say to DiabloD3 that phoenix implements it correctly
Quote
ANY client that EVER uses GET for JSON RPC is wrong. Read the HTTP spec, GETs should never have message bodies. DiabloMiner follows the HTTP specification and uses POST for all requests.
You are correct regarding the HTTP spec, of course. The LP specification is rather ambiguous at this point. However, a GET would actually make sense when the reply is a JSON-RPC notification (id: null). Then the procedure would be like this:
- The client does a simple GET on the LP URL, indicating its interest in "interruption" by notification
- Once the network finds a new block, the server replies with the fresh hash, as if the client just issued a getwork request
- The client aborts/discards the obsolete calculation and starts on the received fresh one - no need for a getwork on the main connection!
- The client re-reisters for "interruption" by starting again with the first GET step.
Of course this is just my interpretation of the LP spec. But it seems that at least poclbm agrees with me, from a quick glance at the sources.
Anyway, thanks for this nice piece of software, keep up the good work!
Quote
3) Miner starts a request to long polling URL with GET
So yes "" does make sense because the pool can just check wether it's a GET or POST request...
ANY client that EVER uses GET for JSON RPC is wrong. Read the HTTP spec, GETs should never have message bodies. DiabloMiner follows the HTTP specification and uses POST for all requests.
If you want LP to work, it must be a unique URL.
Try running DM with -dd, you'll see a matching flood of LP returned messages because your server is not holding the LP request open correctly.
Could you at least try reading my whole post? This has nothing todo with longpoll anymore because i implemented it differently...
proff:
From deepbit: Miner starts a request to long polling URL with GET method and same basic authorization as on main connection.
It does not specify whether there is a body. I should note, that I do not use a body, and it works fine, with every pool I've seen. If it does expect a body, it is a contradictory spec, as you said.
It does not specify whether there is a body. I should note, that I do not use a body, and it works fine, with every pool I've seen. If it does expect a body, it is a contradictory spec, as you said.
Jump to: