DiabloMiner GPU Miner

[ancow]

I just had a look at the code, and you're only having the connection attempt time out, not the connection itself. This patch solves my problem:

Code:

--- DiabloMiner-git/src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java  2011-07-06 16:43:07.344491654 +0200
+++ DiabloMiner_build/src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java        2011-07-06 22:54:21.861192261 +0200
@@ -1104,9 +1104,14 @@
         connection = (HttpURLConnection) bitcoind.openConnection(proxy);
 
       if(timeout)
+      {
         connection.setConnectTimeout(15000);
+      }
       else
+      {
         connection.setConnectTimeout(10 * 60 * 1000);
+        connection.setReadTimeout(60 * 60 * 1000);
+      }

I deliberately set the timeout to an hour so that the amount of false alarms stays low. You may want to implement a lower read timeout, I'm not sure what a decent limit is.

[DiabloD3]

I just had a look at the code, and you're only having the connection attempt time out, not the connection itself. This patch solves my problem:

Code:

--- DiabloMiner-git/src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java  2011-07-06 16:43:07.344491654 +0200
+++ DiabloMiner_build/src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java        2011-07-06 22:54:21.861192261 +0200
@@ -1104,9 +1104,14 @@
         connection = (HttpURLConnection) bitcoind.openConnection(proxy);
 
       if(timeout)
+      {
         connection.setConnectTimeout(15000);
+      }
       else
+      {
         connection.setConnectTimeout(10 * 60 * 1000);
+        connection.setReadTimeout(60 * 60 * 1000);
+      }

I deliberately set the timeout to an hour so that the amount of false alarms stays low. You may want to implement a lower read timeout, I'm not sure what a decent limit is.

Yeah, 60 minutes makes no sense. Bitcoin aims to create a new block every ten minutes. Generally, its closer to every 6 to 8. If 10 minutes have passed, and LP hasn't returned, its obvious we're most likely in a new block by now.

setReadTimeout doesn't seem to do what the javadocs says it does, at least, not from what I can see in the source. I'll look at it later.

[ancow]

Yeah, 60 minutes makes no sense. Bitcoin aims to create a new block every ten minutes. Generally, its closer to every 6 to 8. If 10 minutes have passed, and LP hasn't returned, its obvious we're most likely in a new block by now.

I'd say that 20 minutes makes more sense since the 10 minutes is supposed to be a statistical average, not some upper limit. It happens quite frequently (especially after a few quick blocks) that a longer block comes along to balance things out. OTOH I don't really see the harm in forcing more frequent updates.

setReadTimeout doesn't seem to do what the javadocs says it does, at least, not from what I can see in the source. I'll look at it later.

I haven't really looked at setReadTimeout's source, but it seems to be working fine, here. I have several "ERROR: Cannot connect to Bitcoin: Read timed out" messages in my log now, and after this, long polling messages start coming in again (that's one thing the 1 hour timeout is good for - I see with a high degree of certainty whether long polling stopped working).

[DiabloD3]

Yeah, 60 minutes makes no sense. Bitcoin aims to create a new block every ten minutes. Generally, its closer to every 6 to 8. If 10 minutes have passed, and LP hasn't returned, its obvious we're most likely in a new block by now.

I'd say that 20 minutes makes more sense since the 10 minutes is supposed to be a statistical average, not some upper limit. It happens quite frequently (especially after a few quick blocks) that a longer block comes along to balance things out. OTOH I don't really see the harm in forcing more frequent updates.

Yeah, its the lack of harm that I don't really see an issue with just making both 10. Or even 15. Extremely few blocks are past 15 from what I can tell. The worst case is the connection times out and we cause getworks early.

setReadTimeout doesn't seem to do what the javadocs says it does, at least, not from what I can see in the source. I'll look at it later.

I haven't really looked at setReadTimeout's source, but it seems to be working fine, here. I have several "ERROR: Cannot connect to Bitcoin: Read timed out" messages in my log now, and after this, long polling messages start coming in again (that's one thing the 1 hour timeout is good for - I see with a high degree of certainty whether long polling stopped working).

Ahh, now, thats the magic words I was looking for I think. I should add this to both timeout and no timeout.

Now, the somewhat interesting thing is, LP does not actually control when getworks happen. 100 mhash/sec causes nonce saturation in 45 seconds on a single getwork, and you have 2 getworks per GPU worked in parallel.

LP locking up due to network/pool stupidity only causes higher actual stale rates because LP isn't triggering getworks early. Any shares created until post-new block getwork are stale. It stops generating stales when the new getwork triggers.

[ancow]

Now, the somewhat interesting thing is, LP does not actually control when getworks happen. 100 mhash/sec causes nonce saturation in 45 seconds on a single getwork, and you have 2 getworks per GPU worked in parallel.

LP locking up due to network/pool stupidity only causes higher actual stale rates because LP isn't triggering getworks early. Any shares created until post-new block getwork are stale. It stops generating stales when the new getwork triggers.

I'm not sure I'm understanding this correctly - does this mean you don't use the LP response to update the current work? As I understood it, the LP response is the same thing as a normal getwork response and should be used as the current work, not trigger a new getwork request.

Anyway, not all the shares found after LP failure are rejected, only about 2/3 (which is annoyingly high, and probably caused both by my dodgy network connection and the low hashing speed). So normal getwork still works, that isn't a problem.

[DiabloD3]

Now, the somewhat interesting thing is, LP does not actually control when getworks happen. 100 mhash/sec causes nonce saturation in 45 seconds on a single getwork, and you have 2 getworks per GPU worked in parallel.

LP locking up due to network/pool stupidity only causes higher actual stale rates because LP isn't triggering getworks early. Any shares created until post-new block getwork are stale. It stops generating stales when the new getwork triggers.

I'm not sure I'm understanding this correctly - does this mean you don't use the LP response to update the current work? As I understood it, the LP response is the same thing as a normal getwork response and should be used as the current work, not trigger a new getwork request.

Anyway, not all the shares found after LP failure are rejected, only about 2/3 (which is annoyingly high, and probably caused both by my dodgy network connection and the low hashing speed). So normal getwork still works, that isn't a problem.

You're partly understanding it correctly. Look at the math I printed, a getwork lasts 45 seconds at 100 mhash/sec. There are 2 used per GPU. On my 5850@918, that is a getwork every 12 seconds on average (they come in groups of 2 every 24 seconds). An LP only causes a getwork up to 24 seconds early.

LP returns a getwork, it is reused, but that doesn't help the other threads. Thus, LP causes a getwork flush. Also, for my 5850, this also means I can only produce stales for up to 24 seconds. A terminally stuck LP thread will just cause spans of 24 seconds to be stale-happy. A block happens roughly every 8 minutes (although the network targets 10).

[Druas]

Backup pool option would be great right now. Stupid DDoS!

[SkipDaShu]

Backup pool option would be great right now. Stupid DDoS!

  Yea, go borrow the code from Hashkill ;-)

[Druas]

Backup pool option would be great right now. Stupid DDoS!

  Yea, go borrow the code from Hashkill ;-)

Or poclbm. And I don't really like poclbm.

[JaTochNietDan]

Code:

