DiabloMiner GPU Miner

[DiabloD3]

Slush pool says to avoid new Diablominer. Luckily i had a backup of old diablominer & using it now.

http://forum.bitcoin.org/index.php?topic=1976.msg285661#msg285661

I even started a thread on this subject weeks ago and just got a lot of BS replies from people that couldn't believe it. The effective hash rate on my pool which = my payut didn't lie. It was actually slower..

I can't comment on later versions of phoenix, but I log all my shares with phatk+phoenix svn r64 (which is what I'm mostly running) and the hash meter expected shares agrees quite closely with the actual ones. ::shrugs::

Slush pool says to avoid new Diablominer. Luckily i had a backup of old diablominer & using it now.

http://forum.bitcoin.org/index.php?topic=1976.msg285661#msg285661

This is a very good point, I haven't tried the new build yet since  the build I pulled down 2 weeks ago is working so well for  my 6 GPU system but this is a concern, the async work is great so hopefully it can be sorted.

IIRC, the async work is what is incompatible with slush. It has nothing to do with the new kernel at all.  Basically when the miner would otherwise be idle it increments the ntime anyways, hoping that the pool will still accept those shares.  On slush, it won't so that work is wasted, but it would have been wasted regardless.  The solution to that is to use a better pool, IMO.

It's also broken with flexible mining proxy. Does anyone know how to get back to pre async?

Perhaps an option to specify no ntime increments.

Pools and proxies that can't handle ntime being incremented by one or two need to be fixed.

[DiabloD3]

Update: Added bitless's hack.

My 5850@918 on 2.1 went from 369 to 378, so a 2.4% increase.

[dishwara]

Update: Added bitless's hack.

My 5850@918 on 2.1 went from 369 to 378, so a 2.4% increase.

Please, it would be very very helpful if you add a version number or any number in the zip file itself.
So, that it will be easy to know which diablominer is which.
All your miner files comes in only one file name DiabloMiner.zip, which makes it very hard to know which is new & which is old.
Thanks for having a great miner.

[Druas]

Update: Added bitless's hack.

My 5850@918 on 2.1 went from 369 to 378, so a 2.4% increase.

Damn yeah that is a rather noticeable increase. Overall, since the kernel has "mutated" I am showing a 3.6% increase.

[N4rk0]

In the part where you enqueue the work to the gpu and then read the output buffer , why do you alternate two buffers? ( buffer and output are two arrays of two buffers)

[N4rk0]

Probably i got it , you use two queues so you don't have to call clFinish to wait for the current work to end before reading the buffer.

[DiabloD3]

In the part where you enqueue the work to the gpu and then read the output buffer , why do you alternate two buffers? ( buffer and output are two arrays of two buffers)

Because its faster on some setups.

[wasabi]

He alternates the buffer so the kernel can be executing on a different buffer at the same time as the buffer read on the other. They can both execute out of order. If it happens to run out of order, anyways.

[DiabloD3]

He alternates the buffer so the kernel can be executing on a different buffer at the same time as the buffer read on the other. They can both execute out of order. If it happens to run out of order, anyways.

Oddly, no. I do that by using two (formerly three) threads, each thread having its own queue.

So, that would be 4 (formerly 6) buffers.

The problem is the Radeon driver sometimes does not finish copying the buffer quickly due to system IO load (since SDK 2.1 does not support DMA, nor does 2.4 on Linux). Alternating buffer (which costs me nothing) means I can schedule the kernel execution without having to wait for the previously used buffer to unlock.

So, its executing in parallel, just out strictly out of order.

[DareC]

Anyone who lost speed with the new kernel should try the latest version. It is now much faster for me.

[iopq]

the latest diablo miner is 2mh/s faster than poclbm on my card! I even patched the maj function
edit: but I'm getting a third of my shares rejected lolwat

[Man From The Future]

Is it possible to make it so that if connection is lost, instead of losing any found blocks, store them and try to submit them when connection is resumed? They may end up being rejected, if it was a long period of no ocnnectivity, but it's more likely that they'll be good?

[DiabloD3]

the latest diablo miner is 2mh/s faster than poclbm on my card! I even patched the maj function
edit: but I'm getting a third of my shares rejected lolwat

Because it was already patched.

[DiabloD3]

Is it possible to make it so that if connection is lost, instead of losing any found blocks, store them and try to submit them when connection is resumed? They may end up being rejected, if it was a long period of no ocnnectivity, but it's more likely that they'll be good?

Yes it is possible, seeing as DiabloMiner already does this. DiabloMiner will submit a share no matter what, mere network problems will not stop it.

[padrino]

I didn't see this coming but it seems since bitcoins.lc patched their bitcoind to add support for socket reuse my primary rig running Diablo started getting 15% rejects. It seems my miners running 400Mh/s or so are alright but my main rig running at 2.3Gh/s is having a really hard time, other pools are no problems but bitcoins.lc is hating that speed on one worker. The backend is pushpool.

How would I go about running an instance per GPU or something similar, I hate the idea of doing it but it looks like that might be the only option?

[DiabloD3]

I didn't see this coming but it seems since bitcoins.lc patched their bitcoind to add support for socket reuse my primary rig running Diablo started getting 15% rejects. It seems my miners running 400Mh/s or so are alright but my main rig running at 2.3Gh/s is having a really hard time, other pools are no problems but bitcoins.lc is hating that speed on one worker. The backend is pushpool.

How would I go about running an instance per GPU or something similar, I hate the idea of doing it but it looks like that might be the only option?

I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.

[padrino]

I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.

Running with debug now, seeing "Forcing getwork update due to nonce saturation" in bursts of 8-10 at once, does that provide any hints?

[DiabloD3]

I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.

Running with debug now, seeing "Forcing getwork update due to nonce saturation" in bursts of 8-10 at once, does that provide any hints?

Nope, only that you seem to have 4 or 5 GPUs.

[padrino]

I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.

Running with debug now, seeing "Forcing getwork update due to nonce saturation" in bursts of 8-10 at once, does that provide any hints?

Nope, only that you seem to have 4 or 5 GPUs.

6 GPUs on this one, holing off turning on other 2 GPUs until I get this under control.... bitcoins.lc is looking at it to see what they can figure out, thanks for your help. It seems it's not an issue if I run a worker per GPU keeping the per worker hash rate lower.

While I I'm posting quick note on another topic, I remember seeing a post stating -f 0 was not a good idea, I always run that on my poclbm miners, any insight on what it should be for dedicated cards on a headless system?

[DiabloD3]

I think you mean keepalive support. DiabloMiner supports keepalive, and the use of it does not effect rejections either way.

It sounds like bitcoins.lc screwed something up.

Running with debug now, seeing "Forcing getwork update due to nonce saturation" in bursts of 8-10 at once, does that provide any hints?

Nope, only that you seem to have 4 or 5 GPUs.

6 GPUs on this one, holing off turning on other 2 GPUs until I get this under control.... bitcoins.lc is looking at it to see what they can figure out, thanks for your help. It seems it's not an issue is a run a worker per GPU keeping the per worker hash rate lower.

While I I'm posting quick note on another topic, I remember seeing a post stating -f 0 was not a good idea, I always run that on my poclbm miners, any insight on what it should be for dedicated cards on a headless system?

If it is 6, you should be seeing about 12 in a burst.

-f 1 is recommended, it'll push it up significantly.

As miner per GPU, this won't fix your problem. It sounds like their patch just doesn't work right. I use a single networking thread to process all async getworks, and a single thread to process all async sendworks (ie, two threads total). If it is trying to pair stuff to TCP sessions, then it is 100% broken, and the guy that wrote the patch doesn't understand how HTTP works either.