hashkill - testing bitcoin miner plugin - page 18.

gat3way

sr. member

Activity: 256

Merit: 250

Quote from: martok on May 04, 2011, 06:00:25 PM

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.

smgoller

newbie

Activity: 23

Merit: 0

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

Jaime Frontero

full member

Activity: 126

Merit: 100

Quote from: martok on May 04, 2011, 06:00:25 PM

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.

martok

full member

Activity: 140

Merit: 100

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

Activity: 126

Merit: 100

Quote from: gat3way on May 04, 2011, 05:36:25 PM

It overwrites, no need to delete.

thx.

gat3way

sr. member

Activity: 256

Merit: 250

It overwrites, no need to delete.

Jaime Frontero

full member

Activity: 126

Merit: 100

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?

Jaime Frontero

full member

Activity: 126

Merit: 100

Quote from: gat3way on May 04, 2011, 04:05:55 PM

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

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!

bolapara

member

Activity: 78

Merit: 10

Quote from: gat3way on May 04, 2011, 02:49:35 PM

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

gat3way

sr. member

Activity: 256

Merit: 250

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

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.

gat3way

sr. member

Activity: 256

Merit: 250

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.

Jaime Frontero

full member

Activity: 126

Merit: 100

Quote from: gat3way on May 04, 2011, 02:23:30 PM

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

-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

Activity: 256

Merit: 250

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

bolapara

member

Activity: 78

Merit: 10

Quote from: gat3way on May 04, 2011, 02:03:25 PM

@bolapara: did you use the -D option?

Used -G4 -D

gat3way

sr. member

Activity: 256

Merit: 250

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.

xyzzy

newbie

Activity: 8

Merit: 0

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

Activity: 256

Merit: 250

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

Jaime Frontero

full member

Activity: 126

Merit: 100

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 ::127.0.0.1:8332 -a

[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

Activity: 256

Merit: 250

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.

mskwik

full member

Activity: 125

Merit: 100

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.

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