Bitcoin Forum
September 27, 2016, 10:20:50 PM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 »
  Print  
Author Topic: DiabloMiner GPU Miner  (Read 792488 times)
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
July 06, 2011, 02:59:52 PM
 #821

Thanks a bunch, this should significantly reduce the amount of stales I get! Grin

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
1475014850
Hero Member
*
Offline Offline

Posts: 1475014850

View Profile Personal Message (Offline)

Ignore
1475014850
Reply with quote  #2

1475014850
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475014850
Hero Member
*
Offline Offline

Posts: 1475014850

View Profile Personal Message (Offline)

Ignore
1475014850
Reply with quote  #2

1475014850
Report to moderator
1475014850
Hero Member
*
Offline Offline

Posts: 1475014850

View Profile Personal Message (Offline)

Ignore
1475014850
Reply with quote  #2

1475014850
Report to moderator
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
July 06, 2011, 08:59:12 PM
 #822

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.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 07, 2011, 01:58:17 AM
 #823

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
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
July 07, 2011, 09:37:01 AM
 #824

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).

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 07, 2011, 11:34:59 AM
 #825

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.

Quote
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
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
July 07, 2011, 04:02:59 PM
 #826

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.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 07, 2011, 05:02:37 PM
 #827

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
Member
**
Offline Offline

Activity: 78


View Profile
July 07, 2011, 06:41:07 PM
 #828

Backup pool option would be great right now. Stupid DDoS!
SkipDaShu
Newbie
*
Offline Offline

Activity: 27


mini me


View Profile WWW
July 07, 2011, 07:55:39 PM
 #829

Backup pool option would be great right now. Stupid DDoS!
  Yea, go borrow the code from Hashkill ;-)

- da shu @ HeliOS (http://www.heliosinitiative.org/),
"A child's exposure to technology should never be predicated on an ability to afford it."
Druas
Member
**
Offline Offline

Activity: 78


View Profile
July 08, 2011, 07:11:06 AM
 #830

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
Newbie
*
Offline Offline

Activity: 27


View Profile WWW
July 09, 2011, 01:56:50 AM
 #831

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
Member
**
Offline Offline

Activity: 84


View Profile
July 09, 2011, 02:10:32 AM
 #832

@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
Member
**
Offline Offline

Activity: 90


View Profile
July 09, 2011, 02:32:24 AM
 #833

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
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 09, 2011, 04:15:02 AM
 #834

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
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 09, 2011, 04:16:29 AM
 #835

@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
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 09, 2011, 04:18:40 AM
 #836

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
Member
**
Offline Offline

Activity: 90


View Profile
July 09, 2011, 04:27:53 AM
 #837

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
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 09, 2011, 05:36:02 AM
 #838

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
Newbie
*
Offline Offline

Activity: 27


View Profile WWW
July 09, 2011, 10:00:22 AM
 #839

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
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
July 09, 2011, 11:14:17 AM
 #840

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!