hashkill - testing bitcoin miner plugin

[xen82]

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.

[1715019585]

1715019585

[1715019585]

1715019585

[1715019585]

1715019585

[dudel42]

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]

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?

   * config file

That would be nice...but what exactly are we going to configure that is hard to configure via command-line?

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

   * 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

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

   * an aggressiveness setting

I guess -D and -G work that way. -D -G4 is rather aggressive while just -G1 is the most responsive.

[gat3way]

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]

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]

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?

   * config file

That would be nice...but what exactly are we going to configure that is hard to configure via command-line?

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

   * 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

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

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

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]

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]

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]

I think those are not related. Besides, hashkill does the BFI_INT replacement as well.

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]

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.

[gat3way]

Does your pool support long polling?

[dudel42]

Does your pool support long polling?

slush's pool, http://mining.bitcoin.cz

[gat3way]

Yeah, that's expected then, they have no long polling support. When block is solved there is no mechanism to inform you about that and hashkill is still working on a stale getwork (then eventually submits a share that is stale already). mining.bitcoin.cz does not "punish" you for submitting stales though (at least to my knowledge).

[dudel42]

hmm, running guiminer on a another (windows) machine results in less then 1% stales on slush.

so hashkill could be more efficient when running on pools with lp support (more of my hashing power actually registering with the pool)?

[gat3way]

Nope, there is nothing that can be done in that case and it's a matter of luck. You will see higher stale percentage on "shorter" blocks and lower stale percentage on "longer blocks".

[gominoa]

Probably hashkill-gpu < /dev/zero instead?

Got it working with

Code:

hashkill-gpu < /dev/stdin

Also hexedited the binary to remove the ^M^M^M so now Im happy.
Thanks for the cool miner.

[Dusty]

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.

Very nice, thanks.

The problem is I've no /dev/dri directory (I'm running Ubuntu 11.04), so the chmod that they provide fails.

Is this a problem? Why I don't have that directory?

[DonChate]

thanks for the hard work building the bitcoin plugin to your great app. outperforms phoenix on the 5870, and I love how you don't need multiple instances!

Code:

phoenix-miner r100: 348Mhash/s
hashkill 0.2.5: 367Mhash/s

[sagefool1975]

Hmm getting seg fault myself:

[hashkill] Version 0.2.5
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] GPU0: ATI Radeon HD 5800 Series [busy:0%] [temp:52C]
[hashkill] GPU1: ATI Radeon HD 2600 XT [busy:0%] [temp:65C]
[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: 1374888
[hashkill] Doing BFI_INT magic...
[hashkill] Long polling available, starting LP thread.
Segmentation fault

[gat3way]

What SDK version you use?