DiabloMiner GPU Miner

[DareC]

The new frankenkernel seems to have lost me about 10 mhash/s. I'm on a 6990@910 (mem 625). Using -v 2 -w 128 (increasing -w made things worse, as did fiddling with -v).

[1713587460]

1713587460

[1713587460]

1713587460

[gmaxwell]

Uodate: Behold, the frankenkernel. A mix of DiabloKernel and phatk.
Before this, I got 369 mhash on my 5850@918 on SDK 2.1, and 352 on 2.4 post-11.4 (thanks AMD!)
Now I get 369 on 2.1 AND 2.4.
AMD, you can't hide. I am coming for you.

Congrats, you're finally as fast as phoenix / phatk for me— actually about 0.4% faster it looks like.  (Only tested it on the 5850s with SDK 2.4 so far)

I seemed to be getting high stales with -f0, -f1 was fine but it could have just been bad luck. There didn't appear to be much if any hashrate difference, so I just left it at 1%.

Still need the ability to loadshare (ideally) or fail over between multiple pools.   But it's looking pretty good.  Good work.

[iopq]

Uodate: Behold, the frankenkernel. A mix of DiabloKernel and phatk.

Before this, I got 369 mhash on my 5850@918 on SDK 2.1, and 352 on 2.4 post-11.4 (thanks AMD!)

Now I get 369 on 2.1 AND 2.4.

AMD, you can't hide. I am coming for you.

oh hey it started working for me now
not as fast as poclbm, though

[kripz]

lol pool went down at time of update, what a coincedence...

Cant be me.. 90% shares arent being submitted?

Bug?

Miner 1
mhash 177.7/178.9 | a/r/hwe: 1/0/0 | ghash: 110.2 | fps: 30.0

Miner 2
mhash 819.5/826.6 | a/r/hwe: 0/3/0 | ghash: 114.0 113.3 112.3 | fps: 30.2

