Topic: hashkill - testing bitcoin miner plugin - page 8. (Read 90959 times)
You need 2.3 or above, sorry. It also works on 2.2, but speeds are not optimal.
2.1
What SDK version you use?
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
[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
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
hashkill 0.2.5: 367Mhash/s
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.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.
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?
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.
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".
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)?
so hashkill could be more efficient when running on pools with lp support (more of my hashing power actually registering with the pool)?
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).
Does your pool support long polling?
Still having some problems with stale numbers here:
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.
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.
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?
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?
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.
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.
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:
thousands of times. Literally 10mb of that error per second if I log the output to a file. Ive tried running like
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
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
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.
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?
great info, thx, will change that on the next reboot.
my problem right now lies with the following:
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.
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.
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.
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.
Jump to: