Bitcoin Forum
March 05, 2021, 10:36:13 AM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [All]
  Print  
Author Topic: hashkill - testing bitcoin miner plugin  (Read 90549 times)
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 29, 2011, 11:29:33 PM
Last edit: June 07, 2011, 10:25:32 AM by gat3way
#1

Hello,

I am developing an opensource linux CPU/GPU hash cracker and recently got introduced to bitcoin world and decided to write a bitcoin miner as part of my program (as I can reuse most of my sha256 code).

My bitcoin plugin is in alpha stage, but it already does some pretty handy stuff, e.g:

* Does BFI_INT patching
* Is extremely optimized using some optimization tricks I borrowed from my sha256 plugin (40 GPRs, less than 2890 ALU ops and over 97% ALUPacking on 6870 - it's VLIW5)
* Supports multi-gpu configurations (no need to run separate instances for each device)
* Supports NVidia and ATI (4xxx support is broken though for some reason I have yet not identified)
* Supports long polling
* Does not quit on connection failure, instead it retries after 20 seconds
* Has a relatively smart getwork asking mechanism that does not generate much network traffic and is suitable for pools like bitcoinpool.com where efficiency is important
* Integrated support for getting stats from pools (currently only bitcoinpool.com, deepbit.net and mining.bitcoin.cz)
* Is simple to use
* Preserves high performance without sacrificing desktop responsiveness

It is in alpha stage and at that point I prefer not to release the source of the plugin (except the kernels that look ugly Smiley ). Nevertheless, I have compiled a x86_64 binary, statically linked (so that you don't have to deal with dependency issues):

64bit:
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

Installation is simple - just run sudo ./install.sh (it requires superuser privileges in order to copy the plugins and kernels to /usr/share/)

Usage is also simple, just run:

hashkill-gpu -p bitcoin user:password:host:port [-a addopts]

e.g

hashkill-gpu -p bitcoin gat3way:mypassword:bitcoinpool.com:8334 -a gat3way

tested with bitcoinpool.com, deepbit.net and mining.bitcoinpool.cz

the -a option provides a way to get stats from the pool, you need to provide your API key or your username (bitcoinpool.com). If you do that, you get stats on curreent reward by pressing the enter key while mining.


You can try it if interested. BTW it is very fast, probably among the fastest miners out there. I did some tests with the latest versions of poclbm, phoenix and hashkill on my 6870 card (stock clocks) and the results are:

Quote
hashkill: 271M/s
poclbm (-f1 -w128 -v) : 263M/s
phoenix (BFI_INT VECTORS AGGRESSION=11 FASTLOOP): 256M/s

There is a screenshot:

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1614940573
Hero Member
*
Offline Offline

Posts: 1614940573

View Profile Personal Message (Offline)

Ignore
1614940573
Reply with quote  #2

1614940573
Report to moderator
Tyran
Newbie
*
Offline Offline

Activity: 40
Merit: 0


View Profile
April 30, 2011, 12:31:16 AM
#2

This kernel should be about 10% faster than the phoenix/poclbm one according to AMD's kernel analyzer, but I'm currently on windows so I can't use your binary and I can't figure out what the inputs are to try it with a different miner :p
ghost
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
April 30, 2011, 12:40:35 AM
#3

No 32-bit binary?
JWU42
Legendary
*
Offline Offline

Activity: 1666
Merit: 1000


View Profile
April 30, 2011, 12:54:28 AM
#4

Code:
jw@Krypton:~/BTC/hashkill-0.2.4-x86_64$ hashkill-gpu
hashkill-gpu: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory

LD_LIBRARY_PATH is set in .bashrc and have no issues running poclbm or phoenix FWIW

fpgaminer
Hero Member
*****
Offline Offline

Activity: 560
Merit: 505



View Profile WWW
April 30, 2011, 01:04:51 AM
Last edit: April 30, 2011, 01:45:42 AM by fpgaminer
#5

Quote
phoenix (BFI_INT VECTORS AGGRESSION=11 FASTLOOP): 256M/s
You're not using phoenix correctly. FASTLOOP only works correctly for AGGRESSION < 8. Remove the FASTLOOP argument and retest.

EDIT: You also don't specify the worksize for phoenix. Not sure what that card needs (I'm guessing 128 by the poclbm command you posted).

Zamicol
Newbie
*
Offline Offline

Activity: 56
Merit: 0



View Profile
April 30, 2011, 05:56:24 AM
#6

Code:
jw@Krypton:~/BTC/hashkill-0.2.4-x86_64$ hashkill-gpu
hashkill-gpu: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory

LD_LIBRARY_PATH is set in .bashrc and have no issues running poclbm or phoenix FWIW



I'm having the same issue. 
zoro
Full Member
***
Offline Offline

Activity: 226
Merit: 100


View Profile
April 30, 2011, 06:16:38 AM
#7

ca we have it in windows plz? Smiley

"killer app" of BTC = MasterCoin https://bitcointalk.org/index.php?topic=265488.0Mastercoin(A new protocol layer on top of Bitcoin)
xyzzy
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
April 30, 2011, 07:14:19 AM
#8

Code:
jw@Krypton:~/BTC/hashkill-0.2.4-x86_64$ hashkill-gpu
hashkill-gpu: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory

LD_LIBRARY_PATH is set in .bashrc and have no issues running poclbm or phoenix FWIW


Code:
cd /opt/ati-stream-sdk-v2.1-lnx64/lib/x86_64/lib; sudo ln -s libOpenCL.so libOpenCL.so.1

I get a bit farther than that, but have a different problem:

Quote
crunch@crunch:~/hashkill-0.2.4-x86_64$ uname -a
Linux crunch 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 GNU/Linux
crunch@crunch:~/hashkill-0.2.4-x86_64$ ./hashkill-gpu -p bitcoin xxxx:xxx:deepbit.net:8332

[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Juniper
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] This plugin supports GPU acceleration.
[hashkill] Initialized hash indexes
[hashkill] Initialized thread mutexes
[hashkill] Spawned worker threads
[hashkill] Successfully connected and authorized at deepbit.net:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)[error] (ocl_bitcoin.c:923) clBuildProgram error (-11)
[hashkill] Attack took 12 seconds.
[hashkill] Bye bye Smiley
stakhanov
Full Member
***
Offline Offline

Activity: 175
Merit: 100


View Profile
April 30, 2011, 07:47:50 AM
Last edit: April 30, 2011, 09:16:27 AM by stakhanov
#9

[hashkill] Attack took 12 seconds.
[hashkill] Bye bye Smiley


ಠ_ಠ
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
April 30, 2011, 07:57:53 AM
#10


[hashkill] Attack took 12 seconds.
[hashkill] Bye bye Smiley

ಠ_ಠ
[/quote]

oh my... Shocked
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 30, 2011, 09:13:06 AM
#11

Hello,

The dependance on OpenCL.so.1 is my mistake, I have built it against SDK 2.4 and should fix that. A quick workaround would be to create a symlink libOpenCL.so -> libOpenCL.so.1. Also, it may not work with SDK < 2.3 cause I set some environment variables introduced in 2.3 to speed up host-device transfers a bit and properly support multi-GPU without 100% CPU load

Quote
[hashkill] Attack took 12 seconds.
[hashkill] Bye bye

Yeah, this comes from the fact that the tool is a hash cracker anyway Smiley the bitcoin functionality is a testing one and yet has not been integrated properly yet so in this case we're reusing the generic deinitialization routine used for the hash cracking code. As I said, it's still an alpha, there are many things that need to be done before it reaches release quality Smiley


As for 32-bit version, there are some issues with cross-compilation at that moment that I am working on currently. Should be ready in 1-2 days.

As for windows version - not planned, sorry.
commlinx
Full Member
***
Offline Offline

Activity: 294
Merit: 100



View Profile
April 30, 2011, 09:13:57 AM
#12

I suspect that message is generic because he's reused hash cracker code and it's part of the standard exit code to say how long the "attack" on the hash took, and it exited because of the error instead of requesting more work. Otherwise putting that error would't be a very smart piece of social engineering, would have been much better to report a higher than normal hash rate and then fake a crash reporting it back to the server to get more people to try.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3472
Merit: 1638



View Profile
April 30, 2011, 09:32:51 AM
#13


Quote
I am developing an opensource linux CPU/GPU hash cracker ....

Quote
at that point I prefer not to release the source of the plugin

So is it open source is isn't it?

I'm not going near this until more eyes have been over it ... like more than yours. Hope it is for real, sounds too good to be true in some ways.

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 30, 2011, 09:37:15 AM
#14

The source of the plugin will be available once it reaches "production" quality, right now I would be a bit embarassed to put it in public, cause it's ugly Smiley I need some more test feedback though as I don't have the variety of hardware to test...
bitcoincomes
Newbie
*
Offline Offline

Activity: 15
Merit: 0



View Profile WWW
April 30, 2011, 09:40:02 AM
#15

I am also getting the error:

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

I am running ubuntu 10.10 with SDK 2.1

Thanks.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 30, 2011, 09:46:26 AM
Last edit: April 30, 2011, 10:03:05 AM by gat3way
#16

Please try it with SDK 2.3 (or later, but since 2.4 updates the ICD files, I would recommend 2.3). It is relatively safe and compatible with 2.1 - you just download and unpack it and point LD_LIBRARY_PATH to SDK2.3's library path.

Anyway, peak performance would be achieved with 2.4 as the compiler aggressively optimizes some parts of the code, lowering the number of ALU instructions needed.

SDK 2.1 is too old...it has no OpenCL 1.1 support and is not thread-safe. It has also other problems, e.g rotate() not generating BIT_ALIGN_INT instructions and stuff.

P.S retested phoenix with WORKSIZE=128 and without FASTLOOP. It is indeed faster, in fact as fast as poclbm (263M/s). hashkill is still faster at 271M/s Smiley
nster
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
April 30, 2011, 10:41:28 AM
#17

how hard would it be to make a windows version?  I'm sure people would contribute a few btc for it if it really is faster than poclbm

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 30, 2011, 11:06:55 AM
#18

Well it would require code changes as well as changes in the autoconf/automake part to build properly on windows/cygwin cause right now it depends a lot on some linux specific stuff (like procfs and/or some linux-specific API functions). However, windows version is not in my near plans. It is more likely that an MacOSX port will be done first as I had such requests for the hash cracker and it would be relatively easy. Porting to windows would be much more difficult though.
Convery
Sr. Member
****
Offline Offline

Activity: 966
Merit: 254



View Profile
April 30, 2011, 11:15:17 AM
#19

Porting to windows would be much more difficult though.

I'm sure that someone can do that for you when you release the source to a stable version :3


             ▄          ▄▄▄▄    ▄
            ███      ▄██████▀  ▀█▀
            ███     ▄██▀
            ███     ███        ▄█▄   ▄█▄ ▄█████▄▄         ▄▄██████▄      ▄█▄ ▄█████▄▄         ▄▄█████▄▄        ▄▄█████▄▄
    ▄▄▄▄▄▄  ███     ███        ███   ██████▀▀▀▀███▄     ▄███▀▀▀▀▀███▄    ██████▀▀▀▀███▄     ▄███▀▀▀▀▀███▄    ▄███▀▀▀▀▀███▄
  ▄████████▄███  ▄█████████▄   ███   ████▀      ▀███   ▄██▀       ▀██▄   ████▀      ▀███   ▄██▀       ▀█▀   ▄██▀       ▀██▄
▄███▀    ▀█████   ▀▀███▀▀▀▀    ███   ███         ███   ███         ███   ███         ███   ███              ███████████████
███   ▄▄   ▀███     ███        ███   ███         ███   ███         ███   ███         ███   ███              ███▀▀▀▀▀▀▀▀▀▀▀
███   ▀▀   ▄███     ███        ███   ███         ███   ███         ███   ███         ███   ███         ▄    ███         ▄
▀███▄    ▄█████     ███        ███   ███         ███    ███▄▄   ▄▄████   ███         ███    ███▄▄    ▄███    ███▄▄   ▄▄███
  ▀████████▀███     ███        ███   ███         ███     ▀████████▀███   ███         ███     ▀█████████▀      ▀█████████▀
    ▀▀▀▀▀▀   ▀       ▀          ▀     ▀           ▀         ▀▀▀▀▀   ▀     ▀           ▀         ▀▀▀▀▀            ▀▀▀▀▀

       ▄▄▄▄▄▄▄
   ▄▄▀▀       ▀▀▄▄
  █               █ ▄
 █   █▀▄ ▀█▀ ▀█▀   █ ▀▄
 █   █▀▄  █   █    █  ▀▄
  █  ▀▀   ▀   ▀   █    █
▄▀ ▄▄           ▄▀    ▄▀
 ▀▀  ▀▀▄▄▄▄▄▄▄▀▀      ▀▄
        ▀▄▄      ▄▄▀▀▄▄▀
           ▀▀▀▀▀▀

                      ▄▄▄
  ▄█▄              ▄███████▄
  ▀████▄▄         ██████▀██████▀
    ▀▀▀████▄▄     ███████████▀
    ▀██▄███████▄▄███████████
     ▄▄▄▀██████████████████
      ▀████████████████████
▀█▄▄     ▀████████████████
  ▀████████████████▀█████
    ▀████████████▀▄▄███▀
       ▀▀██████████▀▀
           ▀▀▀▀▀

               ▄▄   ▄▄
              ▄▀ ▀▀█  █
             ▄▀     ▀▀
         ▄▄▄▄█▄
     ▄█▀▀▀▀▀▀▀▀▀▀█▄
 ▄▀▄▀              ▀▄▀▄
█  █   ▄█▄    ▄█▄   █  █
 ▀█    ▀█▀    ▀█▀    █▀
  █                  █
   █   ▀▄      ▄▀   █
    ▀▄   ▀▀▀▀▀▀   ▄▀
      ▀▀▄▄▄▄▄▄▄▄▀▀
New Age of DEFI
A Non-Code Platform for
Decentralized Trading Instruments

   ▄▄███████████████▄▄
 ▄█████████████████████▄
▄██████████████▀▀███████▄
████████████▀▀    ███████
█████████▀▀   ▄   ███████
██████▀▀     █    ███████
████▀       █     ███████
█████▄▄   ▄█      ███████
████████ ██▄      ███████
▀████████ ▀▄███▄▄███████▀
 ▀█████████████████████▀
   ▀▀███████████████▀▀

     ▄              ▄
   ▄███▄          ▄███▄
   █████▄  ▄▄▄▄  ▄█████
  ▄████████████████████▄
 ▄██████████████████████▄
 ████████████████████████
██████▀▀          ▀▀██████
█████▀   ▄      ▄   ▀█████
 ████   ███    ███   ████
  ████   ▀      ▀   ████
   ▀████▄▄▄▄▄▄▄▄▄▄████▀
     ▀▀████████████▀▀

   ▄▄████████████████▄▄
 ▄█████▀▀▀██████▀▀▀█████▄
▄████▀  ▀▀▀    ▀▀▀  ▀████▄
████▀                ▀████
███▀                  ▀███
███       ▄    ▄       ███
██▀      ███  ███      ▀██
██       ▀█▀  ▀█▀       ██
██▄     ▄        ▄     ▄██
▀██▄     ▀▀▄▄▄▄▀▀     ███▀
 ▀███▄▄▄▄▄▄████▄▄▄▄▄▄███▀
   ▀▀████████████████▀▀
Pieter Wuille
Legendary
*
Offline Offline

Activity: 1064
Merit: 1067


View Profile WWW
April 30, 2011, 11:38:21 AM
#20

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] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] This plugin supports GPU acceleration.
[hashkill] Initialized hash indexes
[hashkill] Initialized thread mutexes
[hashkill] Spawned worker threads
[hashkill] Successfully connected and authorized at mining.bitcoin.cz:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 457180
[hashkill] Doing BFI_INT magic...

Mining statistics...
Speed: -1478477178 MPlaintexts/sec [cur: 62%] [proc: 20] [subm: 30] [stale: 0] [eff: 150%]     

I do Bitcoin stuff.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 30, 2011, 11:49:31 AM
#21

That's weird. Does the pool report submitted shares?

Ah, I see now - it uses signed int and you're mining faster than 2G per 3s. OK, fixing that now...
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 30, 2011, 12:59:14 PM
#22

OK - fixed some stuff and rebuilt.

The progress indicator issue should be gone.
Removed dependency on OpenCL.so.1 so that it can be run with older SDKs
Built a 32-bit static-linked binary

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
twitcoins
Newbie
*
Offline Offline

Activity: 39
Merit: 0


View Profile
April 30, 2011, 02:53:27 PM
#23

I get 312 Mhash/s on both poclbm and phoenix, but only 208 with hashkill.  Any useful information I can grab for you, command line switches to try, etc?

hashkill 0.2.4 x86_64, fglrx 8.801, LD_LIBRARY_PATH points to 2.3
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
April 30, 2011, 04:49:37 PM
#24

Hmm...perhaps an ISA dump would be useful to debug the problem.

You can do that by running export GPU_DUMP_DEVICE_KERNEL=3 prior to running hashkill (you need to be in a writable directory like e.g /tmp).

Then after say 30 seconds, stop execution (ctrl-c) and look for a file named bitcoin_<GPUmodel>.isa (e.g bitcoin_Cypress.isa). Please paste this file contents so that I have a look at it.

P.S. you would need ~ 5-10 seconds until speed peaks at maximum, it usually starts at lower speed and gradually increases. As for switches, you might try -G 3 and/or -D and see if it affects performance positively.

P.S 2: also please do not run the 32-bit version on a 64-bit system: it tends to be way slower. And (again) use SDK 2.3 or newer.
xyzzy
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
April 30, 2011, 10:32:31 PM
#25

Hmm...perhaps an ISA dump would be useful to debug the problem.

You can do that by running export GPU_DUMP_DEVICE_KERNEL=3 prior to running hashkill (you need to be in a writable directory like e.g /tmp).

Then after say 30 seconds, stop execution (ctrl-c) and look for a file named bitcoin_<GPUmodel>.isa (e.g bitcoin_Cypress.isa). Please paste this file contents so that I have a look at it.

I'm not the other guy, but I'm seeing some weird results.  I can't tell *what* performance I'm getting out of your client -- it's showing me very strange results:


Code:
crunch@crunch:/tmp$ hashkill-gpu -p bitcoin xxx:xxx:deepbit.net:8332

[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Juniper
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] This plugin supports GPU acceleration.
[hashkill] Initialized hash indexes
[hashkill] Initialized thread mutexes
[hashkill] Spawned worker threads
[hashkill] Successfully connected and authorized at deepbit.net:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 452144
[hashkill] Doing BFI_INT magic...

Mining statistics...
Speed: 0 MHash/sec [cur: 100%] [proc: 18] [subm: 14] [stale: 0] [eff: 77%]       82%]     
Speed: 402 MHash/sec [cur: 28%] [proc: 18] [subm: 16] [stale: 0] [eff: 88%]      82%]     
Speed: 236 MHash/sec [cur: 100%] [proc: 19] [subm: 16] [stale: 0] [eff: 84%]     88%]     
Speed: 0 MHash/sec [cur: 100%] [proc: 19] [subm: 16] [stale: 0] [eff: 84%]       88%]     
Speed: 6148914690576 MHash/sec [cur: 53%] [proc: 19] [subm: 16] [stale: 0] [eff: 84%]
(etc)   

With 2 5850s and a 5770, I expect to get about 600-700 MHash/sec.  Here are the dumped ISA files:

http://dl.dropbox.com/u/694931/bitcoin_Cypress.isa
http://dl.dropbox.com/u/694931/bitcoin_Juniper.isa

(this is with AMD-APP-SDK-v2.4-lnx64)

Nice work, btw, I like the way it automagically finds all the cards and "deals with it", rather than having to run multiple copies of poclbm.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 01, 2011, 09:15:10 AM
Last edit: May 01, 2011, 09:45:34 AM by gat3way
#26

Hello,

Yes, that's one of the bugs I have collected thanks to people that tested the alpha (related to an integer overflow). Another one found is related to missing deinitialization of certain curl handles that creates big problems after some time spent in mining. Another problem was related to improper BFI_INT replacement on 69xx cards (fixed now). Finally, the 69xx codepath is not optimal and I am now currently working on a separate vliw4 codepath that is best optimized for 69xx devices. Sorry for those, but your input was very helpful for me to identify and fix those issues. A new testing release will be ready soon with those problems resolved.

Another thing is that we're walking on the verge with those uint4 vectors...on my 6870 I'm getting 41 GPR usage currently. If that rises to 42 for some reason, performance degrades disastrously as the number of wavefronts/cu drops. I still need to find a way to reduce the GPR usage - cause on some other cards, the compiler is unable to generate code that keeps to 41GPRs thus generating slow-performing code. Since I am doing that by carefully reordering stuff, it's a bit wacky and not reliable at the moment...still need some work on that.
JWU42
Legendary
*
Offline Offline

Activity: 1666
Merit: 1000


View Profile
May 01, 2011, 11:28:17 AM
#27

@gat3way - will give this a try again...

Those of us with 5970's tend to find 2.1 optimal (i.e., max Hash generation).

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] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] This plugin supports GPU acceleration.
[hashkill] Initialized hash indexes
[hashkill] Initialized thread mutexes
[hashkill] Spawned worker threads
[hashkill] Successfully connected and authorized at deepbit.net:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)[error] (ocl_bitcoin.c:923) clBuildProgram error (-11)
[hashkill] Attack took 4 seconds.
[hashkill] Bye bye :)

Made it further than last time!

colossus
Full Member
***
Offline Offline

Activity: 121
Merit: 100

Obey me and live or disobey and die.


View Profile
May 01, 2011, 05:39:16 PM
#28

 Smiley Works great @gat3way thank you for this, it improved my performance greatly from 220 mhash on Diablo to 267 mhash on your code! i did try your code from a few days ago same version number though Cheesy and after a few hours it would loose the connection and just keep retrying, restart solved the problem, lets see if this new one lasts longer.

PS on a 6870, just over clocked to 950 and now at 286 Mhash... Great Stuff!

PPS post your bitcoin address so people can make donations.

for those curious on app SDK 2.4, using this driver http://www2.ati.com/drivers/linux/ati-driver-installer-11-4-x86.x86_64.run
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 01, 2011, 05:57:18 PM
#29

Just wait, people, there are still lots of bugs I am working on Smiley A new release will be done in a couple of days, hopefully fixing them all. The reconnect issue is due to missing deinitialization of a curl handle and this will definitely be resolved. We still have problems with 6990 and this afternoon I had to rewrite the whole kernel (replacing uint4 with interlaced uint2+uint) to get that GPR thing working reliable on all VLIW5 cards.

elitkalle
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
May 01, 2011, 06:54:20 PM
#30

When i run this: hashkill-cpu -p bitcoin xxxxxxxx:xxxxxxx:bitcoinpool.com:8334

[hashkill] Progress indicator will be available once Markov calculations are done...
[error] (bitcoin.c:86) This plugin is GPU only!

I get that error..
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 02, 2011, 05:54:21 AM
#31

^^ This means you don't have the SDK installed or you haven't done export LD_LIBRARY_PATH=/path/to/sdk/lib/<arch> prior to running it.

You should also make sure the OpenCL runtime detects your GPU - by running the CLInfo sample from the SDK.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 03, 2011, 05:18:35 PM
#32

Fixed a couple of bugs:

* Progress indicator finally fixed
* Kernel reworked - there are separate codepaths, one for VLIW5 (interlaced uint2+uint to get best utilization) and another for VLIW4 architectures. Additional optimizations implemented.
* Added -D command-line option. This tends to increase speed at the cost of reduced desktop responsiveness (kinda like Phoenix AGGRESSION parameter)
* Additional marginal speedup can be achieved by using -G 3 option at the command line (or even -G4) - but that requires more memory and faster, multicore CPU
* the curl handles leak was fixed - no more "connection failed after half an hour of work" issues.

The code changes are confirmed to be incompatible with ATI Stream SDK 2.1 and 2.2. Please _DO NOT_ use older than 2.3 versions.


Not implemented yet:

* ADL thermal monitoring for ATI
* Failover extension (used in deepbit.net)


Download:

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
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 03, 2011, 05:54:41 PM
#33

Tried it out and you are about 90MH/s slower than phoenix 1.4 for me.

ubuntu 10.10 x64 - 5870

hashkill - SDK 2.3 - ~344MH/s
phoenix 1.4 - SDK 2.1 - ~434MH/s
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 03, 2011, 06:18:04 PM
#34

Damn...still that 5870 issue...hmmm wanna have one for tests Sad
colossus
Full Member
***
Offline Offline

Activity: 121
Merit: 100

Obey me and live or disobey and die.


View Profile
May 03, 2011, 07:53:13 PM
#35

Last version ran solid for me 3 days straight 24/7.

Tried the additional options normally my card settles on 283 after while, with the D & G options i can get it to settle at 285.

PS @bolapara how did you get 434 on the 5870, i have one clocked at 850, what is yours at? please share.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 03, 2011, 07:58:15 PM
#36

Apparently, on 5870 for some reason the generated binary is not optimal. If someone with such card (or 5970) is willing to help me test and fix that, please PM me.
colossus
Full Member
***
Offline Offline

Activity: 121
Merit: 100

Obey me and live or disobey and die.


View Profile
May 03, 2011, 10:44:15 PM
#37

I tested my 5870 just now

fresh install of ubu 11.04 x64, catalyst 11.4, sdk 2.4 = 370 mhash on hashkill.

i tried to install phoenix but trashed my system with that awful python-opencl dependency on nvidia driver, why oh why did they package it like that.

I will try to test some more tomorrow against phoenix after i re-install.

bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 04, 2011, 03:47:46 PM
#38

PS @bolapara how did you get 434 on the 5870, i have one clocked at 850, what is yours at? please share.

Dedicated mining rig
Ubuntu 10.10
11.4 drivers, 2.1 SDK
1000 core, 300 mem clocks
100% fan speed
76C
phoenix 1.4 - VECTORS AGGRESSION=12 WORKSIZE=128 BFI_INT
colossus
Full Member
***
Offline Offline

Activity: 121
Merit: 100

Obey me and live or disobey and die.


View Profile
May 04, 2011, 06:29:18 PM
#39

Thanks for that bolapara will give it a go.

i guess you removed the nvidia dependency or compiled it manually for the python pyopencl that is, i will have a go myself tonight.

If i can get phoenix working i will compare side by side
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
May 04, 2011, 06:47:27 PM
#40

Tried it out overnight on deepbit and while it was faster it also ended up with roughly 10% stale shares.  Not sure the long polling is working properly, is it supposed to give any indication when it gets a new block notification?

colossus
Full Member
***
Offline Offline

Activity: 121
Merit: 100

Obey me and live or disobey and die.


View Profile
May 04, 2011, 07:01:03 PM
#41

yeah i also forgot to mention it failed for me after a few hours as well, i've reverted to the previous version, there was no communication problem it just stated 0/mash.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 07:03:25 PM
#42

@bolapara: did you use the -D option?

We just tried hashkill on 5970 (which has the same cores as 5870) and speed was as expected: 620-630M/s at stock speeds. That is with -D applied

@mskwik The stale shares could indicate a problem (e.g bad BFI_INT replacement). What GPU do you have?


As a side note, I got ADL working and I can now correctly get GPU temperatures, activity percent and clocks. Wondering how to proceed with that thermal stuff: should I quit when a threshold is reached....or probably pause for a certain period....or completely disabling that GPU? Hmm...
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
May 04, 2011, 07:13:01 PM
#43

This was on a 5770.  Switched back to give the new version of Phoenix another try and it has submitted 700+ shares with none stale while using BFI_INT.  Can try it again if there's some way to get debug output or something to help, didn't get any extra errors or output (beyond the hashrate/stats) at all during the last run.

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 07:16:33 PM
#44

OK, could you please run export GPU_DUMP_DEVICE_KERNEL=3, run hashkill on 5770 for  30-40 seconds and give me the bitcoin_Juniper.isa file generated? This way I can have a look if there is a replacement issue.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 04, 2011, 07:17:45 PM
#45

phenomenal.

got it installed, and thought i'd run it solo to tweak and configure, before i hooked it up to a pool.  started it up thusly (with bitcoind running):

Quote
hashkill-gpu -p bitcoin <username>:<password>:127.0.0.1:8332 -a <username>

[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Juniper
[hashkill] This plugin supports GPU acceleration.
[hashkill] Initialized hash indexes
[hashkill] Initialized thread mutexes
[hashkill] Spawned worker threads
[hashkill] Successfully connected and authorized at 127.0.0.1:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 349524
[hashkill] Doing BFI_INT magic...

Speed: 172 MHash/sec [cur: 22%] [proc: 1] [subm: 0] [stale: 0] [eff: 0%]
Speed: 173 MHash/sec [cur: 34%] [proc: 1] [subm: 0] [stale: 0] [eff: 0%]

...& etc.

running a Sapphire 5770 @ 960 GPUcore, 250 Mem, a bit overvolted.  temp at a pretty constant 64 C.  Catalyst 11.3, SDK 2.4.  on debian testing with the 2.6.32-5-amd64 kernel.

it feels very stable and smooth, with the desktop actually sort of usable.

with DiabloMiner (-f15 -w128 -z4 - which is apparently the sweet spot) i get very stable at 166 MH/sec, but an essentially unusable desktop.  using Hashkill, i can actually open and use a web browser.

i have a couple of questions...

1.) am i supposed to be getting 0% efficiency when mining solo?

2.) any settings recommendations for dedicated mining (i don't mind a much less usable desktop)?  getworks, etc.?

3.) does Hashkill roll over its text cache, or should i set my terminal to a non-infinite scrollback?  i don't want to fill up my tiny hard drive...

thank you very much!
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 07:23:30 PM
#46

Never tried it solo in fact. Should test. -D option brings higher speed at the cost of less responsive desktop. The infinite progress indicator issue will be fixed soon, looks like I've forgotten to flush stdout Smiley
xyzzy
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
May 04, 2011, 07:33:29 PM
#47

This is getting better -- with 1x5770 and 2x5850 (overclocked), I'm getting "up to 818 MHash/sec" (which is about what I expect), but it's only fully loading the cards every few seconds -- here's what it looks like if I hit Enter between each progress update:

Code:
[hashkill] Successfully connected and authorized at deepbit.net:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 348864
[hashkill] Doing BFI_INT magic...

Mining statistics...
Speed: 331 MHash/sec [cur: 23%] [proc: 6] [subm: 6] [stale: 0] [eff: 100%]             
Speed: 805 MHash/sec [cur: 79%] [proc: 6] [subm: 6] [stale: 0] [eff: 100%]   
Speed: 297 MHash/sec [cur: 100%] [proc: 7] [subm: 6] [stale: 0] [eff: 85%]   
Speed: 0 MHash/sec [cur: 100%] [proc: 7] [subm: 6] [stale: 0] [eff: 85%]   
[error] (ocl_bitcoin.c:810) Could not connect to the stats server: please check if the URL provided with --addopt is correct!
Speed: 0 MHash/sec [cur: 100%] [proc: 7] [subm: 6] [stale: 0] [eff: 85%]   
Speed: 222 MHash/sec [cur: 15%] [proc: 7] [subm: 7] [stale: 0] [eff: 100%]   
Speed: 809 MHash/sec [cur: 72%] [proc: 7] [subm: 7] [stale: 0] [eff: 100%]   
Speed: 402 MHash/sec [cur: 100%] [proc: 8] [subm: 7] [stale: 0] [eff: 87%]   
[error] (ocl_bitcoin.c:810) Could not connect to the stats server: please check if the URL provided with --addopt is correct!
Speed: 0 MHash/sec [cur: 100%] [proc: 8] [subm: 7] [stale: 0] [eff: 87%]   
Speed: 0 MHash/sec [cur: 100%] [proc: 8] [subm: 8] [stale: 0] [eff: 100%]   
Speed: 109 MHash/sec [cur: 7%] [proc: 8] [subm: 8] [stale: 0] [eff: 100%]   
[error] (ocl_bitcoin.c:810) Could not connect to the stats server: please check if the URL provided with --addopt is correct!
Speed: 818 MHash/sec [cur: 64%] [proc: 8] [subm: 8] [stale: 0] [eff: 100%]   
Speed: 507 MHash/sec [cur: 100%] [proc: 9] [subm: 8] [stale: 0] [eff: 88%]   
Speed: 0 MHash/sec [cur: 100%] [proc: 9] [subm: 8] [stale: 0] [eff: 88%]   
Speed: 0 MHash/sec [cur: 100%] [proc: 9] [subm: 8] [stale: 0] [eff: 88%]
[error] (ocl_bitcoin.c:810) Could not connect to the stats server: please check if the URL provided with --addopt is correct!
Speed: 16 MHash/sec [cur: 1%] [proc: 9] [subm: 8] [stale: 0] [eff: 88%]   
Speed: 801 MHash/sec [cur: 57%] [proc: 9] [subm: 8] [stale: 0] [eff: 88%]   
Speed: 616 MHash/sec [cur: 100%] [proc: 10] [subm: 8] [stale: 0] [eff: 80%]   
[error] (ocl_bitcoin.c:810) Could not connect to the stats server: please check if the URL provided with --addopt is correct!
Speed: 0 MHash/sec [cur: 100%] [proc: 10] [subm: 8] [stale: 0] [eff: 80%]   

If I run "aticonfig --adapter=all --odgc" manually (and repeatedly) while this is happening, I see that the GPU load is cycling between 90% and 0%, roughly in step with the output of the program.

This is with SDK 2.4, btw -- which I can't even use with poclbm normally, because it only manages to use one of my 3 GPUs (?!!)
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 07:44:49 PM
#48

Yep, this is another thing I need to get done - with faster systems, the keyspace is exhausted faster than we can fetch getwork()'s. I have to perfect the queueing mechanism a bit. Noticed that while testing with 6990.

As a workaround, you can run separate instances against different devices by setting the COMPUTE environment variable to get best performance until I fix that.
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 04, 2011, 07:46:49 PM
#49

@bolapara: did you use the -D option?

Used -G4 -D
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 07:49:35 PM
#50

@bolapara, with -G4 you are too much dependant on CPU and memory. With systems with multicore CPUs and lots of RAM that's OK, but I guess you'd be better off if you provide -G 2 (or no -G at all). -G4 requires about 700 MB of system memory on a single-GPU system and probably about 1GB with dual-GPU ones (sigh) and if you don't have them free, you can get into swap and generally fuck up overall performance quite a lot Sad

Also, with -G4 it takes more time until all threads kick in and initial kernel compilation time is much slower as well. So you are likely to see peak results after ~20-30 seconds or even more with multi-GPU systems.

As a general rule, I'd advise you to stay off turning -G option (unless you are nvidia user with newer drivers where -G2 helps a lot). It has a significant meaning with some "fast" hash cracking plugins (e.g mysql-old), but it does not bring much benefits with bitcoin. You are likely just increasing your overall power consumption without any benefit.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 04, 2011, 08:06:50 PM
#51

Never tried it solo in fact. Should test. -D option brings higher speed at the cost of less responsive desktop. The infinite progress indicator issue will be fixed soon, looks like I've forgotten to flush stdout Smiley

-D option feels less stable.  trying 3, 4 and 6, i get variance between two Mh rates in all three cases: 172 and 176.  mostly 172.  (-G is worthless to me: single-core Sempron 140 with 2 Gig RAM.)

i hope to see version 0.2.5 up soon - if you get stdout flushing, i'll make it the miner for my little, frankenputer pool miner.  and we'll see how it goes with my two solos (2x5870 and 2x5850).

thanks again!
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 08:10:00 PM
#52

Yep, -D is indeed less stable. A very slight variance in desktop usage (e.g minimizing a window) can decrease performance a lot for some interval of time. It's just too flaky for normal desktop usage. This should be used only on dedicated systems.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 09:05:55 PM
#53

OK think I fixed the "fflush" problem. Also managed to integrate the ADL part: now we have some nice statistics about GPU temperature and utilization when you press ENTER key:



There is a user-defined temperature threshold (default:90) that causes the miner to disable the particular overheating GPU for 1 minute when reached. I guess better idea would be to increase fan speed (perfectly possible) but haven't done that yet.

getwork mechanism also improved for faster cards - well, unless you have >2.4GH/s total compute power Smiley  

The ADL monitoring does not depend on any new libraries, it's part of the Catalyst driver suite.

Need some more testing, will release it soon.
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 04, 2011, 09:25:44 PM
#54

@bolapara, with -G4 you are too much dependant on CPU and memory. With systems with multicore CPUs and lots of RAM that's OK, but I guess you'd be better off if you provide -G 2 (or no -G at all). -G4 requires about 700 MB of system memory on a single-GPU system and probably about 1GB with dual-GPU ones (sigh) and if you don't have them free, you can get into swap and generally fuck up overall performance quite a lot Sad

Also, with -G4 it takes more time until all threads kick in and initial kernel compilation time is much slower as well. So you are likely to see peak results after ~20-30 seconds or even more with multi-GPU systems.

As a general rule, I'd advise you to stay off turning -G option (unless you are nvidia user with newer drivers where -G2 helps a lot). It has a significant meaning with some "fast" hash cracking plugins (e.g mysql-old), but it does not bring much benefits with bitcoin. You are likely just increasing your overall power consumption without any benefit.

OK, thanks.  For the record, I also tried no -G option and just -D and had the same results.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 04, 2011, 09:56:14 PM
#55

OK think I fixed the "fflush" problem. Also managed to integrate the ADL part: now we have some nice statistics about GPU temperature and utilization when you press ENTER key:



There is a user-defined temperature threshold (default:90) that causes the miner to disable the particular overheating GPU for 1 minute when reached. I guess better idea would be to increase fan speed (perfectly possible) but haven't done that yet.

getwork mechanism also improved for faster cards - well, unless you have >2.4GH/s total compute power Smiley  

The ADL monitoring does not depend on any new libraries, it's part of the Catalyst driver suite.

Need some more testing, will release it soon.

awesome!
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 04, 2011, 10:31:16 PM
#56

oh say, gat3way - as long as you're online...

what's the upgrade procedure?

do i put the new one in the old directory, run install, and it overwrites everything?  or should i whack /usr/share/hashkill first?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 04, 2011, 10:36:25 PM
#57

It overwrites, no need to delete.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 04, 2011, 10:39:18 PM
#58

It overwrites, no need to delete.

thx.
martok
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
May 04, 2011, 11:00:25 PM
#59

I can test this with 5970s but I don't like the idea of installing things into /usr/share or requiring root privs for anything. Can I configure to pull the kernels from /home/user/share or the like?
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 04, 2011, 11:11:48 PM
#60

I can test this with 5970s but I don't like the idea of installing things into /usr/share or requiring root privs for anything. Can I configure to pull the kernels from /home/user/share or the like?

make a new user with create/read rights to /usr/share?  it shouldn't screw with your main login, or with root.  then make everything in /hashkill executable for that user.
smgoller
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
May 04, 2011, 11:21:53 PM
#61

Just tested this with two 5870s. Hashkill gave me roughly 640Mh/s, whereas running two instances of phoenix got me 760Mh/s (2x380Mh/s)....

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 05, 2011, 07:13:00 AM
#62

I can test this with 5970s but I don't like the idea of installing things into /usr/share or requiring root privs for anything. Can I configure to pull the kernels from /home/user/share or the like?

Users for the hash cracking part requested that on a number of occasions. The reason I am not reluctant to do this is that it creates a possible security problem. The architecture consists of a core binary (hashkill-gpu) and a number of plugins that are in fact shared libraries  (/usr/share/hashkill/plugins) and are loaded dynamically. Having the libraries located in a path that is only writable by root ensures noone can play nasty tricks. If I let the users install them wherever they want, someone might install them in a world-writable directory. This creates a security hole because anyone that can overwrite files there, can take advantage of that to mount local privilege escalation attacks. Besides (from the hash cracking perspective) I don't feel comfortable with the idea that anyone can install the program to crack hashes, without superuser knowledge. So - if you are the owner of the machine - you will install that anyway. If you are an ordinary user and you really need that, you can ask the admin to install it. I am not letting users to crack hashes on a system they don't have permission to. It is resource-intensive process and it may be related to illicit activities.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3472
Merit: 1638



View Profile
May 05, 2011, 07:41:44 AM
#63


I'm not going to install any binaries with root privileges without seeing the source.

Particularly not one from a hash-cracking expert, that would be a huge security hole, wouldn't you agree? Would you do it?

netxshare
Full Member
***
Offline Offline

Activity: 120
Merit: 100


View Profile
May 05, 2011, 08:33:46 AM
#64


I'm not going to install any binaries with root privileges without seeing the source.

Particularly not one from a hash-cracking expert, that would be a huge security hole, wouldn't you agree? Would you do it?

I can understand this, I have worked with gat3way on testing this over IRC on my 6990 system and 5970 I have also seen the source code. You can also get code for everything but the bitcoin plugin off his website. But I am sure when he is ready he will release the code to the public.

donations: 1CWddfhXagPoWgzUCs7oVHFjwBmqbAoJRr
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 05, 2011, 08:58:52 AM
#65

Root privileges are needed only for the installation and the installer script is apparently open source. Then yes - it's a question whether you trust binaries and it is a valid point. Then again, you already do that as the whole OpenCL stack is proprietary. So at the end it boils down to whom you trust to provide you binaries. Of course, in theory I could trojanize you, I could put your system in an evil botnet whose aim is to (say hm) generate bitcoins for me. Not that this wouldn't show up in a simple strace output for example, but then not anyone would bother to check that. Well, it's obvious I can't give you guarantees on that and it's all a matter of trust. Of course, I can make claims as much as I want, but apparently it does not matter.

Until I can get it to a point where I consider it stable enough, I am not putting the code in public. That is my personal choice and I have the right to do that just as you have the right to build some conspiracy theory around that. Source is available upon request though and I would not refuse to provide this to anyone that tests it. However, I am not willing to release it in public at that moment. It will be released soon, but only after I eliminate the present issues and integrate the functionality I've planned.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3472
Merit: 1638



View Profile
May 05, 2011, 10:00:38 AM
#66



No conspiracy theory, I think you are probably doing some good work here, it has the right pedigree.

Just it would be bad practice to do what you are asking for people who are testing it ... unless of course they know and can trust you. I'm pretty sure you wouldn't do it yourself, knowing which side of the security fence you come from. Good luck, carry on.

"Here I've got a binary that is a sub-system for your digital currency miner, just use root to install it and you'll be sweet." (Has a bad look, if you know what I mean.)

Dusty
Hero Member
*****
Offline Offline

Activity: 731
Merit: 500


Libertas a calumnia


View Profile WWW
May 05, 2011, 10:13:28 AM
#67

Root privileges are needed only for the installation
I think that a non-root user could create a chroot system to install and use it anyway, so I suppose this is not a valid concern.

Articoli bitcoin: Il portico dipinto
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 05, 2011, 10:41:44 AM
#68

I am not a firm believer in the theory that opensourcing something would automatically eliminate chances of having deliberately planted malicious code. Its the peer review that eliminate that, not the public source itself (see the underhanded C contest eheh).

Yes, source is the prerequisite, however there is also something else. Hashkill has already turned into a relatively large enough project (~130-140.000 lines of code at present) with a good number of dependencies and supporting all this in my spare time is not easy. I add new functionality faster than I fix bugs (unfortunately as my spare time is limited). This of course reflects on my autoconf/automake stuff (the bitcoin part brought 3 new dependencies - curl, json-c and ADL). Autoconf macros are still buggy and building is a bitch. There are also sometimes some minor API changes in some library that may fail everything. It's just not tested well enough at the moment. I don't feel like answering questions like "build failure XXX, please help" while having to fix some serious issues with the bitcoin code. Static-linked binaries are a nice way to make it working for most distros out there without depending on additional packages and stuff.

One might argue that rewriting everything in a higher-level language like e.g python would be a better idea and I completely agree. It is also much more portable. However it is already too late for this.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3472
Merit: 1638



View Profile
May 05, 2011, 12:28:04 PM
#69

I am not a firm believer in the theory that opensourcing something would automatically eliminate chances of having deliberately planted malicious code. Its the peer review that eliminate that, not the public source itself (see the underhanded C contest eheh).

Yes, source is the prerequisite, however there is also something else. Hashkill has already turned into a relatively large enough project (~130-140.000 lines of code at present) with a good number of dependencies and supporting all this in my spare time is not easy. I add new functionality faster than I fix bugs (unfortunately as my spare time is limited). This of course reflects on my autoconf/automake stuff (the bitcoin part brought 3 new dependencies - curl, json-c and ADL). Autoconf macros are still buggy and building is a bitch. There are also sometimes some minor API changes in some library that may fail everything. It's just not tested well enough at the moment. I don't feel like answering questions like "build failure XXX, please help" while having to fix some serious issues with the bitcoin code. Static-linked binaries are a nice way to make it working for most distros out there without depending on additional packages and stuff.

One might argue that rewriting everything in a higher-level language like e.g python would be a better idea and I completely agree. It is also much more portable. However it is already too late for this.

Okay I can appreciate an argument like this ... if you tearing through a development stage things are flying everywhere and its easier to spit out binaries ... good on ya, poclbm and phoenix are tough competition.

In this case, it is probably best for people who want to test with this code to do it on a dedicated test rig or VM maybe, but not a production mining rig of a cluster or one with a real currency at stake or in the environment anyway.

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 05, 2011, 05:43:49 PM
Last edit: May 05, 2011, 05:57:46 PM by gat3way
#70

OK, newer (hopefully last) alpha is ready.

New in that release:

* Fixed the "fflush" problem: now progress is displayed correctly, not updated with a newline
* Better getwork mechanism: smaller granularity for queueing thread, separate "submit" threads meaning that network-related performance loss is reduced
* Fixed long polling - it is now working correctly and the stales number should greatly be reduced on pools that support it. Stales are still possible though cause the current kernel invocation is not being canceled. Chances are about 1/1000. Also, stales are possible due to HTTP latency issues.
* Added thermal statistics: at any time during mining, press ENTER key to get your GPU temperature and utilization stats
* Added thermal throttling: when a GPU reaches a certain temperature limit, it is being disabled for one minute. The temperature threshold is 90 degrees Celsius by default and can be changed via the -T command-line option
* Changed the kernel to use a worksize of 64. It does not reflect on performance but makes speed more "stable"
* Changed the VLIW4 kernel (69xx cards). Now it should be a bit slower, but more stable.

Not added:

* The failover protocol
* HTTP keep-alive
* HTTPS support

Note: Thermal throttling/monitoring work on ATI cards only at the moment. There are corner cases where it would not work (e.g having adapters not supported by OpenCL).


Download:

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


Reminder: use SDK 2.3 or newer!
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 05, 2011, 06:12:50 PM
#71

thank you, gat3way.

i'll install tonight and let you know.
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 05, 2011, 06:28:16 PM
#72

The whole 'root install' thing really doesn't matter.  Look at the install.sh script.  It's using root privs to copy files into /usr/bin and /usr/share/hashkill.  None of those files are setuid/gid.  When you actually execute the files, you are executing them (unless you are being silly and running hashkill as root or with sudo) with an unprivileged user account.  At that point, your risks are the same as if you ran a binary from your home directory.

Now, open code is a different story....
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 05, 2011, 07:07:45 PM
#73

OK to anyone that needs the source, here it is:

http://www.gat3way.eu/poc/hashkill-src.tgz

Well, at that point I am _not_ providing any support to anyone that has problems building it. Also, I cannot promise that at that point I am going to follow any suggestions, even if they sound very sensible. You'd need to set two environment vairables, ATISTREAMSDKROOT and ADLROOT set to proper paths in order to properly build that.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 06, 2011, 04:56:46 AM
#74

per my previous post:

Quote
running a Sapphire 5770 @ 960 GPUcore, 250 Mem, a bit overvolted.  temp at a pretty constant 64 C.  Catalyst 11.3, SDK 2.4.  on debian testing with the 2.6.32-5-amd64 kernel.

i'm now running the latest version (still called 0.2.4-x86_64) on slush's pool.  173 Mhash/sec like a heartbeat.  efficiency at or above 100%.

a winner!
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 06, 2011, 04:27:27 PM
#75

been running non-stop on slush since my last post.  no real issues.

efficiency is down a touch - steady at 98-99%.

the 'stale' counter is session-additive, right?  it's up to 139.

Mhash/sec holding rock-solid at 173.  no variance at all.

if you'd like any generated logs or anything, let me know, gat3way.

 Smiley
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 06, 2011, 09:25:11 PM
Last edit: May 06, 2011, 09:37:34 PM by gat3way
#76

Efficiency can go over 100% or below 100% - it's a matter of luck. I've had some periods where it is way over 100%, also periods where it drops at 70-80%. Overall with time it should get close to 100% though. The stale counter is additive, yes.

BTW could you provide me the ISA dump?

I am mostly interested in the SQ_PGM_RESOURCES:NUM_GPRS field which should be among the last lines.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 06, 2011, 10:29:46 PM
#77

Efficiency can go over 100% or below 100% - it's a matter of luck. I've had some periods where it is way over 100%, also periods where it drops at 70-80%. Overall with time it should get close to 100% though. The stale counter is additive, yes.

BTW could you provide me the ISA dump?

I am mostly interested in the SQ_PGM_RESOURCES:NUM_GPRS field which should be among the last lines.

hmm...  how do i do that?

i tried running "export GPU_DUMP_DEVICE_KERNEL=3" (also 1 and 0) in tmp - but no isa file magically appeared.  i also tried while hashkill was running.

what am i doing wrong?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 06, 2011, 10:49:34 PM
#78

Well hm...look for *.isa. /tmp should be writable, that's very strange.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 06, 2011, 10:57:26 PM
#79

Well hm...look for *.isa. /tmp should be writable, that's very strange.

maybe try it in one of the /hashkill subdirectories?

BTW, i tried running it as sudo - it said no such program as 'export'.
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
May 07, 2011, 02:26:00 AM
#80

Still seems to have a somewhat high rate of stale shares (as reported in the deepbit stats), but only about 1.5% compared with the 10% last time I tried it.  Does report the new long polling blocks properly now.

As far as the whole untrusted code thing goes I have just been running it in a sandbox (the same as when testing other miners, open source doesn't necessarily matter if I don't have the time to look through it properly), no access to home directory, read access to standard system libs, write access to /dev/ati and /tmp and I can remap accesses to /usr/share/hashkill to something under the working directory.  Still have to trust code somewhat but it would stop any basic wallet-stealing (as well as reporting that it was tried).

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 07, 2011, 10:25:19 AM
#81

The 1.5% of stales is not a real concern IMO, I guess it is within acceptable range. It can be improved, but I don't really see significant reason in that  - point is we cannot cancel an already running kernel and if a solution is found in its NDRange, it will be submitted. OK, I can make it not submit it at the end, but still that would only make it look better for users while in fact it does not matter. That said, when using -D chances are that stale number would be higher and that's kinda tradeoff for the higher speed.
sarah_tonin
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
May 07, 2011, 10:44:52 AM
#82

Very nice work!  Seeing 365-370MH/s on my 5870!
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 07, 2011, 12:07:43 PM
#83

Thanks. Is that on stock clocks or OC?
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
May 07, 2011, 12:47:50 PM
#84

The 1.5% of stales is not a real concern IMO, I guess it is within acceptable range. It can be improved, but I don't really see significant reason in that  - point is we cannot cancel an already running kernel and if a solution is found in its NDRange, it will be submitted. OK, I can make it not submit it at the end, but still that would only make it look better for users while in fact it does not matter. That said, when using -D chances are that stale number would be higher and that's kinda tradeoff for the higher speed.

Yeah, it's definitely much better than it was and at that rate I wouldn't worry about mining long-term with it.  (Assuming the higher speed makes up for a few extra stale shares)

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 07, 2011, 09:57:20 PM
#85

Well hm...look for *.isa. /tmp should be writable, that's very strange.

maybe try it in one of the /hashkill subdirectories?

BTW, i tried running it as sudo - it said no such program as 'export'.


Opsss......I now see what's the problem. You don't need to run hashkill as root (via sudo). It is only needed for the installation (sudo ./install.sh). Once you are done, you just run hashkill-gpu. You can do export ....; sudo hashkill-gpu or sudo export ... ; sudo hashkill-gpu ... but the environment won't be preserved across those so you won't be getting the ISA dump. So you just have to drop that sudo thing. In fact I really don't recommend running hashkill as superuser - it does no matter at all as far as performance is related and it can run perfectly well without superuser privileges. I tend to minimize the set of root processes running on my system, kind of paranoia from days when I used to be a sysadmin. In fact, running as root can only lead to problems as the root user may not be allowed to make a connection to the X server (on my debian devel host for example I need to explicitly allow this with the xhost command).
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 07, 2011, 11:25:37 PM
#86

Well hm...look for *.isa. /tmp should be writable, that's very strange.

maybe try it in one of the /hashkill subdirectories?

BTW, i tried running it as sudo - it said no such program as 'export'.


Opsss......I now see what's the problem. You don't need to run hashkill as root (via sudo). It is only needed for the installation (sudo ./install.sh). Once you are done, you just run hashkill-gpu. You can do export ....; sudo hashkill-gpu or sudo export ... ; sudo hashkill-gpu ... but the environment won't be preserved across those so you won't be getting the ISA dump. So you just have to drop that sudo thing. In fact I really don't recommend running hashkill as superuser - it does no matter at all as far as performance is related and it can run perfectly well without superuser privileges. I tend to minimize the set of root processes running on my system, kind of paranoia from days when I used to be a sysadmin. In fact, running as root can only lead to problems as the root user may not be allowed to make a connection to the X server (on my debian devel host for example I need to explicitly allow this with the xhost command).

sorry - i was unclear.  i should have said "i also tried running it as sudo..."

i've been running hashkill, and first tried running export, as user.  just can't get that blasted thing to work.  no .isa files anywhere on the hard drive.  weird indeed...

"export GPU_DUMP_DEVICE_KERNEL=3" - in /tmp, right?  11.3, 2.4, and AMDOverdriveCtrl profile loaded.  bitcoind not running.

i type it, hit enter, and it just feeds a line to another prompt - nothing happens.  i might as well have just hit enter.
sarah_tonin
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
May 08, 2011, 03:38:44 AM
#87

Thanks. Is that on stock clocks or OC?

Entirely stock!
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 08, 2011, 09:50:09 AM
Last edit: May 08, 2011, 10:50:19 AM by gat3way
#88

@sarah_tonin: just to confirm everything works correctly, can you paste the proc/subm/stale/eff ratio after some minutes of work? Also, did you use the 64-bit or the 32-bit version? Cause I got reports from 5870 users that complain about bad performance and still trying to figure out what's the root cause.

@Jaime Frontero: the OpenCL runtime dumps them in the current directory, so you have to be in a writable directory (e.g /tmp). That's really odd, haven't seen such behavior yet.  BTW the whole export thing itself does not dump anything, you've got to run the hashkill binary after that, leave it running for a couple of seconds (say until it submits a share) then terminate it and look for the .isa files in the current directory.
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 08, 2011, 02:04:38 PM
#89

very nice work,
Did a clean install 64bits ubuntu 11.04/ati 11.4/sdk2.3 and hashkill worked direct without problems and i've got a few Mhashes increase
ubuntu 11.04 / 64bits clean install guide/script:  http://bitcointalk.org/index.php?topic=3359.msg108953#msg108953
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 08, 2011, 02:21:43 PM
#90

Nice Smiley

BTW may I have your hardware info and speed just for statistic purposes?
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 08, 2011, 02:47:00 PM
#91

My tryout-machine is a MSI 770-c45/Mobo with Athlon X2 at 3.00 Ghz with ATti 5570 going from 67Mhash to 71Mhash
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 08, 2011, 02:50:29 PM
#92

Thanks.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 09, 2011, 10:20:13 AM
#93

Alright, to anyone that reported degraded performance: I think I identified the potential root cause and it is related to host-device transfers.

I created a 64-bit build that implements the "usual" way to read GPU buffers from host. Hopefully that would address this issue. If everything is according to my estimations, I will make this configurable via a command-line switch.

Here is the "tryout" build:

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

Note that on systems that do not have that issue, this would be kinda slower. Also please make sure you try that with -G2 -D command-line options.
sniper_sniperson
Full Member
***
Offline Offline

Activity: 124
Merit: 100


View Profile
May 09, 2011, 11:44:05 AM
#94

What exactly are doing these options?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 09, 2011, 11:47:26 AM
#95

-G2 is 2 threads/GPU (which is the default BTW)
-D is a worksize 2x multiplier: it tends to give better performance at the cost of reduced desktop responsiveness.
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 09, 2011, 12:30:01 PM
#96

Alright, to anyone that reported degraded performance: I think I identified the potential root cause and it is related to host-device transfers.

I created a 64-bit build that implements the "usual" way to read GPU buffers from host. Hopefully that would address this issue. If everything is according to my estimations, I will make this configurable via a command-line switch.

Here is the "tryout" build:

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

Note that on systems that do not have that issue, this would be kinda slower. Also please make sure you try that with -G2 -D command-line options.

I had several runs of a few hours and i get about 10% stale rate on all the runs with the old version. the stales won't matter on deepbit, but other pools are not so gentle.
gonna try this new version now
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 09, 2011, 02:15:54 PM
#97

This is what the "tryout" build returned

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

kh@UMiner:~/Downloads/hashkill/hashkill-0.2.4-x86_64$ sudo ./install.sh
Installation complete. Please set your LD_LIBRARY_PATH variable if you are ATI user and intend to run hashkill-gpu

Run hashkill-cpu for CPU-based attacks or hashkill-gpu for GPU/CPU-based ones

