DiabloMiner GPU Miner

[organofcorti]

Update: I improved SDK 2.4 performance and fixed emails in --url (use \\@ or +++++ instead of @)

Also, organofcorti, I just made your chart of doom outdated. 69xx should, theoretically, perform better with the new update I just pushed.

Argh! My beautiful chart.....

Oh, well. I'll have to write a script to do it automatically at some point. And I'm looking forward to the upgrade!

[shakaru]

I have a quick question. I just put 2 6850's into 2 seperate machines (heat) and I am under the impression I should get around 200k per card while using the trigers
-f 60 -w 128

but I cap at like 150k each and was woundering that if anyone had some good configs for this card. All the searching gives me is some very contradicotry statesments. Anyone got something?

[DiabloD3]

I have a quick question. I just put 2 6850's into 2 seperate machines (heat) and I am under the impression I should get around 200k per card while using the trigers
-f 60 -w 128

but I cap at like 150k each and was woundering that if anyone had some good configs for this card. All the searching gives me is some very contradicotry statesments. Anyone got something?

A 6850 as far as I can tell should do more than 225 each.

See the op post for this thread on suggested settings to try. Also, just try all the options, every combination of -v 2, 3, 18, 19, 36 and -w 64, 128, 192, 256.

Also, -f 60 on Windows slows it down due to Windows sucking dick. If you intend on benchmarking, use -f 15 or lower.

[gentakin]

After testing various parameters, I found a way to get 2mhash/s more out of diablo compared to phatk. Great!

However, for the last 5 hours, deepbit never calculated a hashrate for me that was even close to the 270mhash/s shown by diablo. It was mostly ~150mhash/s, sometimes as "high" as 200mhash/s. (Using a 45 min average) (also, 1.65% stale shares - might be caused by deepbit though, not sure if long polling works 100% again)

Is it possible that certain parameters cause diablo to display a much higher hashrate than actually achieved (for example because some of the calculations fail silently), or is this just very bad luck?

[nyargh]

After testing various parameters, I found a way to get 2mhash/s more out of diablo compared to phatk. Great!

However, for the last 5 hours, deepbit never calculated a hashrate for me that was even close to the 270mhash/s shown by diablo. It was mostly ~150mhash/s, sometimes as "high" as 200mhash/s. (Using a 45 min average) (also, 1.65% stale shares - might be caused by deepbit though, not sure if long polling works 100% again)

Is it possible that certain parameters cause diablo to display a much higher hashrate than actually achieved (for example because some of the calculations fail silently), or is this just very bad luck?

I am seeing this same effect on other pools.  I am also wondering if Diablo's hashrate calculations are wrong.

[GODLIKE]

Hi, can anybody help me with this?

Here is what I receive when I open the DiabloMiner:

C:\Users\Marco>C:\Users\Marco\Desktop\trunks\btc\DiabloMiner\DiabloMiner-Windows.exe -u XXX@gmail.com -p XXX -o pit.deepbit.net -r 8332
[02/06/11 19:26:11] Started
[02/06/11 19:26:11] Connecting to: http://pit.deepbit.net:8332/
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.libr
ary.path
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at org.lwjgl.Sys$1.run(Sys.java:73)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
        at org.lwjgl.Sys.loadLibrary(Sys.java:82)
        at org.lwjgl.Sys.<clinit>(Sys.java:99)
        at org.lwjgl.opencl.CL.<clinit>(CL.java:51)
        at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:379)

        at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:127)

C:\Users\Marco>

I'm using DeepBit only because it's the first I found, I'm totally newbie and looking just to make things work.

Thank you for your help.

[DiabloD3]

Hi, can anybody help me with this?

Here is what I receive when I open the DiabloMiner:

C:\Users\Marco>C:\Users\Marco\Desktop\trunks\btc\DiabloMiner\DiabloMiner-Windows.exe -u XXX@gmail.com -p XXX -o pit.deepbit.net -r 8332
[02/06/11 19:26:11] Started
[02/06/11 19:26:11] Connecting to: http://pit.deepbit.net:8332/
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.libr
ary.path
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at org.lwjgl.Sys$1.run(Sys.java:73)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
        at org.lwjgl.Sys.loadLibrary(Sys.java:82)
        at org.lwjgl.Sys.<clinit>(Sys.java:99)
        at org.lwjgl.opencl.CL.<clinit>(CL.java:51)
        at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:379)

        at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:127)

