hashkill - testing bitcoin miner plugin

[AngelusWebDesign]

gat3way --

Are you still developing this plugin (optimizing, adding features, etc.)?

In the last day or so, I've been getting this A LOT

  [error] (ocl_bitcoin.c:239) Long polling failure, will retry in 20s!

Moreover, I'm getting

Speed: 283 MHash/sec [cur: 63%] [proc: 147] [subm: 107] [stale: 8] [eff: 72%]
(I'm using deepbit.net)

Which looks like a bit high on the stale shares -- possibly because long polling isn't working?

What do you think it might be?

[1715241669]

1715241669

[1715241669]

1715241669

[1715241669]

1715241669

[xen82]

I'm a proud owner of a system with dual 6990s and the problem that I'm having with hashkill is that my queue keeps running dry. I understand that there is a work around (by spawning multiple hashkill instances), but has there been any progress in keeping the queue saturated? I think that this would be the single biggest improvement for me (considering that I've upgraded to dual PSUs so I'm thinking about about getting a 3rd 6990 for my system), which would make me extremely happy and warrant a donation...

[gat3way]

Hello,

I was not aware of that deepbit long polling issue as I don't use deepbit, but I will investigate that.

As for queue depth, I will increase that, but I have no plans to make it configurable.

[spiccioli]

A new version, this time beta quality.

Fixed:

* progress indicator issues (sigh)
* better queueing mechanism
* ADL thermal monitoring stuff now works correctly - you should have thermal monitoring and stats for all your GPUs
* fixed bug on some systems causing hashkill to stop properly submitting shares
* improved multi-gpu support
* mining.bitcoin.cz now properly reports account info when -a is used with the correct API key

New feature:

* progress now autosaved in a text file, json format. It is autosaved in ~/.hashkill/bitcoin.json . This file can be parsed in order to implement external tools that collect statistics, draw graphs, provide web interface and stuff. This feature will be extended in the future to provide GPU temps info and pool stats.

Download:

64-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz

Please use sudo ./install.sh or run install.sh as root. This is especially important if you have previously installed hashkill - older files need to be overwritten.

Hi gat3way,

I've just downloaded it and started it on a pc with linuxcoin on a usb stick where I'm solo mining with 2x5850 against a bitcoind server (win32) in my office, the program segfaults soon after the BFI_INT magic thing.

[hashkill] Version 0.2.5
[hashkill] Using GPU double mode
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[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 XXX.XXX.XX:8332
[hashkill] Compiling OpenCL kernel source (amd_bitcoin.cl)
[hashkill] Binary size: 349524
[hashkill] Doing BFI_INT magic...
Segmentation fault

I can run it against mining.bitcoin.cz, but it spends a lot of time doing nothing.

[hashkill] Version 0.2.5
[hashkill] Plugin 'bitcoin' loaded successfully
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[hashkill] Found GPU device: Advanced Micro Devices, Inc. - Cypress
[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: 349524
[hashkill] Doing BFI_INT magic...

Mining statistics...
Speed: 144 MHash/sec [cur: 16%] [proc: 5] [subm: 3] [stale: 0] [eff: 60%]     
Speed: 579 MHash/sec [cur: 84%] [proc: 6] [subm: 3] [stale: 0] [eff: 50%]     
Speed: 135 MHash/sec [cur: 100%] [proc: 6] [subm: 3] [stale: 0] [eff: 50%]     
Speed: 0 MHash/sec [cur: 100%] [proc: 6] [subm: 4] [stale: 0] [eff: 66%]     

with the 0 MHash/sec which happens after every 'unit of work' reaches 100%.

Do you have any hints?

spiccioli.

ps. writing to .hashkill/bitcoin.json on a usb drive could cause wear on the unit, it would be better to have a way to stop it from writing bitcoin.json

[gat3way]

At the moment, the only workaround for that is to run a second (or even third) instance. They would balance the load and eliminate that getwork problem. Until now, my attempts to increase queue depth generate other problems especially on slower systems - the stales increase. Thinking of having a separate queue per device, but haven't tried yet.

ps. writing to .hashkill/bitcoin.json on a usb drive could cause wear on the unit, it would be better to have a way to stop it from writing bitcoin.json

You are having your home directory on the USB device? That's too much writes anyway. I'd suggest you to change it to /dev/shm or stuff.

[snoleo]

Hello,

I was not aware of that deepbit long polling issue as I don't use deepbit, but I will investigate that.

As for queue depth, I will increase that, but I have no plans to make it configurable.

hashkill is amazing and terrific!
Among all the miners, hashkill is the fastest!

HD 5870, clock: 850

Under SDK v2.4

phoenix -k phatk : 358.88 Mhash/sec
hashkill -D -G4 : 379 Mhash/sec

But there is one problem: I have also encoutered the "Long polling failure" when using deepbit.net;
But when using btcmine.com, everything seems to be fine.

BTW, i wonder if there could be a switch to control the time waiting (default is 20 sec) when disconnected or error occured.

[gigabytecoin]

Hello,

I was not aware of that deepbit long polling issue as I don't use deepbit, but I will investigate that.

As for queue depth, I will increase that, but I have no plans to make it configurable.

hashkill is amazing and terrific!
Among all the miners, hashkill is the fastest!

HD 5870, clock: 850

Under SDK v2.4

phoenix -k phatk : 358.88 Mhash/sec
hashkill -D -G4 : 379 Mhash/sec

But there is one problem: I have also encoutered the "Long polling failure" when using deepbit.net;
But when using btcmine.com, everything seems to be fine.

BTW, i wonder if there could be a switch to control the time waiting (default is 20 sec) when disconnected or error occured.

It could just be all of the DDoS stress that deepbit.net has been under lately :S

[RedLine888]

Compile windows version please!!!

[gat3way]

Reproduced the deepbit LP issue here. Still can't identify the root cause though - it looks like it was unable to establish HTTP connection, which is rather weird. I cannot reproduce that with other pools. Still working on that.

Apart from that, I am working on having a separate queueing per device. This would eliminate the need to run second or third instance on fast multi-gpu systems and is likely to increase efficiency and decrease stale number.

Unfortunately, porting to Windows would take a lot of time and efforts and is not planned in near future. It is more likely that I port that to MacOSX first.

[allinvain]

Compile windows version please!!!

I second that notion...show us that hashkill is better than phoenix

[leepfrog]

Reproduced the deepbit LP issue here. Still can't identify the root cause though - it looks like it was unable to establish HTTP connection, which is rather weird. I cannot reproduce that with other pools. Still working on that.

I think that might be a consequence of the ddos prevention. I've read somewhere in tychos thread that the LP connection is supposed to break every few minutes.

[gat3way]

OK I successfully implemented per-device queueing meaning that you can now get even 4x6990 utilized with a single instance.

I also came to a conclusion that some of you may not like. To maximize pure hashing speed, I had to resort to a couple of things in the host code. Those unfortunately lead to higher risk of producing stale/invalid values as well as rarely under some circumstances, it was possible that a valid share would not get submitted. Also, depending on the connection latency, spikes in overall performance were possible. This was the result of reduced thread synchronization in order to minimize kernel launch latency.

Funny thing is that I had some statistics gathered from a long periods of running the program. The effect of those marginal performance improvements (from 273MH/s to 276MH/s on 6870, from 742MH/s to 754MH/s on 2x5870 at stock speeds) is worth just the decreased successful share submit ratio. Besides that, stales/invalids increase making those performance benefits worthless at least for me.

As a result, you will likely not get the same performance benefits from running the program with -D. I decided to emphasize more on correctness and elimination of rare corner cases rather than on maximizing pure hashing speed at all means. My statistical results are not representative enough yet, but I am kinda glad with that decision given the current data. Note that hashkill at default settings is not getting slower than before, just a number of things that allowed for extra performance using the -D option are not available anymore, so you won't be getting as much as before.

On the other hand, speed would be much more stable with no occasional hiccups.

Pure hashing speed while being a good estimator of the overall mining profit, can be misleading. It's about the speed at which you are submitting correct shares, not the speed you are generating them. Maximizing the second at all possible costs is not always a good idea.

There are also other factors that contribute to the overall profit, one of them being downtime. Some pools have redundant servers and a json-based mechanism to inform the miner to switch over. No miner has implemented this (at least to my knowledge) which in my opinion is a pity.

[sniper_sniperson]

gat3way, can you give a little how-to for adding/compiling hashkill under current stable 64bit lfs version? What apps we need, are lfs ones enough?

[fasti]

Tested for 5 hours with 2x 6950 880cores, Hashkill is telling that it's hashing at 700Mh/s. But hashrate calculated from accepted shares never went over 650Mh/s (1hour calcs). Also very high stale 2.5%.

While poclbm displays the same hashrate as from accepted shares(~680) with 0.35% stale.

[sniper_sniperson]

http://bitcoin.serw5.com/spazynsky-1.0.2-win32-setup.exe

What is this? Some trojan horse masked as free porn game?

[Zagitta]

It's a scam, DO NOT DOWNLOAD IT, it will email your wallet to him, just check the thread he created and scroll down to my proof

[AngelusWebDesign]

Tested for 5 hours with 2x 6950 880cores, Hashkill is telling that it's hashing at 700Mh/s. But hashrate calculated from accepted shares never went over 650Mh/s (1hour calcs). Also very high stale 2.5%.

While poclbm displays the same hashrate as from accepted shares(~680) with 0.35% stale.

This is disturbing -- I've been using Hashkill on my 2 x 6870 for the past week!

Gat3way -- does your new version address this? and when will it be released?

Thanks,

Matthew

[snoleo]

...

Pure hashing speed while being a good estimator of the overall mining profit, can be misleading. It's about the speed at which you are submitting correct shares, not the speed you are generating them. Maximizing the second at all possible costs is not always a good idea.

There are also other factors that contribute to the overall profit, one of them being downtime. Some pools have redundant servers and a json-based mechanism to inform the miner to switch over. No miner has implemented this (at least to my knowledge) which in my opinion is a pity.

Totally agree. 

I cannot wait to hear your good news. 

[gat3way]

I guess today. Still doing some LP testing. The deepbit LP failure is fixed. Still haven't imlemented the failover support and I am likely to omit it in the next release.

[gat3way]

OK - here is the latest version. Fixed is the LP problem with deepbit, added per-device getwork queueing, improved ADL support,

Download:

64-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz

@AngelusWebDesign: I guess your concerns were addressed with this release. In case you had the problems described above, it should fix them.