Topic: hashkill - testing bitcoin miner plugin - page 13. (Read 90966 times)

Thank you gat3way for the explainations, I need some clarifications, though:
How can this be possible...?
And anyway why there is difference between processed and submitted?

What is "abnormally high"?
It would be very useful to know the number of "real" stale shares and the invalid ones to diagnose hw problems.
For example, I've an efficiency of around only 90%: is this an "abnormally low" number?
(I suspect it should be near 100%)

Thanks in advance!

cur % is the percentage of the keyspace of the current getwork already calculated and checked. You have ~ 4 billion possible nonces per getwork that need to be tried. 50% would mean that we are currently trying nonce ~ 2 billion.

subm is the number of successfully submitted shares. It might be higher, lower or equal to the number of processed getworks.

stale is not quite appropriate as it includes both stale and invalid shares. Under normal circumstances, there shouldn't be any invalid ones, however with higher temperatures and too much OC, it is possible that the hardware starts calculating hashes incorrectly. Abnormally high stale numbers mean that there are hardware problems.

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!

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.

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

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:


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.

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

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.

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?

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.

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.

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

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.

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?

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)

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

Two 5870s

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"

What GPU do you have, bolapara?

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