C:\Users\Marco>

I'm using DeepBit only because it's the first I found, I'm totally newbie and looking just to make things work.

Thank you for your help.

Try cd C:\Users\Marco\Desktop\trunks\btc\DiabloMiner before running it.

[DiabloD3]

After testing various parameters, I found a way to get 2mhash/s more out of diablo compared to phatk. Great!

However, for the last 5 hours, deepbit never calculated a hashrate for me that was even close to the 270mhash/s shown by diablo. It was mostly ~150mhash/s, sometimes as "high" as 200mhash/s. (Using a 45 min average) (also, 1.65% stale shares - might be caused by deepbit though, not sure if long polling works 100% again)

Is it possible that certain parameters cause diablo to display a much higher hashrate than actually achieved (for example because some of the calculations fail silently), or is this just very bad luck?

I am seeing this same effect on other pools.  I am also wondering if Diablo's hashrate calculations are wrong.

Nope, my hashrate is 100% correct. The problem is, OTHER miners do NOT look for OpenCL execution errors and happily count the hashes on a failed run.

If your Intenret is lagging badly, all miners, not just mine, will have strange hashrate drops because its blocking on share submission.

If you think there is actually a problem, compare vs a local running bitcoind.... if it STILL has large variations in hashrate, then there is an issue.

In addition to that, less than -f 15 often causes the OS clock to get jerky up to the point that the 15 second average (the first number) becomes very unreliable. In these situations, use the forever average only (the second number)... it usually becomes reliable within a minute or two.

Other miners suffer from this, but try various ways of covering it up; none are as accurate as using the forever average on mine over long periods.

[nyargh]

After testing various parameters, I found a way to get 2mhash/s more out of diablo compared to phatk. Great!

However, for the last 5 hours, deepbit never calculated a hashrate for me that was even close to the 270mhash/s shown by diablo. It was mostly ~150mhash/s, sometimes as "high" as 200mhash/s. (Using a 45 min average) (also, 1.65% stale shares - might be caused by deepbit though, not sure if long polling works 100% again)

Is it possible that certain parameters cause diablo to display a much higher hashrate than actually achieved (for example because some of the calculations fail silently), or is this just very bad luck?

I am seeing this same effect on other pools.  I am also wondering if Diablo's hashrate calculations are wrong.

Nope, my hashrate is 100% correct. The problem is, OTHER miners do NOT look for OpenCL execution errors and happily count the hashes on a failed run.

If your Intenret is lagging badly, all miners, not just mine, will have strange hashrate drops because its blocking on share submission.

If you think there is actually a problem, compare vs a local running bitcoind.... if it STILL has large variations in hashrate, then there is an issue.

In addition to that, less than -f 15 often causes the OS clock to get jerky up to the point that the 15 second average (the first number) becomes very unreliable. In these situations, use the forever average only (the second number)... it usually becomes reliable within a minute or two.

Other miners suffer from this, but try various ways of covering it up; none are as accurate as using the forever average on mine over long periods.

I am seeing nearly double the found hashes with phoenix/phatk.  None of them are being rejected by the pool.  The hashrate being reported by the miners is nearly identical. 

If the pool allocates shares based on submitted POWs and doesn't reject them, wouldn't I want the miner that submits more POWs over a given time period?

[gentakin]

Thanks for your fast reply!

If your Intenret is lagging badly, all miners, not just mine, will have strange hashrate drops because its blocking on share submission.

This seems to be no problem for me. I stopped diablo and fired up phoenix, and after some time the hashrate shown at deepbit's web site shows ~270mhash/sec, like I expected. I'm not having any connection issues, only my router sometimes stops working.
Is there a console output I should be watching for in diablo to see if it is taking a long time to submit shares? Both hash meters (total and 15sec average) showed 270mhash/s. (And why not submit shares in a seperate thread so there is no blocking?)

In addition to that, less than -f 15 often causes the OS clock to get jerky up to the point that the 15 second average (the first number) becomes very unreliable. In these situations, use the forever average only (the second number)... it usually becomes reliable within a minute or two.

