hashkill - testing bitcoin miner plugin

[Gnaffel]

BTW...performance is more stable with -D if you switch from ondemand to performance cpu governor. I am not sure the increased CPU power consumption is worth this though.

I have run it for 30 mintutes with minor desktop/mouse lag, near to none
Before i had a stable 75Mhash/s
now:
without the -D or -G1  between 75-77Mhash/s
with -G1 or G2 and -D ~78Mhash/s - Speed: 78 MHash/sec [cur: 68%] [proc: 9] [subm: 7] [stale: 4] [eff: 77%]
Maybe the high stale rate is a fluke, must run it longer to know for shure

(where do i change ondemand to performance cpu governor in hashkill)

[gat3way]

It's not hashkill.

Just do smth like:

echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

[bolapara]

Hmmm, trying to use the latest version with SDK 2.4 and I get this:

Code:

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

[gat3way]

What GPU do you have, bolapara?

[Gnaffel]

How much cpu power is used when mining on gpu? Is hashkill using this for mining performance or goes this to desktop taskst. I rather have my cpu set to powersave mode, but for a better and stable desktop performance i will increase it in steps until it runs smoothly. Maybe setting this to performance mode is a little to much. I will try different modes and see if it makes really difference.
used: sudo sh -c "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"

[bolapara]

What GPU do you have, bolapara?

Two 5870s

[gat3way]

Hmm you did not forget to do sudo ./install.sh, not just ./install.sh ?

[bolapara]

Hmm you did not forget to do sudo ./install.sh, not just ./install.sh ?

Nope.

It'll work if I change the SDK to 2.3.  But with 2.4 it will not work at all.

(2.3 is slow for me)

[gat3way]

Yeah, there are some optimizations in the kernel, specific for 2.4 SDK. It should not be failing to build the kernel though, that's rather strange. Did you install the icd-registration.tgz stuff from 2.4?

[Gnaffel]

BTW...performance is more stable with -D if you switch from ondemand to performance cpu governor. I am not sure the increased CPU power consumption is worth this though.

I have played around with ondemand-performance-powersave cpufreqs, but i dont see any big differences at first eye.
Hashkill cpu usage is between 2%-4%, when i dont use desktop apps. Compared to poclbm cpu usage around 46%, same conditions.

[bolapara]

Yeah, there are some optimizations in the kernel, specific for 2.4 SDK. It should not be failing to build the kernel though, that's rather strange. Did you install the icd-registration.tgz stuff from 2.4?

Yeah.  Just verified it's contents are in /etc/OpenCL/vendors - it is..  No change.

[gat3way]

Hmmmm...perhaps I should add a build log output option. That's rather strange indeed, it's a generic one and there should be no reason it fails on 5870 while compiling on 5570 for example....

Ah I see now...you are reaching a hardcoded limit for a binary size. OK this will be fixed.

[allinvain]

BTW...performance is more stable with -D if you switch from ondemand to performance cpu governor. I am not sure the increased CPU power consumption is worth this though.

I have played around with ondemand-performance-powersave cpufreqs, but i dont see any big differences at first eye.
Hashkill cpu usage is between 2%-4%, when i dont use desktop apps. Compared to poclbm cpu usage around 46%, same conditions.

wow really..for this alone I am dying to see a windows build I'd really love to swap out poclbm for hashkill if it means no more 100% cpu usage.

[bolapara]

Hmmmm...perhaps I should add a build log output option. That's rather strange indeed, it's a generic one and there should be no reason it fails on 5870 while compiling on 5570 for example....

Ah I see now...you are reaching a hardcoded limit for a binary size. OK this will be fixed.

I don't think this is for me, at least...

I ran an strace on hashkill and it appears that it may be dying while trying to run clc?  I look a little further and it appears my 2.4 SDK doesn't have a clc binary in bin/x86_64 (or at all).  Something may be up with my SDK.  I re-downloaded it and see the same thing.  Am I missing something here?

Edit:  More research shows that they removed clc from the 2.4 SDK.  Does hashkill still need it?

[gat3way]

It should never ever try to run clc alone. clc is invoked (was invoked) by the OpenCL runtime itself. With 2.4, clc is deprecated and it should be not exec'd at all.