[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Redwood
[hashkill] GPU0: ATI Radeon HD 5570 [busy:0%] [temp:60C]
[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 mining.bitcoin.cz:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 348696
[hashkill] Doing BFI_INT magic...
Segmentation fault
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 09, 2011, 02:23:27 PM
#98

You are using it with SDK2.1 or SDK2.2 - (unfortunately) they are not compatible.
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 09, 2011, 02:25:25 PM
#99

You are using it with SDK2.1 or SDK2.2 - (unfortunately) they are not compatible.

SDK 2.3

very nice work,
Did a clean install 64bits ubuntu 11.04/ati 11.4/sdk2.3 and hashkill worked direct without problems and i've got a few Mhashes increase
ubuntu 11.04 / 64bits clean install guide/script:  http://bitcointalk.org/index.php?topic=3359.msg108953#msg108953

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 09, 2011, 05:04:43 PM

Rather weird. Tried with another pool?
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 09, 2011, 05:46:11 PM

Rather weird. Tried with another pool?

I get the stale problem with every pool, this is with your first version, your tryout version gives me this segmentation fault on install

Your first version:
Mining statistics...
Speed: 71 MHash/sec [cur: 91%] [proc: 101] [subm: 71] [stale: 10] [eff: 70%]

When i run phoenix it keeps jumping to Warning: work queue empty, miner is idle, even on AGGRESSION=7 and gives me [0 Khash/sec] [1 Accepted] [0 Rejected] [RPC] for many minutes

When i run poclbm i get no stales or rejects
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 09, 2011, 07:39:14 PM

This is what the "tryout" build returned

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

kh@UMiner:~/Downloads/hashkill/hashkill-0.2.4-x86_64$ sudo ./install.sh
Installation complete. Please set your LD_LIBRARY_PATH variable if you are ATI user and intend to run hashkill-gpu

Run hashkill-cpu for CPU-based attacks or hashkill-gpu for GPU/CPU-based ones

[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Redwood
[hashkill] GPU0: ATI Radeon HD 5570 [busy:0%] [temp:60C]
[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 mining.bitcoin.cz:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 348696
[hashkill] Doing BFI_INT magic...
Segmentation fault

I get the exact same problem.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 09, 2011, 08:08:15 PM

Could you check what SDK version are you really using?

This is simple: just type:

ldd /usr/bin/hashkill | grep OpenCL

and paste.

Looking at the guide posted, they do install the SDK and they do set it inside .bashrc. However they do not immediately set the LD_LIBRARY_PATH variable and you will not be using SDK2.3 until you relogin (or open a new session). Thus, if you have already set LD_LIBRARY_PATH to SDK2.1 or 2.2, it would crash. I am asking that because the symptoms are very much as though you're using older SDK - it crashes right after the BFI_INT replacement, on the first clEnqueueNDRangeKernel operation.
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 09, 2011, 08:14:47 PM

Could you check what SDK version are you really using?

This is simple: just type:

ldd /usr/bin/hashkill | grep OpenCL

and paste.

Looking at the guide posted, they do install the SDK and they do set it inside .bashrc. However they do not immediately set the LD_LIBRARY_PATH variable and you will not be using SDK2.3 until you relogin (or open a new session). Thus, if you have already set LD_LIBRARY_PATH to SDK2.1 or 2.2, it would crash. I am asking that because the symptoms are very much as though you're using older SDK - it crashes right after the BFI_INT replacement, on the first clEnqueueNDRangeKernel operation.

Code:
me@miner00:~/hashkill-0.2.4-x86_64$ hashkill-gpu -p bitcoin *****:deepbit.net:8332 -D -a *****

[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Using GPU double mode
[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:53C]
[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 deepbit.net:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 348696
[hashkill] Doing BFI_INT magic...
[hashkill] Long polling available, starting LP thread.
Segmentation fault
me@miner00:~/hashkill-0.2.4-x86_64$ ldd /usr/bin/hashkill-gpu | grep OpenCL
        libOpenCL.so => /opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libOpenCL.so (0x00007fb6f7c73000)
me@miner00:~/hashkill-0.2.4-x86_64$ which hashkill-gpu
/usr/bin/hashkill-gpu
me@miner00:~/hashkill-0.2.4-x86_64$
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 09, 2011, 08:32:53 PM
Last edit: May 09, 2011, 09:14:32 PM by 4z3rt

@Bolapara

go to the dir where your hashkill-gpu is and do:

ldd hashkill-gpu | grep OpenCL

and you'll see this:

   libOpenCL.so => /opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libOpenCL.so (0x00007f1c94159000)

then you know if you got the right SDK

edit@bolapara
didn't scroll down in the included screen to see you already did this

must be a form of my dislectia  Wink
allinvain
Legendary
*
Offline Offline

Activity: 3052
Merit: 1060



View Profile WWW
May 09, 2011, 08:34:19 PM

I'm curious to know if a windows beta/alpha build will be released soon.

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 09, 2011, 08:42:36 PM

Hmpf, that's kinda strange. I definitely see one issue with the thermal monitoring (5970 detected by ADL as a single device named "5800 series" instead of 2 devices, as far as I understood, it depends on the card's BIOS version, so that I need to take that into account).

OK then the crash thing is really weird. Still not sure why does that happen, will build a version that spits out more debug messages to find out what causes them.

Quote
I'm curious to know if a windows beta/alpha build will be released soon.

This is like alpha. Beta will be released once annoying bugs like those are addressed properly.

Thus far I have those:

* on some GPUs performance is rather degraded, root cause not identified. Seen that on 5870 and 5850, probably others. Some 5870 user reported expected speed so this might turn out to be outside hashkill's scope.

* Those crashes (unfortunately I cannot reproduce them). Still wondering what may be the root cause. Will increase verbosity to see where it fails

* Apparently there are issues with thermal monitoring and dual-GPU cards. Also I do not handle the case with an onboard ATI GPU that is not supported by OpenCL - that is a potential issue with some systems.
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 09, 2011, 08:55:01 PM

Hmpf, that's kinda strange. I definitely see one issue with the thermal monitoring (5970 detected by ADL as a single device named "5800 series" instead of 2 devices, as far as I understood, it depends on the card's BIOS version, so that I need to take that into account).

OK then the crash thing is really weird. Still not sure why does that happen, will build a version that spits out more debug messages to find out what causes them.

Actually, I have two 5870 cards.

I also experience the performance issue.  I see about 667MH/s with hashkill and about ~800MH/s with phoenix.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 09, 2011, 09:15:26 PM

BTW are your 5870s crossfired ?
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 09, 2011, 09:16:15 PM

BTW are your 5870s crossfired ?
No.
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 09, 2011, 09:47:01 PM

Quote
Thus far I have those:

* on some GPUs performance is rather degraded, root cause not identified. Seen that on 5870 and 5850, probably others. Some 5870 user reported expected speed so this might turn out to be outside hashkill's scope.

* Those crashes (unfortunately I cannot reproduce them). Still wondering what may be the root cause. Will increase verbosity to see where it fails

* Apparently there are issues with thermal monitoring and dual-GPU cards. Also I do not handle the case with an onboard ATI GPU that is not supported by OpenCL - that is a potential issue with some systems.


If you cant reproduce those tryout version crashes, i could try to build that version from source on my machine (if you have a tryout source version and directions for me)


gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 05:55:58 AM

http://www.gat3way.eu/poc/hashkill-src.tgz

Building is not so easy though. There are some prerequisites: json-c, curl and openssl. With Ubuntu that would be:

apt-get install gcc make autoconf libjson0 libjson0-dev libcurl3-dev openssl

if you fail to provide some of them, the build will likely be successful, however the bitcoin functionality won't be available.


There is also dependance on AMD ADL. IT can be downloaded from AMD site at:

http://developer.amd.com/gpu/adlsdk/pages/default.aspx


Then the easiest way to build it all is by first setting two environment variables:

export ATISTREAMSDKROOT=/path/to/streamsdk
export ADLROOT=/path/to/adl

then

./configure && make && make install

if something fails, you could try to run the ./rebuild.sh script and retry.

For the "make install" step you need root privileges as it does the copy to /usr/share and /usr/bin.

OK, like I said, building is not easy.
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 10, 2011, 06:17:07 AM

@gat3way, I have about an hour or so.  If you want to try and debug anything for a bit I am available.  I am on #bitcoin.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 06:17:43 AM

I gotta go to work now Sad So it would be next time I believe.
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 01:39:12 PM
Last edit: May 10, 2011, 02:17:35 PM by 4z3rt

On the prerequisites i had to additionally install curl and libcurl4-openssl-dev, afaik libcurl3-dev was replaced with libcurl4-openssl-dev

export ATISTREAMSDKROOT=/opt/ati-stream-sdk-v2.3-lnx64
export ADLROOT=/opt/ADL_SDK_3.0

./configure returned no errors

make returned this error:

gcc -DPACKAGE_NAME=\"hashkill\" -DPACKAGE_TARNAME=\"hashkill\" -DPACKAGE_VERSION=\"0.1.0\" -DPACKAGE_STRING=\"hashkill\ 0.1.0\" -DPACKAGE_BUGREPORT=\"gat3way@gat3way.eu\" -DPACKAGE_URL=\"\" -DPACKAGE=\"hashkill\" -DVERSION=\"0.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_FCNTL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_OPENSSL_MD5_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_ZLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_JSON_JSON_H=1 -DHAVE_CURL_CURL_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_SSE2=/\*\*/ -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_BZERO=1 -DHAVE_STRSTR=1 -DHAVE_SYSINFO=1 -DHAVE_STRERROR=1 -DHAVE_ENDPWENT=1 -DHAVE_GETCWD=1 -DHAVE_STRCHR=1 -DHAVE_STRCSPN=1 -DHAVE_STRTOUL=1 -DHAVE_MEMSET=1 -DHAVE_STRTOL=1 -I. -msse2  -ljson -lcurl -DHAVE_CURL_CURL_H -DHAVE_ADL_SDK_H -I/include   -I/include -O3 -funroll-loops  -g -O2 -MT hashkill-ocl-adl.o -MD -MP -MF .deps/hashkill-ocl-adl.Tpo -c -o hashkill-ocl-adl.o `test -f 'ocl-adl.c' || echo './'`ocl-adl.c
ocl-adl.c:3:21: fatal error: adl_sdk.h: No such file or directory
compilation terminated.
make[2]: *** [hashkill-ocl-adl.o] Error 1


and rebuild returned

khash@UbuntuMiner:~/Downloads/hashkill/source/hashkill$ ./rebuild.sh
configure.ac: warning: missing AC_CHECK_FUNCS([mkdir]) wanted by: src/sessions.c:150
configure.ac: warning: missing AC_CHECK_FUNCS([setenv]) wanted by: src/main.c:297
configure.ac: warning: missing AC_PROG_CXX wanted by: src/amd_bitcoin.ll
configure.ac: warning: missing AC_PROG_LN_S wanted by: 64bitset.sh:7
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --no-force
src/Makefile.am:20: compiling `plugins.c' with per-target flags requires `AM_PROG_CC_C_O' in `configure.ac'
autoreconf: Leaving directory `.'
src/Makefile.am:20: compiling `plugins.c' with per-target flags requires `AM_PROG_CC_C_O' in `configure.ac'

any suggestions?

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 02:33:18 PM

Ummm, OK, just use that exact sequence of commands:

Quote
export ATISTREAMSDKROOT=/opt/ati-stream-sdk-v2.3-lnx64
export ADLROOT=/opt/ADL_SDK_3.0
make depclean
./rebuild.sh
./configure
make
sudo make install
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 02:50:47 PM

Ummm, OK, just use that exact sequence of commands:

Quote
export ATISTREAMSDKROOT=/opt/ati-stream-sdk-v2.3-lnx64
export ADLROOT=/opt/ADL_SDK_3.0
make depclean
./rebuild.sh
./configure
make
sudo make install

i must be doing something wrong

khash@UbuntuMiner:~/Downloads/hashkill/source/hashkill$ export ATISTREAMSDKROOT=/opt/ati-stream-sdk-v2.3-lnx64
khash@UbuntuMiner:~/Downloads/hashkill/source/hashkill$ export ADLROOT=/opt/ADL_SDK_3.0
khash@UbuntuMiner:~/Downloads/hashkill/source/hashkill$ make depclean
make: *** No rule to make target `depclean'.  Stop.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 03:17:32 PM

Alright, skip the make depclean part then, just go on with the next ones exactly as I posted
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 03:53:02 PM

brb, have to buy some food, we'll go on in an hour
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 05:16:55 PM

Alright, skip the make depclean part then, just go on with the next ones exactly as I posted

oke i'm back, with a new clean system where the normal hashkill works

first step: hashkill-source  ./configure returns

khash@UbuntuMiner:~/Downloads/hashkillsource/hashkill$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating man/Makefile
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for stdlib.h... (cached) yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking openssl/md5.h usability... yes
checking openssl/md5.h presence... yes
checking for openssl/md5.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking openssl/sha1.h usability... no
checking openssl/sha1.h presence... no
checking for openssl/sha1.h... no
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking json/json.h usability... yes
checking json/json.h presence... yes
checking for json/json.h... yes
checking curl/curl.h usability... yes
checking curl/curl.h presence... yes
checking for curl/curl.h... yes
checking for size_t... yes
checking for uint64_t... yes
checking for uint32_t... yes
checking for uint16_t... yes
checking for ssize_t... yes
checking for inline... inline
checking for working alloca.h... yes
checking for alloca... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for uid_t in sys/types.h... yes
checking for x86 cpuid 0x00000001 output... 100f62:1020800:802009:178bfbff
checking whether sse2 is supported... yes
checking whether C compiler accepts -msse2... yes
configure: error: cannot run /bin/bash ./config.sub
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 05:26:03 PM

Just repeat the steps omitting make depclean. This should be:

export ATISTREAMSDKROOT=/opt/ati-stream-sdk-v2.3-lnx64
export ADLROOT=/opt/ADL_SDK_3.0
./rebuild.sh
./configure
make
sudo make install
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 05:40:34 PM

this time it compiled the whole way thru, (do you need the output of the complilation?)

khash@UbuntuMiner:/usr/bin$ ./hashkill-gpu -p bitcoin xxxxx
[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Redwood
[hashkill] GPU0: ATI Radeon HD 5570 [busy:0%] [temp:48C]
[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 deepbit.net:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 348696
[hashkill] Doing BFI_INT magic...
[hashkill] Long polling available, starting LP thread.

Mining statistics...
Segmentation fault
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 06:09:36 PM

Hmmm could you try with -G1 command line option?
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 06:21:17 PM

Hmmm could you try with -G1 command line option?

When i got this segmentation fault, the normal hashkill didn't work either, so in the normal hashkill i re ./install.sh
and now the source compiled also works, but is this due to the normal reinstall or do i have to reinstall the source compiled one to when i want to run that version?

khash@UbuntuMiner:/usr/bin$ ./hashkill-gpu -p bitcoin xxxxx -G1
[hashkill] Version 0.2.4
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Redwood
[hashkill] GPU0: ATI Radeon HD 5570 [busy:3%] [temp:60C]
[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 deepbit.net:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 348936
[hashkill] Doing BFI_INT magic...
[hashkill] Long polling available, starting LP thread.

Mining statistics...
Speed: 70 MHash/sec [cur: 97%] [proc: 2] [subm: 1] [stale: 0] [eff: 50%]     ^C
[hashkill] Interrupted by user request!

[hashkill] Done!
[hashkill] Attack took 64 seconds.
[hashkill] Bye bye Smiley
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 07:08:21 PM

Looks like the -G1 option fixed this (if I understand correct and the prebuilt version also works with -G1).

Unfortunately this is not optimal performance-wise, you are losing about 1.5% due to that (which is not much though, about 1M/s, you are likelly to get more with -D). Well, I am not sure what's the root cause yet. SDK2.3 should be thread-safe, it could be either my code or the ADL library. I am more inclined to blame my code though Smiley

Stupid thing is I cannot reproduce that here.

OK just one more thing - could you try running that with -G1 -D and also -G2 -D ? I guess -G2 -D would crash, still that would be an interesting experiment.


P.S this is the same as the entry in my estimations table though - at least I am glad about that Smiley

http://www.gat3way.eu/est.php
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 08:04:23 PM

Looks like the -G1 option fixed this (if I understand correct and the prebuilt version also works with -G1).

Unfortunately this is not optimal performance-wise, you are losing about 1.5% due to that (which is not much though, about 1M/s, you are likelly to get more with -D). Well, I am not sure what's the root cause yet. SDK2.3 should be thread-safe, it could be either my code or the ADL library. I am more inclined to blame my code though Smiley

Stupid thing is I cannot reproduce that here.

OK just one more thing - could you try running that with -G1 -D and also -G2 -D ? I guess -G2 -D would crash, still that would be an interesting experiment.


P.S this is the same as the entry in my estimations table though - at least I am glad about that Smiley

http://www.gat3way.eu/est.php

Oke,
i have tried with -G -D, no desktop lag, works great, i ran it for 30 minutes, only 1 stale this time: Speed: 70 MHash/sec [cur: 63%] [proc: 54] [subm: 56] [stale: 1] [eff: 103%]
-G1 -D give sometimes slow mouse movements
-G2 -D and desktop becomes slow in moving screens around
-G4 -D and moving desktop stuff around becomes near to impossible

I am still a little unsatisfied about the segmentation fault, is there no install log file with compiling errors that could clear up this segmentation fault? It must start somewhere.
Maybe i'll try it again 2morrow, clean install (as in install tread before) with only hashkill source and some way to find a install log (if there is one).
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 10, 2011, 08:25:21 PM
Last edit: May 10, 2011, 08:55:11 PM by gat3way

Hm, don't try -G4, you need really fast CPU for that. It does not matter for bitcoin at all, you are just rising your power consumption for no good use. There are some cases with hash cracking where it helps (again you need fast CPU and lots of RAM). I would not recommend anything above -G2.

OK so -D does not bring much of performance (not enough to round up to the next integer MH/s, 71 that is). It brings about 2MH/s on my 6870 (from 270 to 272) and it brings a lot for 6990. I guess it does not matter that much for slower GPUs.

As for the segfaults....ummm well probably the static-built binary is not really optimal for all users. Probably the best way to get full performance and avoid crashes is to build it yourself like you did. Mmmm this means I should work on the build stuff as currently it's too complicated and makes a lot of assumptions.

Hm BTW just one last question, is your GPU at stock clocks or OC'd ?
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 10, 2011, 09:32:41 PM

Hm, don't try -G4, you need really fast CPU for that. It does not matter for bitcoin at all, you are just rising your power consumption for no good use. There are some cases with hash cracking where it helps (again you need fast CPU and lots of RAM). I would not recommend anything above -G2.

OK so -D does not bring much of performance (not enough to round up to the next integer MH/s, 71 that is). It brings about 2MH/s on my 6870 (from 270 to 272) and it brings a lot for 6990. I guess it does not matter that much for slower GPUs.

As for the segfaults....ummm well probably the static-built binary is not really optimal for all users. Probably the best way to get full performance and avoid crashes is to build it yourself like you did. Mmmm this means I should work on the build stuff as currently it's too complicated and makes a lot of assumptions.

Hm BTW just one last question, is your GPU at stock clocks or OC'd ?

The tryout version is on stock, did not come to installing oc software yet, but when i do i will post hashkill oc results
sarah_tonin
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
May 10, 2011, 09:38:53 PM

@sarah_tonin: just to confirm everything works correctly, can you paste the proc/subm/stale/eff ratio after some minutes of work? Also, did you use the 64-bit or the 32-bit version? Cause I got reports from 5870 users that complain about bad performance and still trying to figure out what's the root cause.

@Jaime Frontero: the OpenCL runtime dumps them in the current directory, so you have to be in a writable directory (e.g /tmp). That's really odd, haven't seen such behavior yet.  BTW the whole export thing itself does not dump anything, you've got to run the hashkill binary after that, leave it running for a couple of seconds (say until it submits a share) then terminate it and look for the .isa files in the current directory.


I recently have been tweaking the clocks on my 5870 and using hashkill:

Code:
Speed: 382 MHash/sec [cur: 9%] [proc: 25926] [subm: 25089] [stale: 534] [eff: 96%]   

:~$ aticonfig --od-setclocks=900,900 --adapter=all

Adapter 0 - ATI Radeon HD 5800 Series
            New Core Peak   : 900
            New Memory Peak : 900

and from lspci -v to show the card is really this:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 5870 (Cypress) (prog-if 00 [VGA controller])
Subsystem: XFX Pine Group Inc. Device 2961

The speed is now around 380-390MH/s at 900MHz on the GPU and the memory clock down to 900MHz -- running fairly stable at around 82C and 99% busy :]
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 11, 2011, 10:42:44 AM


Hm BTW just one last question, is your GPU at stock clocks or OC'd ?

I have installed  AMDOverdriveCtrl and set max speed to 700mhz

OC' ed running steady at 75Mhash/s with peaks up to 79Mhash, compared to stockspeed at 70/71MHash/s

Hashkill Mining statistics...
Speed: 75 MHash/sec [cur: 73%] [proc: 3] [subm: 3] [stale: 0] [eff: 100%]    
Long polling: got new block!
Speed: 79 MHash/sec [cur: 68%] [proc: 6] [subm: 8] [stale: 2] [eff: 133%]

Btw, do you have a git or svn repository for hashkill?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 11, 2011, 12:45:36 PM

I use sourceforge's SVN, but I haven't commited the bitcoin code yet
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 11, 2011, 04:30:52 PM


I recently have been tweaking the clocks on my 5870 and using hashkill:

Code:
Speed: 382 MHash/sec [cur: 9%] [proc: 25926] [subm: 25089] [stale: 534] [eff: 96%]   

:~$ aticonfig --od-setclocks=900,900 --adapter=all

Adapter 0 - ATI Radeon HD 5800 Series
            New Core Peak   : 900
            New Memory Peak : 900

and from lspci -v to show the card is really this:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 5870 (Cypress) (prog-if 00 [VGA controller])
Subsystem: XFX Pine Group Inc. Device 2961

The speed is now around 380-390MH/s at 900MHz on the GPU and the memory clock down to 900MHz -- running fairly stable at around 82C and 99% busy :]

good speed, sarah_tonin (BTW, i'm glad your enterochromaffin cells are doing well).

if i might - what brand 5870, and what voltage are you running at?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 11, 2011, 09:40:28 PM

A bugfix/performance improvement release:

* Fixed random crashes when ATI SDK <= 2.3
* Removed some unnecessary code that can lead to performance degradation on multi-gpu systems (or single-gpu ones with -G2 used)
* ATI Stream SDK 2.2 supported (without -D) and also SDK 2.1 (without -D)
* Improved host code, removed unnecessary synchronization, tuned NDRange, improvement about 0.5% (without -D) up to 2.5% with -D. It now peaks at 279M/s with -D on my 6870, stock clock (previously 272M/s).
* Fixed a stupid bug in the long polling code, stales should decrease
* Added minor performance optimizations in kernel, available with SDK 2.4 only.
* Added some minor tweaks to lower down CPU usage. This would make hashkill a bit more energy-efficient.


Known issue: with 32-bit builds, you might experience kernel compilation failures with SDK2.3 (reason:unknown,64-bit version does not have that problem). Just try another SDK. SDK 2.4 is best tested and works flawlessly for both architectures, with any command-line tweaks like -D or -G3. It also tends to be fastest.

Known issue: with SDK2.1 and SDK2.2, both 32-bit and 64-bit versions when used with -D are buggy and return wrong results. Please do not use -D with old sdks

Known issue: Thermal monitoring fails to map devices properly in some configurations (mostly related to onboard video adapters not supported by OpenCL).

Known issue: performance with -D is now more flaky and not as stable as before and desktop is slightly less responsive. This is the tradeoff for higher performance and won't be fixed.

Not implemented yet: fail-over extension used in deepbit.


Download:

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


64-bit build:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 12, 2011, 11:22:21 AM

I cant download the latest hashkill. Your site is not reachable for more than 12 hours now.
dishwara
Legendary
*
Offline Offline

Activity: 1854
Merit: 1016



View Profile
May 12, 2011, 11:35:32 AM

i too got page error. Files is not there.

ACCOUNT WAS HACKED FROM 2016-2019. NOW RECLAIMED BY ORIGINAL USER D.ISHWARA
SORRY IF ANYONE GOT CHEATED BY THE IMPOSTOR
ALL POSTS AFTER MARCH 2016 BECOMES OBSOLETE & WILL BE DELETED AFTER I READ IT.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 11:37:46 AM

Apparently there are connectivity problems. Unfortunately I am away and can't do anything for the next 4-5 hours Sad
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 12, 2011, 11:50:11 AM

Apparently there are connectivity problems. Unfortunately I am away and can't do anything for the next 4-5 hours Sad

Oke, will try again later  Smiley
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 04:38:18 PM

Network connectivity restored.
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 12, 2011, 04:49:57 PM

Network connectivity restored.

yep, download is working again
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 05:00:30 PM

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.
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 12, 2011, 05:48:37 PM
Last edit: May 12, 2011, 06:02:17 PM by 4z3rt

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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 06:04:11 PM

It's not hashkill.

Just do smth like:

echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 12, 2011, 06:15:13 PM

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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 06:17:56 PM

What GPU do you have, bolapara?
Gnaffel
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 12, 2011, 06:52:26 PM
Last edit: May 12, 2011, 07:13:04 PM by 4z3rt

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
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 12, 2011, 07:30:33 PM

What GPU do you have, bolapara?

Two 5870s
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 08:16:23 PM

Hmm you did not forget to do sudo ./install.sh, not just ./install.sh ?
bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 12, 2011, 08:45:43 PM

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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 08:54:40 PM

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
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
May 12, 2011, 09:02:54 PM
Last edit: May 12, 2011, 09:48:20 PM by 4z3rt

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
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 12, 2011, 09:32:39 PM

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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 12, 2011, 09:51:13 PM

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
Legendary
*
Offline Offline

Activity: 3052
Merit: 1060



View Profile WWW
May 13, 2011, 12:12:02 AM

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 Smiley I'd really love to swap out poclbm for hashkill if it means no more 100% cpu usage.


bolapara
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 13, 2011, 12:32:47 AM
Last edit: May 13, 2011, 12:57:57 AM by 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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 13, 2011, 06:00:19 AM

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
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
May 14, 2011, 05:16:57 AM

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
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
May 14, 2011, 06:25:13 AM

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
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
May 16, 2011, 04:35:05 PM

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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 16, 2011, 07:07:43 PM

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
Hero Member
*****
Offline Offline

Activity: 731
Merit: 500


Libertas a calumnia


View Profile WWW
May 17, 2011, 01:33:29 PM

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!

Articoli bitcoin: Il portico dipinto
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 17, 2011, 05:04:46 PM

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.
Dusty
Hero Member
*****
Offline Offline

Activity: 731
Merit: 500


Libertas a calumnia


View Profile WWW
May 17, 2011, 06:35:36 PM

Thank you gat3way for the explainations, I need some clarifications, though:
subm is the number of successfully submitted shares. It might be higher, lower or equal to the number of processed getworks.
How can this be possible...?
And anyway why there is difference between processed and submitted?

Quote
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.
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!

Articoli bitcoin: Il portico dipinto
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 17, 2011, 07:40:56 PM

Quote
How can this be possible...?
And anyway why there is difference between processed and submitted?

It is possible because you can have either 0, or 1 or more than 1 possible "solutions" for a single getwork.


Quote
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%)

Without -D I guess anything below 3% would be OK, with -D probably more. Stale percentage of 20 for example smells rather fishy.
leepfrog
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
May 23, 2011, 06:25:24 PM

Just testing hashkill with ubuntu 11.4 and 3x5830 + 1x6870.

It seems to work fine (aticonfig --odgc shows 99% usage), and also the pool website shows around the speed i am expecting (900-1000 mhash/s).

However hashkill itself only shows between 110 and 140 mhash..

Any idea whats wrong? Do you need any further logs?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 23, 2011, 07:54:37 PM

I am aware of that bug (you are using the 32-bit version I suppose?).

There are also issues with the ADL monitoring I am currently working on.

And since I am building a small rig as well, I noticed some things that can be improved. For example we can log the output into a convinient to parse file or SQL database so that web frontend can be done much less painfully. So there is some work to do. I will hopefully release a new version in 2 or 3 weeks. No performance benefits expected though
leepfrog
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
May 23, 2011, 08:07:33 PM

No as it is a 64bit ubuntu it should be using the 64 bit version (or is this a flag or something which must be set explicitly)?

The sad thing is that ATM it is very hard to compare hash speed with other miners as you have to rely on the rates reported by the pool (which tend to jump up and down around 100mhash).

Looking forward to your next release!
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 23, 2011, 08:27:37 PM

Well,I know this sucks, but I am too tired of that "release early, release often" stuff. I need some more time to properly address all the issues instead of relying on feedback for each small incremental improvement and bugfix.
gigabytecoin
Sr. Member
****
Offline Offline

Activity: 280
Merit: 250


View Profile
May 26, 2011, 07:46:32 AM

Site is down Sad

Anybody have a copy? Torrent file?
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 26, 2011, 08:17:41 AM

Site is down Sad

Anybody have a copy? Torrent file?

check PM...
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 27, 2011, 10:22:15 PM

A new version, this time beta quality.

Fixed:

* progress indicator issues (sigh)
* better queueing mechanism
* ADL thermal monitoring stuff now works correctly - you should have thermal monitoring and stats for all your GPUs
* fixed bug on some systems causing hashkill to stop properly submitting shares
* improved multi-gpu support
* mining.bitcoin.cz now properly reports account info when -a is used with the correct API key

New feature:

* progress now autosaved in a text file, json format. It is autosaved in ~/.hashkill/bitcoin.json . This file can be parsed in order to implement external tools that collect statistics, draw graphs, provide web interface and stuff. This feature will be extended in the future to provide GPU temps info and pool stats.

Download:

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

Please use sudo ./install.sh or run install.sh as root. This is especially important if you have previously installed hashkill - older files need to be overwritten.
dikidera
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 27, 2011, 10:23:41 PM

Щo нe cпиш бpe gat3way   Grin

Nice release though.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 27, 2011, 10:43:44 PM

Exex бeзcъниe Smiley
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
May 27, 2011, 10:50:11 PM

The date on the executable is 5/11/2011

Also, I don't see a folder in my home directory named ".hashkill"

Did I download the new version before you updated the .tgz?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 27, 2011, 10:51:23 PM

Hm, browser caching issues?
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
May 27, 2011, 11:00:27 PM

I got it now. Thanks.

BTW is it possible to turn off the writing logfile info to disk? Does it slow things down at all?
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 27, 2011, 11:03:54 PM

Shouldn't slow down. File is rather small. It is overwritten each 5 seconds so if you want to generate graphs or stuff, you gotta write a script that parses that each 5 secs and e.g updates a sql database. hashkill does not keep history of past values.

P.S if you need to tune speed, play with -D and -G2/-G3/-G4 options until you find a balance. -D -G2 works best for me (2x5870/1x6870).
dikidera
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 27, 2011, 11:08:00 PM

Are you solo gat3? I was thinking of getting another 5850 so i can CF, however a 6950 is not a bad choice either(minus the CF).
Should still be profitable considering EVN charges 0.18BGN for 1KW
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 27, 2011, 11:11:13 PM

Pooled.

BTW, I've put an estimations table (for hashkill, but ratios should be OK for other miners though speeds won't be the same):

http://www.gat3way.eu/est.php

It is surprisingly accurate eheh, real speeds vary up to +/- 1.5% as compared to estimations on real tests I've done on different hardware. Formula is rather simple, but anyway we are getting OT here...

So I guess 5850 is more energy efficient than 6950. But then other factors come into play (e.g you may be limited on pcie slots or stuff, then faster cards may be better even if they are not that power-efficient).
dikidera
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
May 27, 2011, 11:16:17 PM

The only problem i have is heat. And summer is also going to take it's toll. But no matter how i look at it, a 6950 uses about 160w at stock and does ~310 Mhash/s.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
May 27, 2011, 11:22:24 PM

Heat is a bitch. But then, it could be much worse - there are places much warmer than Bulgaria. And electricity is cheap ATM (however with that renewable energy EU crap it might soon get much more expensive).
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 01, 2011, 08:36:42 PM

gat3way --

Are you still developing this plugin (optimizing, adding features, etc.)?

In the last day or so, I've been getting this A LOT

  [error] (ocl_bitcoin.c:239) Long polling failure, will retry in 20s!

Moreover, I'm getting

Speed: 283 MHash/sec [cur: 63%] [proc: 147] [subm: 107] [stale: 8] [eff: 72%]
(I'm using deepbit.net)

Which looks like a bit high on the stale shares -- possibly because long polling isn't working?

What do you think it might be?
xen82
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
June 02, 2011, 03:25:38 PM

I'm a proud owner of a system with dual 6990s and the problem that I'm having with hashkill is that my queue keeps running dry. I understand that there is a work around (by spawning multiple hashkill instances), but has there been any progress in keeping the queue saturated? I think that this would be the single biggest improvement for me (considering that I've upgraded to dual PSUs so I'm thinking about about getting a 3rd 6990 for my system), which would make me extremely happy and warrant a donation...
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 02, 2011, 04:30:36 PM

Hello,

I was not aware of that deepbit long polling issue as I don't use deepbit, but I will investigate that.

As for queue depth, I will increase that, but I have no plans to make it configurable.
spiccioli
Legendary
*
Offline Offline

Activity: 1377
Merit: 1000

nec sine labore


View Profile
June 02, 2011, 09:15:54 PM

A new version, this time beta quality.

Fixed:

* progress indicator issues (sigh)
* better queueing mechanism
* ADL thermal monitoring stuff now works correctly - you should have thermal monitoring and stats for all your GPUs
* fixed bug on some systems causing hashkill to stop properly submitting shares
* improved multi-gpu support
* mining.bitcoin.cz now properly reports account info when -a is used with the correct API key

New feature:

* progress now autosaved in a text file, json format. It is autosaved in ~/.hashkill/bitcoin.json . This file can be parsed in order to implement external tools that collect statistics, draw graphs, provide web interface and stuff. This feature will be extended in the future to provide GPU temps info and pool stats.

Download:

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

Please use sudo ./install.sh or run install.sh as root. This is especially important if you have previously installed hashkill - older files need to be overwritten.

Hi gat3way,

I've just downloaded it and started it on a pc with linuxcoin on a usb stick where I'm solo mining with 2x5850 against a bitcoind server (win32) in my office, the program segfaults soon after the BFI_INT magic thing.

[hashkill] Version 0.2.5
[hashkill] Using GPU double mode
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[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 XXX.XXX.XX:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 349524
[hashkill] Doing BFI_INT magic...
Segmentation fault

I can run it against mining.bitcoin.cz, but it spends a lot of time doing nothing.

[hashkill] Version 0.2.5
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[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 mining.bitcoin.cz:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 349524
[hashkill] Doing BFI_INT magic...

Mining statistics...
Speed: 144 MHash/sec [cur: 16%] [proc: 5] [subm: 3] [stale: 0] [eff: 60%]     
Speed: 579 MHash/sec [cur: 84%] [proc: 6] [subm: 3] [stale: 0] [eff: 50%]     
Speed: 135 MHash/sec [cur: 100%] [proc: 6] [subm: 3] [stale: 0] [eff: 50%]     
Speed: 0 MHash/sec [cur: 100%] [proc: 6] [subm: 4] [stale: 0] [eff: 66%]     

with the 0 MHash/sec which happens after every 'unit of work' reaches 100%.

Do you have any hints?

spiccioli.

ps. writing to .hashkill/bitcoin.json on a usb drive could cause wear on the unit, it would be better to have a way to stop it from writing bitcoin.json
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 03, 2011, 07:33:10 AM

At the moment, the only workaround for that is to run a second (or even third) instance. They would balance the load and eliminate that getwork problem. Until now, my attempts to increase queue depth generate other problems especially on slower systems - the stales increase. Thinking of having a separate queue per device, but haven't tried yet.

Quote
ps. writing to .hashkill/bitcoin.json on a usb drive could cause wear on the unit, it would be better to have a way to stop it from writing bitcoin.json

You are having your home directory on the USB device? That's too much writes anyway. I'd suggest you to change it to /dev/shm or stuff.
snoleo
Member
**
Offline Offline

Activity: 77
Merit: 10


A Colt Crossed the River


View Profile
June 04, 2011, 07:01:57 AM

Hello,

I was not aware of that deepbit long polling issue as I don't use deepbit, but I will investigate that.

As for queue depth, I will increase that, but I have no plans to make it configurable.

hashkill is amazing and terrific!
Among all the miners, hashkill is the fastest!

HD 5870, clock: 850

Under SDK v2.4

phoenix -k phatk : 358.88 Mhash/sec
hashkill -D -G4 : 379 Mhash/sec

But there is one problem: I have also encoutered the "Long polling failure" when using deepbit.net;
But when using btcmine.com, everything seems to be fine.

BTW, i wonder if there could be a switch to control the time waiting (default is 20 sec) when disconnected or error occured.

btc123.com - bitcoin Info & Web directory
gigabytecoin
Sr. Member
****
Offline Offline

Activity: 280
Merit: 250


View Profile
June 04, 2011, 07:06:32 AM

Hello,

I was not aware of that deepbit long polling issue as I don't use deepbit, but I will investigate that.

As for queue depth, I will increase that, but I have no plans to make it configurable.

hashkill is amazing and terrific!
Among all the miners, hashkill is the fastest!

HD 5870, clock: 850

Under SDK v2.4

phoenix -k phatk : 358.88 Mhash/sec
hashkill -D -G4 : 379 Mhash/sec

But there is one problem: I have also encoutered the "Long polling failure" when using deepbit.net;
But when using btcmine.com, everything seems to be fine.

BTW, i wonder if there could be a switch to control the time waiting (default is 20 sec) when disconnected or error occured.

It could just be all of the DDoS stress that deepbit.net has been under lately :S
RedLine888
Full Member
***
Offline Offline

Activity: 238
Merit: 109


View Profile
June 04, 2011, 07:22:20 AM

Compile windows version please!!!
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 09:14:52 AM

Reproduced the deepbit LP issue here. Still can't identify the root cause though - it looks like it was unable to establish HTTP connection, which is rather weird. I cannot reproduce that with other pools. Still working on that.

Apart from that, I am working on having a separate queueing per device. This would eliminate the need to run second or third instance on fast multi-gpu systems and is likely to increase efficiency and decrease stale number.

Unfortunately, porting to Windows would take a lot of time and efforts and is not planned in near future. It is more likely that I port that to MacOSX first.
allinvain
Legendary
*
Offline Offline

Activity: 3052
Merit: 1060



View Profile WWW
June 04, 2011, 09:41:33 AM

Compile windows version please!!!

I second that notion...show us that hashkill is better than phoenix Wink


leepfrog
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
June 04, 2011, 10:26:31 AM

Reproduced the deepbit LP issue here. Still can't identify the root cause though - it looks like it was unable to establish HTTP connection, which is rather weird. I cannot reproduce that with other pools. Still working on that.

I think that might be a consequence of the ddos prevention. I've read somewhere in tychos thread that the LP connection is supposed to break every few minutes.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 01:10:25 PM

OK I successfully implemented per-device queueing meaning that you can now get even 4x6990 utilized with a single instance.

I also came to a conclusion that some of you may not like. To maximize pure hashing speed, I had to resort to a couple of things in the host code. Those unfortunately lead to higher risk of producing stale/invalid values as well as rarely under some circumstances, it was possible that a valid share would not get submitted. Also, depending on the connection latency, spikes in overall performance were possible. This was the result of reduced thread synchronization in order to minimize kernel launch latency.

Funny thing is that I had some statistics gathered from a long periods of running the program. The effect of those marginal performance improvements (from 273MH/s to 276MH/s on 6870, from 742MH/s to 754MH/s on 2x5870 at stock speeds) is worth just the decreased successful share submit ratio. Besides that, stales/invalids increase making those performance benefits worthless at least for me.

As a result, you will likely not get the same performance benefits from running the program with -D. I decided to emphasize more on correctness and elimination of rare corner cases rather than on maximizing pure hashing speed at all means. My statistical results are not representative enough yet, but I am kinda glad with that decision given the current data. Note that hashkill at default settings is not getting slower than before, just a number of things that allowed for extra performance using the -D option are not available anymore, so you won't be getting as much as before.

On the other hand, speed would be much more stable with no occasional hiccups.

Pure hashing speed while being a good estimator of the overall mining profit, can be misleading. It's about the speed at which you are submitting correct shares, not the speed you are generating them. Maximizing the second at all possible costs is not always a good idea.

There are also other factors that contribute to the overall profit, one of them being downtime. Some pools have redundant servers and a json-based mechanism to inform the miner to switch over. No miner has implemented this (at least to my knowledge) which in my opinion is a pity.
sniper_sniperson
Full Member
***
Offline Offline

Activity: 124
Merit: 100


View Profile
June 04, 2011, 01:22:08 PM

gat3way, can you give a little how-to for adding/compiling hashkill under current stable 64bit lfs version? What apps we need, are lfs ones enough?
fasti
Member
**
Offline Offline

Activity: 92
Merit: 10


View Profile
June 04, 2011, 01:30:54 PM

Tested for 5 hours with 2x 6950 880cores, Hashkill is telling that it's hashing at 700Mh/s. But hashrate calculated from accepted shares never went over 650Mh/s (1hour calcs). Also very high stale 2.5%.

While poclbm displays the same hashrate as from accepted shares(~680) with 0.35% stale.

1QCcAR3e3wdxr7CcJ8ND1NmWuvLttCJScH
sniper_sniperson
Full Member
***
Offline Offline

Activity: 124
Merit: 100


View Profile
June 04, 2011, 01:40:42 PM


What is this? Some trojan horse masked as free porn game?
Zagitta
Full Member
***
Offline Offline

Activity: 304
Merit: 100


Presale is live!


View Profile
June 04, 2011, 02:45:45 PM

It's a scam, DO NOT DOWNLOAD IT, it will email your wallet to him, just check the thread he created and scroll down to my proof

AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 04, 2011, 04:21:08 PM

Tested for 5 hours with 2x 6950 880cores, Hashkill is telling that it's hashing at 700Mh/s. But hashrate calculated from accepted shares never went over 650Mh/s (1hour calcs). Also very high stale 2.5%.

While poclbm displays the same hashrate as from accepted shares(~680) with 0.35% stale.

This is disturbing -- I've been using Hashkill on my 2 x 6870 for the past week!

Gat3way -- does your new version address this? and when will it be released?

Thanks,

Matthew
snoleo
Member
**
Offline Offline

Activity: 77
Merit: 10


A Colt Crossed the River


View Profile
June 04, 2011, 06:05:05 PM

...

Pure hashing speed while being a good estimator of the overall mining profit, can be misleading. It's about the speed at which you are submitting correct shares, not the speed you are generating them. Maximizing the second at all possible costs is not always a good idea.

There are also other factors that contribute to the overall profit, one of them being downtime. Some pools have redundant servers and a json-based mechanism to inform the miner to switch over. No miner has implemented this (at least to my knowledge) which in my opinion is a pity.

Totally agree.  Smiley

I cannot wait to hear your good news.  Smiley

btc123.com - bitcoin Info & Web directory
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 07:01:38 PM

I guess today. Still doing some LP testing. The deepbit LP failure is fixed. Still haven't imlemented the failover support and I am likely to omit it in the next release.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 07:57:28 PM
Last edit: June 04, 2011, 09:09:37 PM by gat3way

OK - here is the latest version. Fixed is the LP problem with deepbit, added per-device getwork queueing, improved ADL support,

Download:

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

@AngelusWebDesign: I guess your concerns were addressed with this release. In case you had the problems described above, it should fix them.
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 04, 2011, 09:31:42 PM
Last edit: June 04, 2011, 10:36:00 PM by AngelusWebDesign

Ok -- I cleared my browser cache, downloaded it, and overwrote the old version. I also made sure the executable was dated today -- all checked out. I remembered to run "install.sh".

So it's a pretty safe bet I'm running the new version. We'll see how it goes.

Before:
Poclbm on card 1 (Sapphire 6870 - GPU @ 950 MHz): 276.7 Mh/s
Poclbm on card 2 (XFX 6870 - GPU @ 940 MHz): 273.5 Mh/s
TOTAL: 550.2 Mh/s

Hashkill:
Both cards, 565 - 568 Mh/s

So I'm getting my usual boost from Hashkill -- let's hope it translates into more good shares Smiley

UPDATE 4:40 PM: As of right this instant, it's showing 129 submitted shares, 0 stale.
I also just saw, "Long polling: got new block!" -- that's a welcome sight.

It could be my imagination, but my card started getting a bit hotter -- particularly the weaker of the two (XFX). I had to up the fanspeed to 80% from 75% -- now the temps are stabilizing.

When I first ran it -- it MIGHT have been the old version -- it gave me the same error about long polling. I'm looking to see if it happens again. I am pretty sure I'm running the new version now.

BTW, Gat3way, have you ever heard of upping the version number when you release a new version? Wink

Thanks,

Matthew
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 09:41:43 PM

Well it's not an official uprev yet, I still consider bitcoin code experimental. And I have other work related to hash cracking plugins. If we're good with bitcoin (though I'd still like to add some nice features like a list of pools to jump on network failure) I guess 0.2.5 would officially be out somewhere in July Smiley
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 04, 2011, 09:47:21 PM

Sounds good -- thanks!

I have some good figures to compare to -- I was running Poclbm for about 5 hours today; My rate stales was almost exactly 0.7% on each of the 2 cards.

I'll look at it around 9:00 tonight and see if I'm getting less stales. That would be great!

Matthew

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 09:52:52 PM

Stales would be greatly decreased with that release at the cost of some little performance loss (but your pool should support long polling). You can also check against the speed reported by the pool.

Anyway, hashkill still lacks CPU verification prior to sending. So if you are overclocking your cards too much, it is possible that you are sending invalid shares (false positives) and hashkill would count them as "stale". That's another feature I would like to implement, some miners warn you about your hardware running unstable. Unfortunately, hashkill does not do that at present.
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 04, 2011, 10:02:53 PM

I created a new worker on deepbit.net, so I can see what they report as far as % stale shares.

What is the "eff" column mean?

Is that how efficiently I'm finding shares? In other words, how lucky I am?

I've seen it above 100% before. Right now it's at 87%.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 10:11:20 PM

Generally it is, but right now it's not a good measure. Any new LP notification would reset current getwork and cause a new one to be issued per thread and by default we use 2 threads/GPU. When using a pool that supports long polling, efficiency is likely getting slowly down with time. I have to take that into account when calculating the "efficiency" percentage. I guess you can ignore that. Just have a look at deepbit's pool reported speed. It should be either somewhat higher or lower than the speed reported by hashkill. If it is constantly below the speed reported by hashkill (as reported before) then we have a problem.

P.S your speed as reported by the pool would likely drop on a new block notification. That's because the current getwork is being reset and you've got to wait until it's fed with a new one. Depending on your network latency (I am using a wireless connection that is not very fast and stable) you may even see some tens of Mhash/s drop. It should quickly compensate for this though.
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 04, 2011, 10:16:28 PM

Has anything changed with the parameters? You said that multiple GPU setups should use -G 2 -D
But now you're saying that -D has been "de-fanged" and doesn't do much -- is it worth using at all?

Matthew
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 04, 2011, 10:21:00 PM

Well, it's still worth using -D. Default speeds (without -D) should not change and using -D with the latest version tends to be slower than before...but still faster than without -D. -G2 is the default one on AMD cards. I guess -G3 or -G4 would not bring you much (but your CPU usage and power consumption would be up using them)
Disposition
Full Member
***
Offline Offline

Activity: 121
Merit: 100


View Profile
June 05, 2011, 12:04:22 AM

@gat3way

when you get a chance check out the error with btcguild's long polling?
hchc
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
June 05, 2011, 04:18:10 AM

how does this compare with the phatk kernel?
I'm currently getting 302mh/s with 5830 976/300 on Win7

Would hashkill be able to beat that...I guess i could setup a linux machine to find out
Would it + stream sdk work thru a VM? (vmware etc...)

............
.           ▓▓▓▓▓▓▓▓▓▓▓▓▓▓
        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▀  ▀▓▓▓▀  ▀▓▓▀  ▀▓▓▓▓
    ▓▓▓▓▓▄  ▄▓▓▓▄  ▄▓▓▄  ▄▓▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
  ▓▓▓▓▓▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓▓▓▀  ▀▓▓▓▓▓
▓▓▓▓▓▓▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓▓▓▄  ▄▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▀  ▀▓▓▓▀  ▀▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▄  ▄▓▓▓▄  ▄▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
  ▓▓▓▓▓▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
     ▓▓▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
          ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

..           ▓▓▓▓▓▓▓▓▓▓▓▓▓▓
        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▀  ▀▓▓▓▀  ▀▓▓▀  ▀▓▓▓▓
    ▓▓▓▓▓▄  ▄▓▓▓▄  ▄▓▓▄  ▄▓▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
  ▓▓▓▓▓▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓▓▓▀  ▀▓▓▓▓▓
▓▓▓▓▓▓▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓▓▓▄  ▄▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▀  ▀▓▓▓▀  ▀▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▄  ▄▓▓▓▄  ▄▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
  ▓▓▓▓▓▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▀  ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
     ▓▓▓▓▄  ▄▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
          ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

.............
supa
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 05, 2011, 05:01:41 AM
Last edit: June 05, 2011, 05:52:59 AM by supa

Random question -

The last time I tried this, it kept complaining about long polling failure while using eligius.st

Update -
I just tried it again and it constantly complains of long polling on eligius.

I'm also getting nearly 20% stale/invalid... Huh
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 05, 2011, 08:01:16 AM

If you have downloaded prior versions, please make sure you are using the new version. Do:

Quote
md5sum /usr/bin/hashkill-gpu

For the 32-bit one it should return:
cda0feb360a2e81c5c93fbcfac86c6e6

And for the 64-bit one it should be:
855ec7e26d10b12845820dfbed1d9175

If those checksums don't match, please make sure:

* You don't have a browser caching issue with the download. Or if you have used wget, make sure you don't have it downloaded already so that the new download would be renamed to hashkill-....tgz.1
* You run the install.sh script with root privileges so that it is able to overwrite the old binary
supa
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 05, 2011, 08:05:48 AM


I have the newest version.

Can someone quickly test against mining.eligius.st port 8337 or 80 ?

The beginning output says Long Polling was detected, but I get the warning about long polling failing every 20 seconds.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 05, 2011, 08:10:46 AM

Ah, just tried. Dammit, they use relative URLs for that. OK, gotta fix that sorry.
supa
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 05, 2011, 06:24:21 PM


.... did you fix it?  I'm not sure if I should be waiting for you to post a new download link or try the old download link and hope it's the new version? Smiley
RedLine888
Full Member
***
Offline Offline

Activity: 238
Merit: 109


View Profile
June 05, 2011, 07:02:16 PM

Hi!

Will there be a version for WINDOWS users?
dishwara
Legendary
*
Offline Offline

Activity: 1854
Merit: 1016



View Profile
June 05, 2011, 07:23:18 PM

Hi!

Will there be a version for WINDOWS users?

Seems No & can't

http://forum.bitcoin.org/index.php?topic=12053

ACCOUNT WAS HACKED FROM 2016-2019. NOW RECLAIMED BY ORIGINAL USER D.ISHWARA
SORRY IF ANYONE GOT CHEATED BY THE IMPOSTOR
ALL POSTS AFTER MARCH 2016 BECOMES OBSOLETE & WILL BE DELETED AFTER I READ IT.
RedLine888
Full Member
***
Offline Offline

Activity: 238
Merit: 109


View Profile
June 05, 2011, 07:34:22 PM

Thanx.

that is sad(
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 05, 2011, 08:16:18 PM

The error is happening again, Gat3way.

I just got 1% stales I noticed, and I looked at my terminal output and it's giving the "error" Long polling failure, will retry in 20s!

The error happened here: _bitcoin.c:232


hashkill-gpu -G 2 -D -p bitcoin XXXX:XXXX:deepbit.net:8332

I checked the MD5, and it checked out to be the latest version.

Hopefully you can fix it -- thanks!

Matthew
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 06, 2011, 07:46:45 AM

Will have a look. It may also be a problem on the deepbit.net's side. Did it continue to throw that error or it stopped? Did restarting the miner fix that?

I am going to commit some fixes to the LP code today, fixing the eligius LP issue. Will have a look again at that.

BTW did you have a look at the speed as reported by deepbit?
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
June 06, 2011, 03:36:35 PM
Last edit: June 06, 2011, 03:52:20 PM by AngelusWebDesign

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

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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 06, 2011, 05:00:02 PM

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
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
June 06, 2011, 05:10:32 PM

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
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 06, 2011, 05:16:58 PM

Quote
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).

Quote
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
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
June 06, 2011, 05:20:55 PM

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
Member
**
Offline Offline

Activity: 92
Merit: 10


View Profile
June 06, 2011, 05:45:28 PM

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.

1QCcAR3e3wdxr7CcJ8ND1NmWuvLttCJScH
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 06, 2011, 05:58:11 PM

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

Activity: 92
Merit: 10


View Profile
June 06, 2011, 06:08:01 PM

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

1QCcAR3e3wdxr7CcJ8ND1NmWuvLttCJScH
fasti
Member
**
Offline Offline

Activity: 92
Merit: 10


View Profile
June 06, 2011, 10:52:48 PM

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).

1QCcAR3e3wdxr7CcJ8ND1NmWuvLttCJScH
sal002
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500


View Profile WWW
June 07, 2011, 12:31:38 AM

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
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500


View Profile WWW
June 07, 2011, 12:52:21 AM

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

I'll do it on linuxcoin instead.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 07, 2011, 05:43:50 AM

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
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
June 07, 2011, 10:13:40 AM

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
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
June 07, 2011, 10:21:10 AM


Hello gat3way, would it be possible to edit the first post with the 32 bit link.
leepfrog
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
June 07, 2011, 11:18:43 AM

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
Member
**
Offline Offline

Activity: 92
Merit: 10


View Profile
June 07, 2011, 11:55:33 AM

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?

1QCcAR3e3wdxr7CcJ8ND1NmWuvLttCJScH
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 07, 2011, 12:25:55 PM

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
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
June 07, 2011, 12:28:52 PM

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
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
June 07, 2011, 04:56:55 PM

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
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
June 07, 2011, 05:09:19 PM

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 Smiley
xen82
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
June 07, 2011, 05:11:47 PM

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...

You need to have X Windows started, and be logged in (in the case of say GDM). Then you can export your DISPLAY settings and start the app as that user. Hope that helps.
dudel42
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
June 07, 2011, 05:14:33 PM

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...

You need to have X Windows started, and be logged in (in the case of say GDM). Then you can export your DISPLAY settings and start the app as that user. Hope that helps.

yeah, that's what I'm doing now.. setup ubuntu to autologin on startup. just thought there was a way of using it without being logged in on the console, like with aticonfig.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 07, 2011, 05:18:24 PM

Quote
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.

Hmpf, that should have been resolved already. You are sure you ran install.sh with root privs?


Quote
   * config file

That would be nice...but what exactly are we going to configure that is hard to configure via command-line?

Quote
   * some type of RPC (JSON-RPC anyone) interface for managing operation and querying status of miners (hash speed, temp, pause resume queue, etc)

Right now there is such mechanism, but it's like read-only...you can have a look at the ~/.hashkill/bitcoin.json. It exports hash speed and etc stuff in json format. It sucks though and definitely it would be good to control it remotely.

Quote
   * ability to adjust fan speeds automatically and provide ability to set min and max speeds per card

This is a very bad idea. Tried doing that in the past. The end result being something that works good on one system and goes crazy on another (well I guess that's what the whole GPU programming is about anyway). Overall I am not inclined

Quote
   * 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

This is an interesting idea that never occured to me before. Worth trying.

Quote
   * an aggressiveness setting

I guess -D and -G work that way. -D -G4 is rather aggressive while just -G1 is the most responsive.
gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 07, 2011, 05:22:20 PM

Quote
yeah, that's what I'm doing now.. setup ubuntu to autologin on startup. just thought there was a way of using it without being logged in on the console, like with aticonfig.

Have a look at this:

http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=19

I am running hashkill via ssh. No logged gnome user required. Also no local console logins needed.
dudel42
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
June 07, 2011, 06:34:35 PM

great info, thx, will change that on the next reboot.

my problem right now lies with the following:

Code:
[proc: 1464] [subm: 553] [stale: 499] [eff: 37%]

this doesn't look all that good...

edit: i had it started with -D -G4 for experimenting with different parameters, guess that was causing it.. with -G2 things look much better.
xen82
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
June 07, 2011, 07:57:22 PM

Quote
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.

Hmpf, that should have been resolved already. You are sure you ran install.sh with root privs?


Quote
   * config file

That would be nice...but what exactly are we going to configure that is hard to configure via command-line?

Quote
   * some type of RPC (JSON-RPC anyone) interface for managing operation and querying status of miners (hash speed, temp, pause resume queue, etc)

Right now there is such mechanism, but it's like read-only...you can have a look at the ~/.hashkill/bitcoin.json. It exports hash speed and etc stuff in json format. It sucks though and definitely it would be good to control it remotely.

Quote
   * ability to adjust fan speeds automatically and provide ability to set min and max speeds per card

This is a very bad idea. Tried doing that in the past. The end result being something that works good on one system and goes crazy on another (well I guess that's what the whole GPU programming is about anyway). Overall I am not inclined

Quote
   * 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

This is an interesting idea that never occured to me before. Worth trying.

Quote
   * an aggressiveness setting

I guess -D and -G work that way. -D -G4 is rather aggressive while just -G1 is the most responsive.


I used sudo ./install.sh so there were no permissions problems. Quick note, when you release an updated version of hashkill, please change the filename with every revision, I'm sure it will help with ambiguity and the bloody web proxies I deal with. Smiley

Config files keep things easy to manage when more and more features come into play.

At present I have 2x6990s running, and due to current cooling constraints, the 6990 that is running up top (gpu0 & gpu1) is running 15% hotter than the bottom card. Due to this, I am using phoenix and set the aggressiveness to 5 on GPU0, 7 on GPU1 and 12 on GPU2 and 3. I tried playing around with D and G, however I wasn't able to keep the card from overheating.

With regards to the temperature threshold in the current implementation, do you poll the SDK until the temperature drops 10C below threshold and begin processing, or do you have a predetermined time based time out.

With regards to prioritizing workloads to keep constant temperatures on the GPUs, it would help to prolong reduce wear from the cards heating up and cooling down.

BTW, have you tested hashkill with btcguild?
gominoa
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
June 08, 2011, 02:34:36 AM

Im running hashkill on a headless machine. Everything works fine if I access via ssh and manually start hashkill. Im trying to have it started automatically by a process manager in a non interactive shell. When I started this way i get the following output:

Code:
[error] (ocl_bitcoin.c:930) Statistics about that pool (pit.deepbit.net) not supported.

thousands of times. Literally 10mb of that error per second if I log the output to a file. Ive tried running like

Code:
echo | hashkill-gpu
or
Code:
hashkill-gpu < /dev/null

with no change. I would like some kind of daemon mode switch that completely disables pool stats and replaces the ^M^M^M in the MHash/sec output with a newline.

Thanks
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3472
Merit: 1638



View Profile
June 08, 2011, 06:50:04 AM

gat3way:

When BFI_INT was implemented on poclbm lower mem. clock produced speed improvement and lower power usage on linux.

They may be related but icbw.

gat3way
Sr. Member
****
Offline Offline

Activity: 256
Merit: 250


View Profile
June 08, 2011, 08:34:13 AM

I think those are not related. Besides, hashkill does the BFI_INT replacement as well.

Quote

Im trying to have it started automatically by a process manager in a non interactive shell. When I started this way i get the following output:

echo | hashkill-gpu

or

hashkill-gpu < /dev/null


with no change. I would like some kind of daemon mode switch that completely disables pool stats and replaces the ^M^M^M in the MHash/sec output with a newline.

Probably hashkill-gpu < /dev/zero instead?
dudel42
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
June 08, 2011, 08:58:53 AM

Still having some problems with stale numbers here:

Code:
[proc: 1096] [subm: 1000] [stale: 63] [eff: 91%]

maybe this field could be separated, so we know whether it's actually a hw calculation error or a real stale share with the pool?

the number also varies over time for me, no stales for a long time, then several in a short amount of time, then stable again. But I have no idea if this is my hw's fault or not.