[24/06/11 8:49:58 PM] DEBUG: Attempt 77 found on Cypress (#3)
[24/06/11 8:50:02 PM] DEBUG: Attempt 78 found on Cypress (#2)
[24/06/11 8:50:07 PM] DEBUG: Attempt 79 found on Cypress (#2)
[24/06/11 8:50:12 PM] DEBUG: Attempt 80 found on Cypress (#3)
[24/06/11 8:50:13 PM] DEBUG: Attempt 81 found on Cypress (#2)
[24/06/11 8:50:14 PM] DEBUG: Attempt 82 found on Cypress (#3)
[24/06/11 8:50:15 PM] DEBUG: Attempt 83 found on Cypress (#2)
[24/06/11 8:50:18 PM] DEBUG: Attempt 84 found on Cypress (#3)
[24/06/11 8:50:21 PM] DEBUG: Attempt 85 found on Cypress (#1)
[24/06/11 8:50:23 PM] DEBUG: Attempt 86 found on Cypress (#2)
[24/06/11 8:50:33 PM] DEBUG: Attempt 87 found on Cypress (#2)

both updated to latest git

Just updated windows machine

[24/06/11 8:56:17 PM] DEBUG: Attempt 3 found on Cayman (#2)
[24/06/11 8:56:18 PM] DEBUG: Attempt 4 found on Cayman (#2)
[24/06/11 8:56:20 PM] DEBUG: Attempt 5 found on Cayman (#2)
[24/06/11 8:56:26 PM] DEBUG: Forcing getwork update due to nonce saturation
[24/06/11 8:56:31 PM] DEBUG: Forcing getwork update due to nonce saturation
[24/06/11 8:56:32 PM] DEBUG: Attempt 6 found on Cayman (#2)
[24/06/11 8:56:32 PM] DEBUG: Attempt 7 found on Cayman (#2)
[24/06/11 8:56:34 PM] DEBUG: Attempt 8 found on Cayman (#2)
[24/06/11 8:56:38 PM] DEBUG: Attempt 9 found on Cayman (#2)

mhash 364.5/362.8 | a/r/hwe: 0/1/0 | ghash: 30.1 | fps: 30.4

Nothing is being submitted?

EDIT: now how do i go back to the old version?

Nope, it's Diablominer and/or flexible proxy (though i never touched the proxy). It will find a few results, submit one or two and say accepted. After that "Attempt found" but never submit it?

Phoenix works 100% rock solid

[DiabloD3]

Uodate: Behold, the frankenkernel. A mix of DiabloKernel and phatk.
Before this, I got 369 mhash on my 5850@918 on SDK 2.1, and 352 on 2.4 post-11.4 (thanks AMD!)
Now I get 369 on 2.1 AND 2.4.
AMD, you can't hide. I am coming for you.

Congrats, you're finally as fast as phoenix / phatk for me— actually about 0.4% faster it looks like.  (Only tested it on the 5850s with SDK 2.4 so far)

I seemed to be getting high stales with -f0, -f1 was fine but it could have just been bad luck. There didn't appear to be much if any hashrate difference, so I just left it at 1%.

Still need the ability to loadshare (ideally) or fail over between multiple pools.   But it's looking pretty good.  Good work.

Don't use -f 0. I need to add an error message for that, as far as I can tell, instead of dividing by zero, it just steadily increases the worksize to maximum of 2^32 (or about 0.1 fps give or take).

Loadshare might be halfway easily to implement. Not sure.

[DiabloD3]

Uodate: Behold, the frankenkernel. A mix of DiabloKernel and phatk.

Before this, I got 369 mhash on my 5850@918 on SDK 2.1, and 352 on 2.4 post-11.4 (thanks AMD!)

Now I get 369 on 2.1 AND 2.4.

AMD, you can't hide. I am coming for you.

oh hey it started working for me now
not as fast as poclbm, though

Use -v 2 with either -w 128 or 256. -v 3/19 settings don't seem to be optimum anymore.

[DiabloD3]

The new frankenkernel seems to have lost me about 10 mhash/s. I'm on a 6990@910 (mem 625). Using -v 2 -w 128 (increasing -w made things worse, as did fiddling with -v).

-v 2 -w 128 should be as fast as phatk VECTORS WORKSIZE=128 on your machine. If it isn't, then its just more proof Phoenix has a broken hash meter.

[DiabloD3]

lol pool went down at time of update, what a coincedence...

Cant be me.. 90% shares arent being submitted?

Bug?

Miner 1
mhash 177.7/178.9 | a/r/hwe: 1/0/0 | ghash: 110.2 | fps: 30.0

Miner 2
mhash 819.5/826.6 | a/r/hwe: 0/3/0 | ghash: 114.0 113.3 112.3 | fps: 30.2

[24/06/11 8:49:58 PM] DEBUG: Attempt 77 found on Cypress (#3)
[24/06/11 8:50:02 PM] DEBUG: Attempt 78 found on Cypress (#2)
[24/06/11 8:50:07 PM] DEBUG: Attempt 79 found on Cypress (#2)
[24/06/11 8:50:12 PM] DEBUG: Attempt 80 found on Cypress (#3)
[24/06/11 8:50:13 PM] DEBUG: Attempt 81 found on Cypress (#2)
[24/06/11 8:50:14 PM] DEBUG: Attempt 82 found on Cypress (#3)
[24/06/11 8:50:15 PM] DEBUG: Attempt 83 found on Cypress (#2)
[24/06/11 8:50:18 PM] DEBUG: Attempt 84 found on Cypress (#3)
[24/06/11 8:50:21 PM] DEBUG: Attempt 85 found on Cypress (#1)
[24/06/11 8:50:23 PM] DEBUG: Attempt 86 found on Cypress (#2)
[24/06/11 8:50:33 PM] DEBUG: Attempt 87 found on Cypress (#2)

both updated to latest git

Just updated windows machine

[24/06/11 8:56:17 PM] DEBUG: Attempt 3 found on Cayman (#2)
[24/06/11 8:56:18 PM] DEBUG: Attempt 4 found on Cayman (#2)
[24/06/11 8:56:20 PM] DEBUG: Attempt 5 found on Cayman (#2)
[24/06/11 8:56:26 PM] DEBUG: Forcing getwork update due to nonce saturation
[24/06/11 8:56:31 PM] DEBUG: Forcing getwork update due to nonce saturation
[24/06/11 8:56:32 PM] DEBUG: Attempt 6 found on Cayman (#2)
[24/06/11 8:56:32 PM] DEBUG: Attempt 7 found on Cayman (#2)
[24/06/11 8:56:34 PM] DEBUG: Attempt 8 found on Cayman (#2)
[24/06/11 8:56:38 PM] DEBUG: Attempt 9 found on Cayman (#2)

mhash 364.5/362.8 | a/r/hwe: 0/1/0 | ghash: 30.1 | fps: 30.4

Nothing is being submitted?

EDIT: now how do i go back to the old version?

Nope, it's Diablominer and/or flexible proxy (though i never touched the proxy). It will find a few results, submit one or two and say accepted. After that "Attempt found" but never submit it?

Phoenix works 100% rock solid

The proxy probably does not correctly support things DiabloMiner does, such as time incrementing and returning multiple nonces for the same getwork over short periods. It looks like the sendwork thread is being choked by the proxy.

So, clearly, its a proxy bug.

[kripz]

I will report it in the proxy thread. Hopefully it's fixed so i can use diablo again.

[DareC]

The new frankenkernel seems to have lost me about 10 mhash/s. I'm on a 6990@910 (mem 625). Using -v 2 -w 128 (increasing -w made things worse, as did fiddling with -v).

-v 2 -w 128 should be as fast as phatk VECTORS WORKSIZE=128 on your machine. If it isn't, then its just more proof Phoenix has a broken hash meter.

I don't think I was clear. I lost about 10 Mhash/s upgrading from non-frankenkernel Diablo to frankenkernel Diablo.

I built myself a pre-frankenkernel Diablo so I'm set for now, but speed decrease should probably be investigated.

[iopq]

Uodate: Behold, the frankenkernel. A mix of DiabloKernel and phatk.

Before this, I got 369 mhash on my 5850@918 on SDK 2.1, and 352 on 2.4 post-11.4 (thanks AMD!)

Now I get 369 on 2.1 AND 2.4.

AMD, you can't hide. I am coming for you.

oh hey it started working for me now
not as fast as poclbm, though

Use -v 2 with either -w 128 or 256. -v 3/19 settings don't seem to be optimum anymore.

that worked, I'm getting about 138mhash/s which is my hashrate with poclbm

[padrino]

The new frankenkernel seems to have lost me about 10 mhash/s. I'm on a 6990@910 (mem 625). Using -v 2 -w 128 (increasing -w made things worse, as did fiddling with -v).

-v 2 -w 128 should be as fast as phatk VECTORS WORKSIZE=128 on your machine. If it isn't, then its just more proof Phoenix has a broken hash meter.

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

[dishwara]

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

[gmaxwell]

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::

[gmaxwell]

Don't use -f 0. I need to add an error message for that, as far as I can tell, instead of dividing by zero, it just steadily increases the worksize to maximum of 2^32 (or about 0.1 fps give or take).

Or just clamp it at some reasonable value and don't even bother throwing an error.

Loadshare might be halfway easily to implement. Not sure.

I'd hope it would be, especially now that you're async— run multiple work collecting threads, have the miners threads pull from ones with current work in round-robin or random (to reduce lock contention) order.

Having one miner process per system is nice from a maintenance perspective (it sucks to have to track the health of 6 processes), but it's an increased liability e.g. if one TCP session loses a packet and stalls out for 10 seconds before recovering then the I've got 1.8GH/s going stale. And god forbid a pool go down or the internet have some routing retardation. Having two or three separate access threads being pulled from in realtime would greatly reduce that risk while still reducing load on the pools vs one card one socket that most miner programs result in.

[DareC]

If anyone needs a compiled version of the last version before the new kernel, I've compiled and put it up here. Source is included.

EDIT: Added GPG signature. This is the same key I use on #bitcoin-otc (see here).

[Druas]

Uodate: Behold, the frankenkernel. A mix of DiabloKernel and phatk.

Before this, I got 369 mhash on my 5850@918 on SDK 2.1, and 352 on 2.4 post-11.4 (thanks AMD!)

Now I get 369 on 2.1 AND 2.4.

AMD, you can't hide. I am coming for you.

This update seems to have given me a very small increase in hashrate. My hashrate is also more consistently one number than the previous version where it jumped around a bit. So far, I have had far less stales, but maybe I have just been getting lucky. I am tempted to save the last version though just because it is a version that is not tainted by phoenix.

[padrino]

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.

[gmaxwell]

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.

[kripz]

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.