DiabloMiner GPU Miner

[GODLIKE]

Either you do not have OpenCL drivers installed, or your device does not support OpenCL.

Duh I didn't read anything about the need of OpenCL anywhere... it should be included with ATI drivers right? So it should be installed already.

[DiabloD3]

A dead giveaway of the bug is using -dd and seeing a ton of hardware check errors.

That's probably it!

Code:

[02.06.11 23:34:37] Added Barts (#1) (14 CU, local work size of 192)
[02.06.11 23:34:37] DEBUG: Enabling long poll support
[02.06.11 23:34:37] DEBUG: Enabling long poll support
[02.06.11 23:34:37] DEBUG: Enabling long poll support
[02.06.11 23:34:48] DEBUG: Attempt 1 found on Barts (#1)
[02.06.11 23:34:48] DEBUG: Invalid block found on Barts (#1), possible driver or hardware issue
[02.06.11 23:34:56] DEBUG: Attempt 2 found on Barts (#1)
[02.06.11 23:34:56] DEBUG: Invalid block found on Barts (#1), possible driver or hardware issue
[02.06.11 23:34:58] DEBUG: Attempt 3 found on Barts (#1)
[02.06.11 23:34:58] Block 1 found on Barts (#1)1
[02.06.11 23:35:15] DEBUG: Attempt 4 found on Barts (#1)
[02.06.11 23:35:15] Block 2 found on Barts (#1)6
[02.06.11 23:35:25] DEBUG: Attempt 5 found on Barts (#1)
[02.06.11 23:35:25] Block 3 found on Barts (#1),0
[02.06.11 23:35:26] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:35:26] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:35:26] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:36:13] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:36:13] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:36:13] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:36:15] DEBUG: Attempt 6 found on Barts (#1)
[02.06.11 23:36:16] Block 4 found on Barts (#1),4
[02.06.11 23:36:18] DEBUG: Attempt 7 found on Barts (#1)
[02.06.11 23:36:18] DEBUG: Invalid block found on Barts (#1), possible driver or hardware issue
[02.06.11 23:36:19] DEBUG: Attempt 8 found on Barts (#1)
[02.06.11 23:36:19] Block 5 found on Barts (#1),4
[02.06.11 23:36:29] DEBUG: Attempt 9 found on Barts (#1)
[02.06.11 23:36:29] DEBUG: Invalid block found on Barts (#1), possible driver or hardware issue
[02.06.11 23:36:50] DEBUG: Attempt 10 found on Barts (#1)
[02.06.11 23:36:50] Block 6 found on Barts (#1),9
[02.06.11 23:36:53] DEBUG: Attempt 11 found on Barts (#1)
[02.06.11 23:36:53] Block 7 found on Barts (#1),0
[02.06.11 23:36:53] DEBUG: Attempt 12 found on Barts (#1)
[02.06.11 23:36:53] Block 8 found on Barts (#1),0
[02.06.11 23:37:01] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:37:01] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:37:02] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:37:03] DEBUG: Attempt 13 found on Barts (#1)
[02.06.11 23:37:03] Block 9 found on Barts (#1),0
[02.06.11 23:37:25] DEBUG: Attempt 14 found on Barts (#1)
[02.06.11 23:37:25] DEBUG: Invalid block found on Barts (#1), possible driver or hardware issue
[02.06.11 23:37:37] DEBUG: Attempt 15 found on Barts (#1)
[02.06.11 23:37:38] Block 10 found on Barts (#1)8
[02.06.11 23:37:49] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:37:49] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:37:49] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:38:36] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:38:36] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:38:37] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:39:11] DEBUG: Attempt 16 found on Barts (#1)
[02.06.11 23:39:11] DEBUG: Invalid block found on Barts (#1), possible driver or hardware issue
[02.06.11 23:39:13] DEBUG: Attempt 17 found on Barts (#1)
[02.06.11 23:39:13] Block 11 found on Barts (#1)3
[02.06.11 23:39:23] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:39:24] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:39:25] DEBUG: Forcing getwork update due to nonce saturation
[02.06.11 23:39:30] DEBUG: Attempt 18 found on Barts (#1)
[02.06.11 23:39:30] Block 12 found on Barts (#1)4
[02.06.11 23:39:41] DEBUG: Attempt 19 found on Barts (#1)
[02.06.11 23:39:41] Block 13 found on Barts (#1)3
270047/269776 khash/sec | ghash: 82,0 | fps: 29,3^C

Now...

Code:

user@host:~/...../DiabloMiner$ git pull
Already up-to-date.

AFAIR, there were no updates since i cloned the repo from github yesterday. Even if there were, I just did a "mvn package" to recompile and still getting the hardware issue in my log. I hope I'm not doing it wrong.
Again, thanks for your support and fast miner.

Huh, interesting. You're getting them, yet the bug has been fixed, and I'm not aware of the bug ever showing on 2.4.

BTW, bfi_int with certain combinations of vector cause false positive hw errors, but otherwise do not touch the number of shares produced. At 270 mhash, you should be able to produce 50 shares in about 14 minutes.

If its the bug I'm thinking it is, then you will get 50 attempts, but not 50 shares. If its the bfi_int harmless driver bug, then you will get 50 shares, but way more than 50 attempts.

[Druas]

I am not exactly sure what version I had before, but I installed it on May 17. With that version I got about 33000 khash/s. However, the new one is struggling to get 29000 khash/s. Using AMD 6750M and going back to old version for now.

If you're using -v 2, try -v 3. If you're using -v 3, try -v 2.

Idk what is going on, but this newest version DID seem to work a little better. I was seeing about 37000 on -v 3 -w 128 after about 2 min of running it, then I stopped it to try a couple other configurations. -v 3 -w 128 is basically the only thing that works for me I think. Get invalid memory access errors now with -v 2, -v 19, even -v 3 -w 64,192,256. Worst part is when I started -v 3 -w 128 back up again after 2 min of running it only get 28000. Tried to get it to go back up, but no luck so, I guess I will go back to the older version. Macs suck at this.

[POPOEVER]

How can I turn off the autorun on bootup on my MBP? Can't find it in the autorun list

[whackedspinach]

I've been monitoring Bitcoin for a few months and finally decided to join in on the pooled mining.  After switching to the catalyst drivers (ugh), and installing OpenCL, I finally got DiabloMiner up and running.  I am currently using the following script to run it:

Code:

./DiabloMiner-Linux.sh --url http://user.worker:password@mining.bitcoin.cz:8332/ -v 2 -w 128 -D 1,2

My system contains 2 Radeon HD6850s connected by CrossFire. The hash meter is giving me around 190,000 khash/sec, which sounds really low compared to what I've seen around the forums.  I'm currently playing with the -f settings, but I've only gotten it up to about 200,000 (and it makes the computer completely unusable).  Am I doing something completly wrong or should this rate be expected?

[gentakin]

If its the bug I'm thinking it is, then you will get 50 attempts, but not 50 shares. If its the bfi_int harmless driver bug, then you will get 50 shares, but way more than 50 attempts.

So I started up diablo and after 14 minutes:
* 42 attempts
* 31 shares
* 273378/271347 khash/sec | ghash: 226,4

Not sure if this will help you track down what is going on with my setup. It looks like it's the "bad" bug, not the harmless bug. That would explain why the deepbit hashmeter never ever reached more than about 200mhash/s.
Maybe I'm just trying to get more out of my hardware than I should, thus really causing a "possible driver or hardware issue"?

edit: I also modified diablominer so it will send attempts even though H != 0, but that didn't work of course (ERROR: Connection failed: Bitcoin returned error message: Wrong data: checkWork: checkHash wrong).

[DiabloD3]

If its the bug I'm thinking it is, then you will get 50 attempts, but not 50 shares. If its the bfi_int harmless driver bug, then you will get 50 shares, but way more than 50 attempts.

So I started up diablo and after 14 minutes:
* 42 attempts
* 31 shares
* 273378/271347 khash/sec | ghash: 226,4

Not sure if this will help you track down what is going on with my setup. It looks like it's the "bad" bug, not the harmless bug. That would explain why the deepbit hashmeter never ever reached more than about 200mhash/s.
Maybe I'm just trying to get more out of my hardware than I should, thus really causing a "possible driver or hardware issue"?

edit: I also modified diablominer so it will send attempts even though H != 0, but that didn't work of course (ERROR: Connection failed: Bitcoin returned error message: Wrong data: checkWork: checkHash wrong).

Let me repeat: the Deepbit hashmeter is useless. It does not reflect anything useful. I've had it say I'm doing 500 mhash consistently for about an hour, and I do around 300.

And yes, don't try to send failed hashes. Not a good idea.

42 attempts producing 31 shares honestly sounds like the hardware is overheating or your machine is unstable. As long as your GPU temp is below 85c, this shouldn't happen unless the card sucks (say, Powercolor,  Diamond, non-reference XFX, etc) or your PSU can't handle the load.

I cannot reproduce this bug.

[melanarchy]

So I've been mining with phoenix and phatk and I get 299Mhash/sec pretty consistently (VECTORS BFI_INT AGGRESSION=12 WORKSIZE=128).  I tried Diablo and it lets me push it up to around 304Mhash/sec (-v 19 -w 192) (Headless linux miner, 6870 1000MHz core 920Mhz memory). That does seem higher, but with phoneix I get an average of 98% accepted blocks where as with Diablo I'm seeing 90% accepted or below.  That's a big difference. I'd love the 5 Mhash/sec more, but the drop in efficiency makes my actual throughput  lower.

Any suggestions?

[DiabloD3]

So I've been mining with phoenix and phatk and I get 299Mhash/sec pretty consistently (VECTORS BFI_INT AGGRESSION=12 WORKSIZE=128).  I tried Diablo and it lets me push it up to around 304Mhash/sec (-v 19 -w 192) (Headless linux miner, 6870 1000MHz core 920Mhz memory). That does seem higher, but with phoneix I get an average of 98% accepted blocks where as with Diablo I'm seeing 90% accepted or below.  That's a big difference. I'd love the 5 Mhash/sec more, but the drop in efficiency makes my actual throughput  lower.

Any suggestions?

Like I've said to others, I believe there is either a widespread bug in how some pools operate (such as giving the wrong diff target out, or incorrectly checking hashes (such as H == 0 only instead of also G <= target)), or Pheonix is incorrectly reporting that shares have been accepted when they haven't.

For me, on Deepbit, I get two or three stale shares for every 1000 give or take.

[melanarchy]

Okay I'll try Diablo with a smaller pool that has been more reliable for me in the past and let you know if that helps.

Like I've said to others, I believe there is either a widespread bug in how some pools operate (such as giving the wrong diff target out, or incorrectly checking hashes (such as H == 0 only instead of also G <= target)), or Pheonix is incorrectly reporting that shares have been accepted when they haven't.

For me, on Deepbit, I get two or three stale shares for every 1000 give or take.

[GODLIKE]

Either you do not have OpenCL drivers installed, or your device does not support OpenCL.

Duh I didn't read anything about the need of OpenCL anywhere... it should be included with ATI drivers right? So it should be installed already.

Nonetheless, it's not workin, what should I do?

[nyargh]

I cannot reproduce this bug.

That's fine, there are other miners.

[DiabloD3]

Either you do not have OpenCL drivers installed, or your device does not support OpenCL.

Duh I didn't read anything about the need of OpenCL anywhere... it should be included with ATI drivers right? So it should be installed already.

Nonetheless, it's not workin, what should I do?

If you're on Windows, and have installed a recent version of Catalyst (11.4 and up), it installs the OpenCL runtime unless you tell it not to.

What hardware do you have?

[DiabloD3]

I cannot reproduce this bug.

That's fine, there are other miners.

Well, if the bug happens to be on the pool side (ie, pools are not properly checking hashes), then not only is that exploitable, it would be blocked by the pool software I'm writing (which checks share validity fully).

If the bug IS in my miner, I would love to find out what exactly triggers it so I can fix it, but I just don't think it is.

[DiabloD3]

Using the log vonshmitt sent me, the people suffering from this bug are losing about 1/3rd shares (rejected and accepted combined).

I wonder if I missed additional bugs in mtrlt's patch.

Edit: double fuck, its doing it here too.

[organofcorti]

Edit: double fuck, its doing it here too.

No bug for me using DM dl'd on 31-5. I'm on LinuxCoin, AMD APP SDK v2.4, ATI catalyst & drivers 11.3 and one solitary 6990. I get arouns 700000Mhps which is similar to what Eligius is giving me:

Code:

This user has submitted 1,716 shares in the last 3 hours. This represents a contribution in average of 682.42 Mhashes/sec to the pool.

BTW, (in case this bug doesn't have you busy as a blue arsed fly) I haven't been able to figure out how to run DM from cron, either by calling a script or DM directly. It fails with a bunch of crap about not being able to do something inexplicable in java. I guess I'm not adding the correct folder to PATH in cron? Or something? Any ideas? I'll post the error message later if it helps.

[[Tycho]]

Let me repeat: the Deepbit hashmeter is useless. It does not reflect anything useful. I've had it say I'm doing 500 mhash consistently for about an hour, and I do around 300.

I call it "the luck meter" for a reason.
It may not reflect your real hashing speed correctly, but your reward will be the same as if you were hashing with that displayed speed and "normal" luck.
So if you saw 500 MH/s on the luck meter, then you were 200 MH/s more lucky and got 66% more BTCs.

[whackedspinach]

Code:

[6/3/11 6:49:05 PM] Block 10 found on Barts (#2)
[6/3/11 6:49:09 PM] Block 11 found on Barts (#1)
[6/3/11 6:49:29 PM] Block 12 found on Barts (#2)
[6/3/11 6:49:40 PM] Block 13 found on Barts (#1)
[6/3/11 6:49:44 PM] Block 14 found on Barts (#2)
[6/3/11 6:50:25 PM] Block 15 found on Barts (#2)
[6/3/11 6:50:43 PM] Block 16 found on Barts (#2)
[6/3/11 6:50:57 PM] Block 17 found on Barts (#1)

So, if DM is outputting stuff like this, then are the blocks defiantly being found by the cards that are in parentheses?  What I mean is that Barts (#2) doesn't seem to be accessible by certain aticonfig options, and my hash rate seems to be that of a single GPU.  Is it possible that all blocks are being completed by Barts #1 but being labeled otherwise?

[melanarchy]

Okay I'll try Diablo with a smaller pool that has been more reliable for me in the past and let you know if that helps.

Like I've said to others, I believe there is either a widespread bug in how some pools operate (such as giving the wrong diff target out, or incorrectly checking hashes (such as H == 0 only instead of also G <= target)), or Pheonix is incorrectly reporting that shares have been accepted when they haven't.

For me, on Deepbit, I get two or three stale shares for every 1000 give or take.

I connected to a small pool I often use with Diablo. It kept up reporting 304Mhash/s but after several hours the pool reported that of the 1231 requested blocks Diablo had only been able to return 854, for an efficiency of 69%.

With phoenix my efficiency is upwards of 90% even though my Mhash rate is slower by 5.  I don't know enough about the long polling process or the way the rpcs work to identify if this is a bug with my pool or the miner.  But my effective hash rate is certainly better with phoenix.

[brunoshady]

how can I check my sdk version?

where can I see it?