Topic: hashkill - testing bitcoin miner plugin - page 11. (Read 90959 times)

Well it's not an official uprev yet, I still consider bitcoin code experimental. And I have other work related to hash cracking plugins. If we're good with bitcoin (though I'd still like to add some nice features like a list of pools to jump on network failure) I guess 0.2.5 would officially be out somewhere in July

Ok -- I cleared my browser cache, downloaded it, and overwrote the old version. I also made sure the executable was dated today -- all checked out. I remembered to run "install.sh".

So it's a pretty safe bet I'm running the new version. We'll see how it goes.

Before:
Poclbm on card 1 (Sapphire 6870 - GPU @ 950 MHz): 276.7 Mh/s
Poclbm on card 2 (XFX 6870 - GPU @ 940 MHz): 273.5 Mh/s
TOTAL: 550.2 Mh/s

Hashkill:
Both cards, 565 - 568 Mh/s

So I'm getting my usual boost from Hashkill -- let's hope it translates into more good shares

UPDATE 4:40 PM: As of right this instant, it's showing 129 submitted shares, 0 stale.
I also just saw, "Long polling: got new block!" -- that's a welcome sight.

It could be my imagination, but my card started getting a bit hotter -- particularly the weaker of the two (XFX). I had to up the fanspeed to 80% from 75% -- now the temps are stabilizing.

When I first ran it -- it MIGHT have been the old version -- it gave me the same error about long polling. I'm looking to see if it happens again. I am pretty sure I'm running the new version now.

BTW, Gat3way, have you ever heard of upping the version number when you release a new version?

Thanks,

Matthew

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.

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.

Totally agree. 

I cannot wait to hear your good news. 

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

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

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

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.

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?

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.

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.

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

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.

Compile windows version please!!!

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

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.

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.


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.

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

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.