It's not hashkill.
Just do smth like:
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Topic: hashkill - testing bitcoin miner plugin - page 14. (Read 90959 times)
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)
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.
Network connectivity restored.
yep, download is working again
Network connectivity restored.
Apparently there are connectivity problems. Unfortunately I am away and can't do anything for the next 4-5 hours 
Oke, will try again later
Apparently there are connectivity problems. Unfortunately I am away and can't do anything for the next 4-5 hours
i too got page error. Files is not there.
I cant download the latest hashkill. Your site is not reachable for more than 12 hours now.
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
* 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
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
:~$ 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?
I use sourceforge's SVN, but I haven't commited the bitcoin code yet
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?
@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.
@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
:~$ 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 :]
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 ?
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
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 ?
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 ?
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
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
http://www.gat3way.eu/est.php
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
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
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).
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
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
http://www.gat3way.eu/est.php
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
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
http://www.gat3way.eu/est.php
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
Hmmm could you try with -G1 command line option?
Jump to: