Topic: DiabloMiner GPU Miner - page 34. (Read 866596 times)

:-)

Tell me what mhz you're at, because its quite entirely possible to get 464, but that sounds high for stock 880mhz.

Yeah, I hope it's not a bug too.  Odd thing was I was getting much lower mhash at first, playing with different settings, and then got this with just defaults.

Note that it's not stock, I have the GPU clocked to 950 through CCC, but looking at the hwardware comparison page it looks like it should be around 430 mhash tops, so I don't think that fully explains it unless the hardware comparison page is just out of date.


Anyway, with the latest Diablominer, mhash didn't change too much:

[1/24/12 12:36:37 AM] api2.bitcoin.cz accepted block 381 from Cayman (#1)
[1/24/12 12:36:41 AM] api2.bitcoin.cz accepted block 382 from Cayman (#1)
mhash: 461.9/462.5 | accept: 382 | reject: 2 | hw error: 0^C
C:\Users\giles\Desktop\DiabloMiner>cd ..

C:\Users\giles\Desktop>cd DiabloMinerNew

C:\Users\giles\Desktop\DiabloMinerNew>DiabloMiner-Windows.exe -l http://api2.bit
coin.cz -u giles.hex1 -p ****
[1/24/12 12:37:02 AM] Started
[1/24/12 12:37:02 AM] Connecting to: http://api2.bitcoin.cz:8332/
[1/24/12 12:37:03 AM] Using AMD Accelerated Parallel Processing OpenCL 1.1 AMD-A
PP (831.4)
[1/24/12 12:37:03 AM] BFI_INT patching enabled, disabling hardware check errors
[1/24/12 12:37:03 AM] Added Cayman (#1) (24 CU, local work size of 256)
[1/24/12 12:37:12 AM] api2.bitcoin.cz accepted block 1 from Cayman (#1)
[1/24/12 12:37:14 AM] api2.bitcoin.cz accepted block 2 from Cayman (#1)
[1/24/12 12:37:21 AM] api2.bitcoin.cz accepted block 3 from Cayman (#1)
[1/24/12 12:37:29 AM] api2.bitcoin.cz accepted block 4 from Cayman (#1)
[1/24/12 12:37:36 AM] api2.bitcoin.cz accepted block 5 from Cayman (#1)
[1/24/12 12:37:36 AM] api2.bitcoin.cz accepted block 6 from Cayman (#1)
[1/24/12 12:37:39 AM] api2.bitcoin.cz accepted block 7 from Cayman (#1)
[1/24/12 12:37:41 AM] api2.bitcoin.cz accepted block 8 from Cayman (#1)
[1/24/12 12:38:06 AM] api2.bitcoin.cz rejected block 1 from Cayman (#1)
[1/24/12 12:38:19 AM] api2.bitcoin.cz accepted block 9 from Cayman (#1)
[1/24/12 12:38:37 AM] api2.bitcoin.cz accepted block 10 from Cayman (#1)
[1/24/12 12:38:48 AM] api2.bitcoin.cz accepted block 11 from Cayman (#1)
[1/24/12 12:39:14 AM] api2.bitcoin.cz accepted block 12 from Cayman (#1)
[1/24/12 12:39:18 AM] api2.bitcoin.cz accepted block 13 from Cayman (#1)
[1/24/12 12:39:24 AM] api2.bitcoin.cz accepted block 14 from Cayman (#1)
[1/24/12 12:39:27 AM] api2.bitcoin.cz accepted block 15 from Cayman (#1)
[1/24/12 12:39:36 AM] api2.bitcoin.cz accepted block 16 from Cayman (#1)
mhash: 464.2/462.9 | accept: 16 | reject: 1 | hw error: 0

Oh, and do me a favor, and check if the release I just released changes this. I'm hoping thats not a bug, its too awesome.

Update: Fix -aa when used with -v 1

That'd be impossible on stock clocks, I think. Either that, or my recent kernel changes have REALLY increased speed.

I've just switched to diablominer after using the simple guiminer for several months.  On this particular PC, I have a single 6970 and I have been getting around 380mhash typically with guiminer.  Somehow, with diablominer I am now getting an apparent 460mhash, and I am trying to figure out if this is for real.  It seems like too much of an increase. Is DiabloMiner really that much more efficient? Was  something wrong with my system earlier maybe?

This is with no special flags.  I tried playing around with -v and -w but found the best results came without any extra flags.

This is what I am seeing-

[1/23/12 11:51:45 PM] api2.bitcoin.cz accepted block 122 from Cayman (#1)
[1/23/12 11:52:06 PM] api2.bitcoin.cz accepted block 123 from Cayman (#1)
[1/23/12 11:52:25 PM] api2.bitcoin.cz accepted block 124 from Cayman (#1)
[1/23/12 11:52:38 PM] api2.bitcoin.cz accepted block 125 from Cayman (#1)
mhash: 463.4/462.7 | accept: 125 | reject: 0 | hw error: 0

That requires ADL, something only C apps can use unless I develop a Java wrapper for that, which isn't something I particularly want to do. However, if someone else writes one and it works and its packaged in a jar sanely, I would use it.

I think we'd be all better off with a stand alone program that uses the cgminer-like code for that so ANY miner can use it. The python miners have the same issue I do, calling C functions suck.

As of roadmap, I dunno. I expect main DM development is basically finished unless I produce a web UI and/or cluster control. Some people have asked for that, but I'm not sure if its worth adding. Major GCN support is about the only thing thats concrete.

Hey Diablo,
Since Diablominer obviously has 'staying power' as many users still prefer it over even CGMiner (and all cgminer features), have you considered adding card controls (Clock, Fan etc) to it and further develop it ?
Do you have a 'Roadmap' of where you would like to see Diablominer, say in a year ?

Seems to be -v 1 -w 256 -aa

Update: Shorten debug status line, fix kernel for layered vectors

No flags is the best flags.

i guess my question got lost in my results.  which are best so far for me with all defaults.  ( i tried -v 2, not better. v4 even worse)

what are the best flags for the 7970 ?

Those weren't my results. I think he was trying to tell me that's what he was getting.

It's about.. .5mh/s faster. Margin of error...

Hey 7970 users, could people check if -aa is faster at all on 7970? I'm getting reports that it actually is, which would be pretty amazing if its true.

Road,  what flags are you using for diablo?

I am getting ~670Mh  1125/1020  pulling about 240w/c   all defaults on diablo


edit:  i since changed to 925/1100  to compare.   getting: ~550   diablo defaults

edit2: wow, only pulling about 175w/c    2 cards:  479w total

mobo:  crosshair V
psu:     seasonic 650
cpu:    phenomII x4 830
HD:   western dig green power 500g
mem:  Kingston 4g 1600

nothing underclocked on mobo, all defaults pulls about 120w idle

Update: Fix ozco.in specific bug

Update: Increased speed 0.5%, added alt array more (-aa)

Update: Improve kernel mangling parser, fix accidental disabling of BFI_INT