hashkill - testing bitcoin miner plugin

[gfaust]

I'm running dual 5830s on my test machine clocked at 875,900.  Also using the latest ubuntu 11.04 x64, sdk 2.4 and catalyst 11.6.

using Deepbit pool, hashkill is delivering about 433Mhash/sec but phoenix 1.5/phatk is delivering about 528Mhash/sec.  Should I be using an earlier driver?  I tried playing with -D, -G1, -G2, -G3, -G4.  Is there anything else I can try to duplicate the results other folks have had?

[kripz]

After a random amount of time hashkill will crash with this:

Mining statistics...
Speed: 171 MHash/sec [proc: 8] [subm: 5] [stale: 1] [eff: 62%]     [error] (ocl_bitcoin.c:141) Cannot authenticate!

Using phoenix it's 100% stable. How can i debug?

[gat3way]

After a random amount of time hashkill will crash with this:

Mining statistics...
Speed: 171 MHash/sec [proc: 8] [subm: 5] [stale: 1] [eff: 62%]     [error] (ocl_bitcoin.c:141) Cannot authenticate!

Using phoenix it's 100% stable. How can i debug?

kripz you can reproduce it with the latest release? Also did you change your worker password in that timeframe?

[kripz]

I'm using version 0.2.5, is that the latest? You have 0.2.4 in the OP.

Password has never changed.

Edit:

Ran for longer today

Speed: 173 MHash/sec [proc: 394] [subm: 294] [stale: 60] [eff: 74%]     [error] (ocl_bitcoin.c:141) Cannot authenticate!

[figvam]

Pre-compiled 0.2.4 binaries do not run under Fedora 14:
./hashkill-gpu: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory

I compiled 0.2.4 with AMD APP 2.4, and substituted bitcoin.so from the binary distribution. It looks like hashkill itself is working, but the bitcoin plugin errors out (can't see GPU):

$ ./hashkill -p bitcoin xxxxxxxxxxxxx
[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Total physical memory : 3018 MB
[hashkill] Detected 2 CPUs.
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - ATI RV730
[hashkill] Using 4xxx codepath
[hashkill] Loading markov statfile (rockyou)
[hashkill] Threads queue size: 128 plaintexts/thread
[hashkill] Initialized thread mutexes
[hashkill] Initialized hash bitmaps
[hashkill] Spawned worker threads
[hashkill] Launching Markov attack
[hashkill] Markov max len: 10 threshold:1000
[hashkill] Progress indicator will be available once Markov calculations are done...
[hashkill] SSE2 accelerated routines available
[hashkill] Attack has non-linear complexity
[error] (bitcoin.c:86) This plugin is GPU only!


environment:
$ env|grep AMD
LD_LIBRARY_PATH=/opt/AMD-APP-SDK-v2.4-lnx32/lib/x86/
ATISTREAMSDKROOT=/opt/AMD-APP-SDK-v2.4-lnx32/
OPENCL_VENDOR_PATH=/opt/AMD-APP-SDK-v2.4-lnx32/etc/OpenCL/vendors/

[gat3way]

Prior to ./configure, export ATISTREAMSDKROOT to point to your APP SDK directory and ADLROOT to point to your ADL sources and it should be OK. The ADLROOT part is not mandatory but you would lose the thermal monitoring support.

P.S libcrypto.so.0.9.8 comes with openssl.

[figvam]

Prior to ./configure, export ATISTREAMSDKROOT to point to your APP SDK directory

That's what I did, see my environment. hashkill has no trouble loading APP SDK. Maybe it's something to do with APP SDK being statically compiled into bitcoin.so?

and ADLROOT to point to your ADL sources and it should be OK. The ADLROOT part is not mandatory but you would lose the thermal monitoring support.

My card is a mobile Radeon 4650, it doesn't have a thermal monitoring, so I assume ADL isn't needed at all.

P.S libcrypto.so.0.9.8 comes with openssl.

Fedora has much newer openssl:
$ rpm -q openssl
openssl-1.0.0d-1.fc14.i686
$ rpm -ql openssl |fgrep libcrypto
/lib/.libcrypto.so.1.0.0d.hmac
/lib/.libcrypto.so.10.hmac
/lib/libcrypto.so.1.0.0d
/lib/libcrypto.so.10

[gat3way]

Nope, it is impossible to link statically against the SDK as it provides .so only.  This is rather strange - and my guess is that sources on sf.net are out of sync with my copy.

OK - we can do the following: I will upload the openssl library from my system - you may download it and copy to /usr/lib, the try again the precompiled version:

http://www.gat3way.eu/poc/libcrypto.so.0.9.8

[spiccioli]

gat3way,

I've made several more tests with hashkill the other night, on my system (running linuxcoin 0.2a from USB stick) I underclock memory (dual sapphire 5850 at 885/295 core/mem at 1.08V) to save energy, with these settings latest hashkill-gpu gives 555-560 MHash/s

Same pc, same settings, two instances of phoenix give around 350-352 MHash/s _each_.

If I increase memory speed hashkill increases output, but around 620MHash/s (885/470-500) system locks up solid, so maybe my cards can't overclock core and memory at the same time (they're stock cards, no changes to bios).

Do you know what makes hashkill slower on such a system? Is there something (apart from rising memory clock) which you can change in hashkill to be able to run it on GPUs with underclocked memory ?

I like the idea of a single miner handling all GPUs and I'm tired of phoenix hangings, but losing 150MHash/s is a little too much

TIA

spiccioli.

[gat3way]

I have no idea, but yes - hashkill tends to generate underperforming code on some hardware/SDK combinations. My best advice would be to use SDK2.4. Any older one increase the chance of fucking it up and it would like not work at all with SDK 2.1.

[Gary13579]

Hey guys, I've figured out an edge case bug on some networks which can cause a very large amount of stale shares, up to 30%. The problem is that hashkill uses curl to open a connection to the longpolling server, and it idles on that connection until a new block is available. This is fine and dandy, but a lot of networks and firewalls will kill a connection if it has been idle for a certain amount of time. This was set to 10 minutes on my network. This meant that every time a block went for longer than 10 minutes, longpolling would break and you'd submit a bunch of stale shares not knowing they are stale.

A fix for this should be coming in hashkill as it's a very simple thing to fix, ~5 lines of code. Until then you can run the following command to fix it (note that it must be ran as root):

[root@snuggles]# echo "300" > /proc/sys/net/ipv4/tcp_keepalive_time

This sets the keepalive time to be 5 minutes, which means every 5 minutes, your Linux box will send an empty packet to the server which keeps the connection alive. Adjust this value based on your network/firewall configuration.

[kripz]

could be related to my bug where it randomly says cannot authenticate, ill try it when i get home.

[figvam]

Nope, it is impossible to link statically against the SDK as it provides .so only.  This is rather strange - and my guess is that sources on sf.net are out of sync with my copy.

I took both the sources and the binary from your site, not from sf.net. But yes, looks like the binary plugin is having trouble communicating with the program compiled from sources.

OK - we can do the following: I will upload the openssl library from my system - you may download it and copy to /usr/lib, the try again the precompiled version:

http://www.gat3way.eu/poc/libcrypto.so.0.9.8

I'll need libssl.so.0.9.8, too. Thanks.

[Gary13579]

could be related to my bug where it randomly says cannot authenticate, ill try it when i get home.

It shouldn't help, but I suggest trying it anyway.

Edit: actually, I'm positive that it won't help. What pool are you using? I'd try btcguild.

Nope, it is impossible to link statically against the SDK as it provides .so only.  This is rather strange - and my guess is that sources on sf.net are out of sync with my copy.

I took both the sources and the binary from your site, not from sf.net. But yes, looks like the binary plugin is having trouble communicating with the program compiled from sources.

OK - we can do the following: I will upload the openssl library from my system - you may download it and copy to /usr/lib, the try again the precompiled version:

http://www.gat3way.eu/poc/libcrypto.so.0.9.8

I'll need libssl.so.0.9.8, too. Thanks.

You don't need 0.9.8, I'm running it just fine with 1.0.0 on Arch Linux.


[gary@snuggles lib]$ ls -lah /usr/lib/ | grep libcrypto
-rw-r--r--   1 root root 3.5M Feb  8 12:58 libcrypto.a
lrwxrwxrwx   1 root root   18 Feb  8 12:58 libcrypto.so -> libcrypto.so.1.0.0
-r-xr-xr-x   1 root root 2.0M Feb  8 12:58 libcrypto.so.1.0.0


I suggest manually symlinking libcrypto.so and libssl.so to the latest versions (which would be libcrypto.so.1.0.0d and libssl.so..1.0.0d on Fedora, apparently).

sudo ln -s /lib/libcrypto.so /lib/libcrypto.so.1.0.0d
sudo ln -s /lib/libssl.so /lib/libssl.so.1.0.0d

if that doesn't work, rm them and try symlinking against .so.10. Or switch to a distro that doesn't suck

[kripz]

Didnt work as you said, is hashkill open source?

[spiccioli]

I have no idea, but yes - hashkill tends to generate underperforming code on some hardware/SDK combinations. My best advice would be to use SDK2.4. Any older one increase the chance of fucking it up and it would like not work at all with SDK 2.1.

gat3way,

linuxcoin has SDK2.4 only, so it has to be something else, sadly.

best regards.

spiccioli.

[figvam]

I got the binary build running by symlinking the libs. However it's much slower than any of the poclbm-based miners: 24-25Mh/sec vs 29Mh for poclbm. Perhaps non-surprising on the 4xxx hardware.

[gat3way]

Yeah, the 4xxx codepath is not optimized very well.

P.S tried the -D switch?

[figvam]

No, I haven't - the desktop responsiveness was horrible even without it.

[sniper_sniperson]

Under a custom build Slax from slax.org (x64 Slackware 2.6.27.27 is the kernel) I've got this error:

bash: /usr/bin/hashkill-cpu: cannot execute binary file

What exactly I need to run it under this lovely OS (yeah, it's better than Ubuntu, I swear)