Hm it could be somehow trying to use an older SDK. Please check again what the LD_LIBRARY_PATH variable contains (it is the only envvar you need with 2.4 as ATISTREAMSDKROOT one was deprecated). Also, you can check the SDK version in effect by doing:

ldd /usr/bin/hashkill |grep OpenCL

this will print out the exact path to the OpenCL library used.


As for the CPU usage - there are a couple of potential causes for this. One is the SDK itself as it uses spinlocks for synchronization. On linux, there is an environment variable that overrides that behavior, which is set automatically by hashkill. It works on most occasions, but I have seen this failing on some systems though for no apparent reason. On windows, that variable is not available.

Another reason would be the miner itself. I have tried to minimize CPU usage, but indeed there is nothing you can do if the root cause for that is the SDK.

P.S you are advised to play with -G1/-G2/-D flags until you find the ones that best work for you. Basically, -G2 -D tends to be fastest on most systems, but sometimes they may not be optimal.

Unfortunately, windows version is not planned soon.

[bolapara]

It should never ever try to run clc alone. clc is invoked (was invoked) by the OpenCL runtime itself. With 2.4, clc is deprecated and it should be not exec'd at all.

Hm it could be somehow trying to use an older SDK. Please check again what the LD_LIBRARY_PATH variable contains (it is the only envvar you need with 2.4 as ATISTREAMSDKROOT one was deprecated). Also, you can check the SDK version in effect by doing:

ldd /usr/bin/hashkill |grep OpenCL

this will print out the exact path to the OpenCL library used.

ldd reports I'm using 2.4 as expected..  I'm confused.

[StinkiePhish]

Many thanks for sharing this software.  I have it running a box with 5770x2 and a 5870 and is generating beautifully.  On another machine, I have a 5970 and a 5870, and the Speed is being displayed incorrectly:

Code:

[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] GPU0: ATI Radeon HD 5800 Series  [busy:0%] [temp:50C]
[hashkill] Temperature threshold set to 90 degrees C
[hashkill] This plugin supports GPU acceleration.
[hashkill] Initialized hash indexes
[hashkill] Initialized thread mutexes
[hashkill] Spawned worker threads
[hashkill] Successfully connected and authorized at btcmine.com:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 349352
[hashkill] Doing BFI_INT magic...

Mining statistics...
Speed: 172 MHash/sec [cur: 24%] [proc: 128] [subm: 98] [stale: 3] [eff: 76%]     

The "proc" and "subm" are going up, indicating that it is submitting shares near the expected speed.  "aticonfig --odgc --adapter=all" returns that all GPUs are being fully used.

I have attempted with and without -D and -G 1 to -G 4 with no change on the display.  I am running ATI SDK 2.4 on Ubuntu 10.10, Intel Xeon 3.0 GHz, 8 GB RAM.

[Rush]

I have just tried hashkill and I have two issues with it:
1) First time I was testing it, it encountered some connection issue and went down - I think it should try to reconnect and not require running it in a loop
2) It runs bad when the output is redirected to a file, for example:

Code:

hashkill-gpu <options> &> hashkill.log

I wasn't able to run it at all in this way with it spamming a lot of messages for not being able to get stuff for bitcoin.pool.dashjr.org

Otherwise, it has great speeds with my 6870 - 305Mhs at 990Mhz. That's 8Mhs better than phoenix with phatk!!

[gat3way]

It should reconnect unless it's the first connection attempt in which case it bails out (as most likely it's due to bad hostname/port). Retry period is 20 seconds.

As for the file redirection, this will never happen as it is rather inconvinient to parse. While I am planning and building a mining rig at home, I am currently extending it to dump status data in a text file in a specific (more easily parsable) format to be used by a couple of monitoring scripts with a web frontend and mail notifications. Still don't know what portion of it will be released though - as I am doing this mostly for my personal use and don't have enough time. Probably only the status exports.

[Dusty]

I'm sorry if it has been asked before, but I can't understand the meaning of "cur%" and why the difference from processed and submitted blocks.

Someone cares to explain me?

Thanks!