[09/07/11 02:54:24] Started
[09/07/11 02:54:24] Connecting to: http://api.bitcoin.cz:8332/
[09/07/11 02:54:24] Using ATI Stream OpenCL 1.0 ATI-Stream-v2.1 (145)
[09/07/11 02:54:33] BFI_INT patching enabled, disabling hardware checkin
[09/07/11 02:54:33] Added Cypress (#1) (18 CU, local work size of 256)
mhash: 0.0/0.0 | accept: 0 | reject: 0 | hw error: 0

Using Ubuntu 10.10 and a Sapphire HD 5850, it never seems to do any work, it just sits there?

Any ideas on what may be causing this problem?

[Zagitta]

@DiabloD3: I'm currently writing my own pool software and i was wondering if DiabloMiner conforms with the longpoll protocol description at https://deepbit.net/longpolling.php ? because currently my code works perfectly with Phoenix but Diablominer screws up:

Code:

[09-07-11 04:08:06] Started
[09-07-11 04:08:06] Connecting to: http://localhost:8000/
[09-07-11 04:08:06] Using AMD Accelerated Parallel Processing OpenCL 1.1 AMD-APP
-SDK-v2.4 (650.9)
[09-07-11 04:08:08] Added ATI RV770 (#2) (10 CU, local work size of 256)
[09-07-11 04:08:15] DEBUG: Enabling long poll support
[09-07-11 04:08:16] DEBUG: Long poll returned
[09-07-11 04:08:17] DEBUG: Long poll returned
[09-07-11 04:08:23] DEBUG: Long poll returned
[09-07-11 04:08:24] DEBUG: Long poll returned
[09-07-11 04:08:25] DEBUG: Long poll returned
[09-07-11 04:08:26] DEBUG: Long poll returned
[09-07-11 04:08:27] DEBUG: Long poll returned
[09-07-11 04:08:28] DEBUG: Long poll returned
[09-07-11 04:08:29] DEBUG: Long poll returned
[09-07-11 04:08:30] DEBUG: Long poll returned
[09-07-11 04:08:30] DEBUG: Long poll returned
[09-07-11 04:08:32] DEBUG: Long poll returned
[09-07-11 04:08:33] DEBUG: Long poll returned
mhash: 51,1/47,0 | a/r/hwe: 0/0/0 | ghash: 1,2 | fps: 29,8

I guess you're using the protocol differently because i never actually recieves any GET request from diablominer...
Could you prehaps give me the specifications you go by?

[toasty]

I read back for the last few pages and don't see anyone reporting this, if it's already been mentioned sorry!

I'm trying this on OS X 10.7, with both a 5870 and 5770 in the same Mac Pro. I know the Mac OpenCL implementation is pretty bad for this stuff, but I'm seeing something kinda weird with the latest binary.

It seems to think that my system is producing many ghash/sec. As awesome as this would be if it were true, I'm going to go out on a limb here and say something is wrong.

I get:

Code:

[7/8/11 9:25:31 PM] Using Apple OpenCL 1.1 (Jun 14 2011 23:31:14)            
[7/8/11 9:25:31 PM] Added ATI Radeon HD 5770 (#1) (10 CU, local work size of 256)
[7/8/11 9:25:32 PM] DEBUG: Enabling long poll support                        
[7/8/11 9:25:32 PM] Added ATI Radeon HD 5870 (#2) (20 CU, local work size of 256)

Followed by 3-10 "Forcing getwork update due to nonce saturation" messages per second. When I finally get it displaying stats, I see:

mhash: 16830.9/14640.1 | a/r/hwe: 0/0/0 | ghash: 223.2 612.6 | fps: 160.1

It does appear to be doing SOME work, since I'm getting occasional blocks accepted by the server, but not nearly enough for the speeds it thinks it's doing. The "ghash" counter seems to repeatedly jump in large movements, then go back to normal incrementing.

I've tried enabling just one card at a time, and the results are pretty much the same.  Anyone seen anything like this?

[DiabloD3]

Code:

[09/07/11 02:54:24] Started
[09/07/11 02:54:24] Connecting to: http://api.bitcoin.cz:8332/
[09/07/11 02:54:24] Using ATI Stream OpenCL 1.0 ATI-Stream-v2.1 (145)
[09/07/11 02:54:33] BFI_INT patching enabled, disabling hardware checkin
[09/07/11 02:54:33] Added Cypress (#1) (18 CU, local work size of 256)
mhash: 0.0/0.0 | accept: 0 | reject: 0 | hw error: 0

Using Ubuntu 10.10 and a Sapphire HD 5850, it never seems to do any work, it just sits there?

Any ideas on what may be causing this problem?

Yes, you used -D 0. I swear I'm going to add an error for that.

Do not use -D unless you want to exclude cards. DiabloMiner by default uses all cards.

[DiabloD3]

@DiabloD3: I'm currently writing my own pool software and i was wondering if DiabloMiner conforms with the longpoll protocol description at https://deepbit.net/longpolling.php ? because currently my code works perfectly with Phoenix but Diablominer screws up:

Code:

[09-07-11 04:08:06] Started
[09-07-11 04:08:06] Connecting to: http://localhost:8000/
[09-07-11 04:08:06] Using AMD Accelerated Parallel Processing OpenCL 1.1 AMD-APP
-SDK-v2.4 (650.9)
[09-07-11 04:08:08] Added ATI RV770 (#2) (10 CU, local work size of 256)
[09-07-11 04:08:15] DEBUG: Enabling long poll support
[09-07-11 04:08:16] DEBUG: Long poll returned
[09-07-11 04:08:17] DEBUG: Long poll returned
[09-07-11 04:08:23] DEBUG: Long poll returned
[09-07-11 04:08:24] DEBUG: Long poll returned
[09-07-11 04:08:25] DEBUG: Long poll returned
[09-07-11 04:08:26] DEBUG: Long poll returned
[09-07-11 04:08:27] DEBUG: Long poll returned
[09-07-11 04:08:28] DEBUG: Long poll returned
[09-07-11 04:08:29] DEBUG: Long poll returned
[09-07-11 04:08:30] DEBUG: Long poll returned
[09-07-11 04:08:30] DEBUG: Long poll returned
[09-07-11 04:08:32] DEBUG: Long poll returned
[09-07-11 04:08:33] DEBUG: Long poll returned
mhash: 51,1/47,0 | a/r/hwe: 0/0/0 | ghash: 1,2 | fps: 29,8

I guess you're using the protocol differently because i never actually recieves any GET request from diablominer...
Could you prehaps give me the specifications you go by?

I follow the URL RFC and the LP specification. What URL are you giving it in the LP header?

[DiabloD3]

I read back for the last few pages and don't see anyone reporting this, if it's already been mentioned sorry!

I'm trying this on OS X 10.7, with both a 5870 and 5770 in the same Mac Pro. I know the Mac OpenCL implementation is pretty bad for this stuff, but I'm seeing something kinda weird with the latest binary.

It seems to think that my system is producing many ghash/sec. As awesome as this would be if it were true, I'm going to go out on a limb here and say something is wrong.

I get:

Code:

[7/8/11 9:25:31 PM] Using Apple OpenCL 1.1 (Jun 14 2011 23:31:14)            
[7/8/11 9:25:31 PM] Added ATI Radeon HD 5770 (#1) (10 CU, local work size of 256)
[7/8/11 9:25:32 PM] DEBUG: Enabling long poll support                        
[7/8/11 9:25:32 PM] Added ATI Radeon HD 5870 (#2) (20 CU, local work size of 256)

Followed by 3-10 "Forcing getwork update due to nonce saturation" messages per second. When I finally get it displaying stats, I see:

mhash: 16830.9/14640.1 | a/r/hwe: 0/0/0 | ghash: 223.2 612.6 | fps: 160.1

It does appear to be doing SOME work, since I'm getting occasional blocks accepted by the server, but not nearly enough for the speeds it thinks it's doing. The "ghash" counter seems to repeatedly jump in large movements, then go back to normal incrementing.

I've tried enabling just one card at a time, and the results are pretty much the same.  Anyone seen anything like this?

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.

[toasty]

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.

Do you have access to a Mac? If not, would you like remote access to one to play with?

[DiabloD3]

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.

Do you have access to a Mac? If not, would you like remote access to one to play with?

I don't need access. OSX is not open source, so I can't fix it where it needs to be fixed, only Apple can.

[JaTochNietDan]

Code:

[09/07/11 02:54:24] Started
[09/07/11 02:54:24] Connecting to: http://api.bitcoin.cz:8332/
[09/07/11 02:54:24] Using ATI Stream OpenCL 1.0 ATI-Stream-v2.1 (145)
[09/07/11 02:54:33] BFI_INT patching enabled, disabling hardware checkin
[09/07/11 02:54:33] Added Cypress (#1) (18 CU, local work size of 256)
mhash: 0.0/0.0 | accept: 0 | reject: 0 | hw error: 0

Using Ubuntu 10.10 and a Sapphire HD 5850, it never seems to do any work, it just sits there?

Any ideas on what may be causing this problem?

Yes, you used -D 0. I swear I'm going to add an error for that.

Do not use -D unless you want to exclude cards. DiabloMiner by default uses all cards.

Actually I didn't, I used this exact command:

Code:

./DiabloMiner-YourOS.sh -u myuser -p mypass -o api.mining.cz

[DiabloD3]

Code:

[09/07/11 02:54:24] Started
[09/07/11 02:54:24] Connecting to: http://api.bitcoin.cz:8332/
[09/07/11 02:54:24] Using ATI Stream OpenCL 1.0 ATI-Stream-v2.1 (145)
[09/07/11 02:54:33] BFI_INT patching enabled, disabling hardware checkin
[09/07/11 02:54:33] Added Cypress (#1) (18 CU, local work size of 256)
mhash: 0.0/0.0 | accept: 0 | reject: 0 | hw error: 0

Using Ubuntu 10.10 and a Sapphire HD 5850, it never seems to do any work, it just sits there?

Any ideas on what may be causing this problem?

Yes, you used -D 0. I swear I'm going to add an error for that.

Do not use -D unless you want to exclude cards. DiabloMiner by default uses all cards.

Actually I didn't, I used this exact command:

Code:

./DiabloMiner-YourOS.sh -u myuser -p mypass -o api.mining.cz

Weird. The only way you can get that behavior is if slush's pool is accepting new connections but just stalling. Try a different pool.

[Zagitta]

@DiabloD3: I'm currently writing my own pool software and i was wondering if DiabloMiner conforms with the longpoll protocol description at https://deepbit.net/longpolling.php ? because currently my code works perfectly with Phoenix but Diablominer screws up:

Code:

[09-07-11 04:08:06] Started
[09-07-11 04:08:06] Connecting to: http://localhost:8000/
[09-07-11 04:08:06] Using AMD Accelerated Parallel Processing OpenCL 1.1 AMD-APP
-SDK-v2.4 (650.9)
[09-07-11 04:08:08] Added ATI RV770 (#2) (10 CU, local work size of 256)
[09-07-11 04:08:15] DEBUG: Enabling long poll support
[09-07-11 04:08:16] DEBUG: Long poll returned
[09-07-11 04:08:17] DEBUG: Long poll returned
[09-07-11 04:08:23] DEBUG: Long poll returned
[09-07-11 04:08:24] DEBUG: Long poll returned
[09-07-11 04:08:25] DEBUG: Long poll returned
[09-07-11 04:08:26] DEBUG: Long poll returned
[09-07-11 04:08:27] DEBUG: Long poll returned
[09-07-11 04:08:28] DEBUG: Long poll returned
[09-07-11 04:08:29] DEBUG: Long poll returned
[09-07-11 04:08:30] DEBUG: Long poll returned
[09-07-11 04:08:30] DEBUG: Long poll returned
[09-07-11 04:08:32] DEBUG: Long poll returned
[09-07-11 04:08:33] DEBUG: Long poll returned
mhash: 51,1/47,0 | a/r/hwe: 0/0/0 | ghash: 1,2 | fps: 29,8

I guess you're using the protocol differently because i never actually recieves any GET request from diablominer...
Could you prehaps give me the specifications you go by?

I follow the URL RFC and the LP specification. What URL are you giving it in the LP header?

Code:

response.AppendHeader("X-Long-Polling","");

AKA same URL but i guess it probably would be a good idea to add /LP just to avoid confusing miners But none the less i'm never getting a GET request which i technically should :p

Okay so i changed my code around a bit to use the incomming RawUrl as the determining factor for wether or not it's the LP request wich works fine for both phoenix and diablominer BUT diablominer starts spamming getwork requests after ~57 seconds @ 60-70 mhash/s
Any idea what that could be?