This seems to be no problem for me as well. I don't specify -f on the command line, so I guess it's using a default value. With diablo, there is pretty much no desktop lag for me (while phatk causes same lag). The gnome clock updates fine, so this should be fine.

Other miners suffer from this, but try various ways of covering it up; none are as accurate as using the forever average on mine over long periods.

As I said, the forever average looked okay.

It's still possible, due to the random nature of mining, that the relatively low number of submitted shares was bad luck. Or maybe there is a bug that only appears on some systems (i.e. my system) and possibly only with some configurations that causes diablo to
* calculate hashrate wrong OR
* sometimes not submit/recognize a share even if it is valid.

[nyargh]

* sometimes not submit/recognize a share even if it is valid.

This is what I would suspect, but who knows?  I am convinced that there is a bug in DiabloMiner.  What is your setup?  card / driver / sdk / os?

[gentakin]

This is what I would suspect, but who knows?  I am convinced that there is a bug in DiabloMiner.  What is your setup?  card / driver / sdk / os?

it's a single 6870 from sapphire, using sdk 2.4, ubuntu 11.04 (I like unity, even though it might put some load on my gpu) and apt says my driver is "fglrx 2:8.840-0ubuntu4".
No manual over/underclocking.

[nyargh]

it's a single 6870 from sapphire, using sdk 2.4, ubuntu 11.04 (I like unity, even though it might put some load on my gpu) and apt says my driver is "fglrx 2:8.840-0ubuntu4".
No manual over/underclocking.

Hmmm... I have a different setup, 2x sapphire 5830s, 2.4 SDK, 11.5 driver, debian squeeze.  My cards are overclocked to the default bios max (875 mhz).  This may be a more serious bug if it's affecting two very different setups.  The only common thread here is the SDK and the platform (kinda).

[GODLIKE]

I tried as you say, this is the result:



Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Marco>cd C:\Users\Marco\Desktop\trunks\btc\DiabloMiner

C:\Users\Marco\Desktop\trunks\btc\DiabloMiner>C:\Users\Marco\Desktop\trunks\btc\
DiabloMiner\DiabloMiner-Windows.exe -u XXX@gmail.com -p XXX -o pit
.deepbit.net -r 8332
[02/06/11 23:04:47] Started
[02/06/11 23:04:47] Connecting to: http://pit.deepbit.net:8332/
Exception in thread "main" org.lwjgl.LWJGLException: Could not locate OpenCL lib
rary.
        at org.lwjgl.opencl.CL.create(CL.java:121)
        at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:379)

        at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:127)

C:\Users\Marco\Desktop\trunks\btc\DiabloMiner>

[DiabloD3]

Thanks for your fast reply!

If your Intenret is lagging badly, all miners, not just mine, will have strange hashrate drops because its blocking on share submission.

This seems to be no problem for me. I stopped diablo and fired up phoenix, and after some time the hashrate shown at deepbit's web site shows ~270mhash/sec, like I expected. I'm not having any connection issues, only my router sometimes stops working.
Is there a console output I should be watching for in diablo to see if it is taking a long time to submit shares? Both hash meters (total and 15sec average) showed 270mhash/s. (And why not submit shares in a seperate thread so there is no blocking?)

In addition to that, less than -f 15 often causes the OS clock to get jerky up to the point that the 15 second average (the first number) becomes very unreliable. In these situations, use the forever average only (the second number)... it usually becomes reliable within a minute or two.

This seems to be no problem for me as well. I don't specify -f on the command line, so I guess it's using a default value. With diablo, there is pretty much no desktop lag for me (while phatk causes same lag). The gnome clock updates fine, so this should be fine.

Other miners suffer from this, but try various ways of covering it up; none are as accurate as using the forever average on mine over long periods.

As I said, the forever average looked okay.

It's still possible, due to the random nature of mining, that the relatively low number of submitted shares was bad luck. Or maybe there is a bug that only appears on some systems (i.e. my system) and possibly only with some configurations that causes diablo to
* calculate hashrate wrong OR
* sometimes not submit/recognize a share even if it is valid.

Wait, hold up. Theres your problem. Deepbit's hash meter is 100% inaccurate and is counting a rare random event, ie, share generation. Do not use Deepbit's hash meter as a measure of performance.

