hashkill - testing bitcoin miner plugin - page 16.

bolapara

member

Activity: 78

Merit: 10

Quote from: Gnaffel on May 09, 2011, 09:15:54 AM

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.

Gnaffel

newbie

Activity: 53

Merit: 0

Quote from: gat3way on May 09, 2011, 12:04:43 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

gat3way

sr. member

Activity: 256

Merit: 250

Rather weird. Tried with another pool?

Gnaffel

newbie

Activity: 53

Merit: 0

Quote from: gat3way on May 09, 2011, 09:23:27 AM

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

SDK 2.3

Quote from: Gnaffel on May 08, 2011, 09:04:38 AM

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: https://bitcointalksearch.org/topic/m.108953

gat3way

sr. member

Activity: 256

Merit: 250

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

Gnaffel

newbie

Activity: 53

Merit: 0

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

Gnaffel

newbie

Activity: 53

Merit: 0

Quote from: gat3way on May 09, 2011, 05:20:13 AM

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

gat3way

sr. member

Activity: 256

Merit: 250

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

sniper_sniperson

full member

Activity: 124

Merit: 100

What exactly are doing these options?

gat3way

sr. member

Activity: 256

Merit: 250

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.

gat3way

sr. member

Activity: 256

Merit: 250

Thanks.

Gnaffel

newbie

Activity: 53

Merit: 0

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

Activity: 256

Merit: 250

Nice

BTW may I have your hardware info and speed just for statistic purposes?

Gnaffel

newbie

Activity: 53

Merit: 0

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: https://bitcointalksearch.org/topic/m.108953

gat3way

sr. member

Activity: 256

Merit: 250

@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.

sarah_tonin

newbie

Activity: 4

Merit: 0

Quote from: gat3way on May 07, 2011, 07:07:43 AM

Thanks. Is that on stock clocks or OC?

Entirely stock!

Jaime Frontero

full member

Activity: 126

Merit: 100

Quote from: gat3way on May 07, 2011, 04:57:20 PM

Quote from: Jaime Frontero on May 06, 2011, 05:57:26 PM

Quote from: gat3way on May 06, 2011, 05:49:34 PM

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.

gat3way

sr. member

Activity: 256

Merit: 250

Quote from: Jaime Frontero on May 06, 2011, 05:57:26 PM

Quote from: gat3way on May 06, 2011, 05:49:34 PM

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

mskwik

full member

Activity: 125

Merit: 100

Quote from: gat3way on May 07, 2011, 05:25:19 AM

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

Activity: 256

Merit: 250

Thanks. Is that on stock clocks or OC?

Topic: hashkill - testing bitcoin miner plugin - page 16. (Read 90911 times)