hashkill - testing bitcoin miner plugin

[AngelusWebDesign]

I tried restarting the miner -- didn't help. (BTW, I'm a fellow programmer, so trying to isolate a problem is 2nd nature )

Deepbit started reporting a lot of stale shares (and Hashkill started complaining about the Long Polling, as I mentioned) -- when it starts to get over 2% I get nervous about not getting the most from my modest hardware. I'm only getting 20 MH/s more on my 2 cards with Hashkill -- which I love, don't get me wrong -- but if that 3.5% increase results in 2.5, 3, or 4% stale shares -- I have to do something.

You're right, it could be due to something on the Deepbit side -- is there anything the software could do to compensate, or deal with whatever it is? I don't think there's a server/debug log we could look at to see what's happening on the Deepbit side.

I like using Hashkill because I only have to run it once (instead of once per card), it's faster, and it makes me feel like I'm getting something extra for my 64-bit Linux install.

And a 3.5% increase is going to mean more and more as I add capacity. One more card on the way, for now.

[gat3way]

OK - the emergency fix is ready. This finally solves the LP issues on deepbit and elligius. Please redownload.

64-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz

[leepfrog]

gat3way is there a way to disable reading of the thermal values of a GPU?
I am facing an issue where reading the gpu temperature via aticonfig sometimes reduces the fan speed back to 24% from my manual configured 90%.
I've once observed the same behaviour when running hashkill so I fear it might be the same issue and therefore would like to disable it completely.

Another question: I am mining with 3x5830 and 1 6870 on the same rig. From what I understand hashkill takes a piece of work from the pool and distributes it between the 4 cards.
Is it possible that this results in a performance impact because of different mhash/architecture?

[gat3way]

gat3way is there a way to disable reading of the thermal values of a GPU?
I am facing an issue where reading the gpu temperature via aticonfig sometimes reduces the fan speed back to 24% from my manual configured 90%.
I've once observed the same behaviour when running hashkill so I fear it might be the same issue and therefore would like to disable it completely.

That's rather strange and it should not happen. Never heard about something like that before. Have you tried using other Catalyst version? Unfortunately, thermal monitoring cannot be disabled at present (OK, there is a workaround - you can rename /usr/lib/libatiadlxx.so and it would stop working - aticonfig would stop working as well until you rename it back).

Another question: I am mining with 3x5830 and 1 6870 on the same rig. From what I understand hashkill takes a piece of work from the pool and distributes it between the 4 cards.
Is it possible that this results in a performance impact because of different mhash/architecture?

It used to. Now it has a separate queue per thread and by default you have 2*(number of GPUs) threads. It indeed resulted in performance loss on faster systems that was usually worked around by running a second instance. This should be no more valid now.

[leepfrog]

The thermal issue is not related to hashkill - i guess it is something with the catalyst or SDK version... furthermore I am using cards which do not have the reference cooler (Sapphire 5830 Extreme), so this might also be an issue.
But this is not such a big deal - I've got a cronjob monitoring temperature and killing miners if temperature exeeds a threshold - just wanted to know if there is an undocumented switch.

Nice to hear that the LP issue as well as the performance with different GPUs has been increased, I'll give it another try later today!

Thanks for the super fast reply!

[fasti]

mm.. after 4 proc, hashrate went to 0

Restarted.. after a while it shutdown my primary card and continued only with the other one.

Does it stop if there's some error?

I have overclocked my 6950 from 810 -> 880 with stock voltage. Haven't tested if it's stable, works with other miners w/o any increase to invalid. Temperature 77c with primary and 75 on secondary.

[gat3way]

Looks more like a connection problem to me. Do you have "failure connecting..." messages in the console?

[fasti]

no.. nothing, it never reactivated the other GPU after it dropped it.

[fasti]

Problem went away after 2 first tries... weird. Anyway now it's telling that my hashrate is up to 684, which is kind of lower than previous versions 704(altough it never provided no where near 700).

[sal002]

I get this error when I try to run:

[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)[error] (ocl_bitcoin.c:1079) clBuildProgram error (-11)

[sal002]

Nevermind - I am using 2.1 of the SDK - I assume this is the issue.

I'll do it on linuxcoin instead.

[gat3way]

Unfortunately it won't work with SDK 2.1. It also works with 2.2, but not at all optimal on multi-gpu systems.

[dudel42]

hi,

Running the latest version here with:

./hashkill-gpu -G2 -D -p bitcoin xxx:xxx:xx...

However I get a little less MH/s than with phoenix (~275), and lots of stales?

Speed: 270 MHash/sec [proc: 86] [subm: 70] [stale: 22] [eff: 81%]

2.4 sdk, radeon 5850, 64bit  ubuntu 11.04

any ideas what could be wrong?

[doomy]

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz

Hello gat3way, would it be possible to edit the first post with the 32 bit link.

[leepfrog]

hi,

Running the latest version here with:

./hashkill-gpu -G2 -D -p bitcoin xxx:xxx:xx...

However I get a little less MH/s than with phoenix (~275), and lots of stales?

Speed: 270 MHash/sec [proc: 86] [subm: 70] [stale: 22] [eff: 81%]

2.4 sdk, radeon 5850, 64bit  ubuntu 11.04

any ideas what could be wrong?

Did you underclock your memory? From what I did observe it seems as hashkill can suffer a noticable performance impact if memory is downclocked.

[fasti]

About the dropping GPU randomly... My 6950 seems to sometimes hop from 77-> 80 for one second and then go back to 77, increasing fan speed in the same time. Maybe hashkill for some reason detects this spiky(maybe more than 80c) temperature measure and shuts GPU down?

[gat3way]

Default thermal throttling value is 90C and there should be a warning displayed about that. I will investigate that GPU dropping issue as I haven't reproduced it yet.

Lowering mem clock should not affect performance as we use just 4 bytes of video memory. I can experiment with that though since we're also able to use host-accessible memory for that. However, since I use my machines for hash cracking too (where a lot more video memory is required) I can't afford to flash my GPU bios and extremely underclock memory just for testing.

[dudel42]

hi,

Running the latest version here with:

./hashkill-gpu -G2 -D -p bitcoin xxx:xxx:xx...

However I get a little less MH/s than with phoenix (~275), and lots of stales?

Speed: 270 MHash/sec [proc: 86] [subm: 70] [stale: 22] [eff: 81%]

2.4 sdk, radeon 5850, 64bit  ubuntu 11.04

any ideas what could be wrong?

Did you underclock your memory? From what I did observe it seems as hashkill can suffer a noticable performance impact if memory is downclocked.

nope, running 5850 with stock clock/mem, haven't had time yet to play around with the clocks...

[dudel42]

how can one run hashkill without being logged on the desktop?

I want to move the system somewhere without a monitor attached, and I can't start hashkill in the ssh session when I'm not also logged in on the console...

[xen82]

I tried the latest build of hashkill on my dual 6990 setup and I'm blown away with the performance. I think it's a great tool and look forward to see where things will be headed. I have been having trouble with connectivity to btcguild.com Phoenix 1.48 has been running rock stable (although with 10% lower speeds), so I think there must be some LP issues there.

One thing I've seen is LOTS of stales. When I used the latest hashkill with deepbit, I noticed I had 7% stales, that's plain crazy. I've tried tinkering with clock speeds, cooling other pools, nothing really helps to resolve this.

If that would be resolved the following would make hashkill slaughter the competition:

• config file
• some type of RPC (JSON-RPC anyone) interface for managing operation and querying status of miners (hash speed, temp, pause resume queue, etc)
• ability to adjust fan speeds automatically and provide ability to set min and max speeds per card
• either prioritize workloads per GPU or per GPU temperature... it would be good for long term operations to have all the GPUs working at the same temperature
• an aggressiveness setting

If a solid RPC based management interface would be implemented with queue/workload management than I would be willing to put in some time to write the tedious interface bits in python