My miner tends to swing the randomness of share generation around harder (due to working on independent work in parallel), but otherwise has no effect on actual share generation.

Also, I may consider submitting shares in a separate thread in the future, however I already run 3 mining threads per GPU and this tends to eliminate usual network lag issues.

[DiabloD3]

After testing various parameters, I found a way to get 2mhash/s more out of diablo compared to phatk. Great!

However, for the last 5 hours, deepbit never calculated a hashrate for me that was even close to the 270mhash/s shown by diablo. It was mostly ~150mhash/s, sometimes as "high" as 200mhash/s. (Using a 45 min average) (also, 1.65% stale shares - might be caused by deepbit though, not sure if long polling works 100% again)

Is it possible that certain parameters cause diablo to display a much higher hashrate than actually achieved (for example because some of the calculations fail silently), or is this just very bad luck?

I am seeing this same effect on other pools.  I am also wondering if Diablo's hashrate calculations are wrong.

Trust me, my hashrate calculation is correct. If anything, poclbm is somewhat inaccurate and phoenix has been proven to be very inaccurate.

[DiabloD3]

I tried as you say, this is the result:



Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Marco>cd C:\Users\Marco\Desktop\trunks\btc\DiabloMiner

C:\Users\Marco\Desktop\trunks\btc\DiabloMiner>C:\Users\Marco\Desktop\trunks\btc\
DiabloMiner\DiabloMiner-Windows.exe -u XXX@gmail.com -p XXX -o pit
.deepbit.net -r 8332
[02/06/11 23:04:47] Started
[02/06/11 23:04:47] Connecting to: http://pit.deepbit.net:8332/
Exception in thread "main" org.lwjgl.LWJGLException: Could not locate OpenCL lib
rary.
        at org.lwjgl.opencl.CL.create(CL.java:121)
        at com.diablominer.DiabloMiner.DiabloMiner.execute(DiabloMiner.java:379)

        at com.diablominer.DiabloMiner.DiabloMiner.main(DiabloMiner.java:127)

C:\Users\Marco\Desktop\trunks\btc\DiabloMiner>

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

[DiabloD3]

After testing various parameters, I found a way to get 2mhash/s more out of diablo compared to phatk. Great!

However, for the last 5 hours, deepbit never calculated a hashrate for me that was even close to the 270mhash/s shown by diablo. It was mostly ~150mhash/s, sometimes as "high" as 200mhash/s. (Using a 45 min average) (also, 1.65% stale shares - might be caused by deepbit though, not sure if long polling works 100% again)

Is it possible that certain parameters cause diablo to display a much higher hashrate than actually achieved (for example because some of the calculations fail silently), or is this just very bad luck?

I am seeing this same effect on other pools.  I am also wondering if Diablo's hashrate calculations are wrong.

Nope, my hashrate is 100% correct. The problem is, OTHER miners do NOT look for OpenCL execution errors and happily count the hashes on a failed run.

If your Intenret is lagging badly, all miners, not just mine, will have strange hashrate drops because its blocking on share submission.

If you think there is actually a problem, compare vs a local running bitcoind.... if it STILL has large variations in hashrate, then there is an issue.

In addition to that, less than -f 15 often causes the OS clock to get jerky up to the point that the 15 second average (the first number) becomes very unreliable. In these situations, use the forever average only (the second number)... it usually becomes reliable within a minute or two.

Other miners suffer from this, but try various ways of covering it up; none are as accurate as using the forever average on mine over long periods.

I am seeing nearly double the found hashes with phoenix/phatk.  None of them are being rejected by the pool.  The hashrate being reported by the miners is nearly identical. 

If the pool allocates shares based on submitted POWs and doesn't reject them, wouldn't I want the miner that submits more POWs over a given time period?

Are you sure you're using the absolute newest version of my miner? mtrlt's 0.5% speed increase accidentally had a bug that would cause similar behavior to half of shares missing. I fixed it shortly afterwards.

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

[nyargh]

Are you sure you're using the absolute newest version of my miner? mtrlt's 0.5% speed increase accidentally had a bug that would cause similar behavior to half of shares missing. I fixed it shortly afterwards.

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

Interesting, last one I pulled down was yesterday.  I'll try that flag and see if hw errors pop - I assumed that they would show up by default.

[gentakin]

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.