Bitcoin Forum
December 04, 2016, 08:33:51 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 »  All
  Print  
Author Topic: hashkill - testing bitcoin miner plugin  (Read 85451 times)
AngelusWebDesign
Sr. Member
****
Offline Offline

Activity: 392


View Profile
June 01, 2011, 08:36:42 PM
 #181

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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480883631
Hero Member
*
Offline Offline

Posts: 1480883631

View Profile Personal Message (Offline)

Ignore
1480883631
Reply with quote  #2

1480883631
Report to moderator
1480883631
Hero Member
*
Offline Offline

Posts: 1480883631

View Profile Personal Message (Offline)

Ignore
1480883631
Reply with quote  #2

1480883631
Report to moderator
1480883631
Hero Member
*
Offline Offline

Posts: 1480883631

View Profile Personal Message (Offline)

Ignore
1480883631
Reply with quote  #2

1480883631
Report to moderator
xen82
Newbie
*
Offline Offline

Activity: 22


View Profile
June 02, 2011, 03:25:38 PM
 #182

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
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 02, 2011, 04:30:36 PM
 #183

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
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
June 02, 2011, 09:15:54 PM
 #184

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
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 03, 2011, 07:33:10 AM
 #185

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.

Quote
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
Member
**
Offline Offline

Activity: 79


A Colt Crossed the River


View Profile
June 04, 2011, 07:01:57 AM
 #186

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.

btc123.com - bitcoin Info & Web directory
gigabytecoin
Sr. Member
****
Offline Offline

Activity: 280


View Profile
June 04, 2011, 07:06:32 AM
 #187

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
Full Member
***
Offline Offline

Activity: 163



View Profile
June 04, 2011, 07:22:20 AM
 #188

Compile windows version please!!!

If I helped and You do wanna thank:
1FoiQYVPtUwWWnrYe1oYV3GCtJP8YBe1fv
Feel free to PM if you're in a need of any help
-------------------------------------------------------------------
gat3way
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 04, 2011, 09:14:52 AM
 #189

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
Legendary
*
Offline Offline

Activity: 1988



View Profile
June 04, 2011, 09:41:33 AM
 #190

Compile windows version please!!!

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


leepfrog
Full Member
***
Offline Offline

Activity: 126

Hopity Hopity Hop


View Profile
June 04, 2011, 10:26:31 AM
 #191

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.

-----Crypto--Investor----Family--Guy-----All--Around--Winner----
gat3way
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 04, 2011, 01:10:25 PM
 #192

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
Full Member
***
Offline Offline

Activity: 124


View Profile
June 04, 2011, 01:22:08 PM
 #193

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
Member
**
Offline Offline

Activity: 92


View Profile
June 04, 2011, 01:30:54 PM
 #194

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.

1QCcAR3e3wdxr7CcJ8ND1NmWuvLttCJScH
sniper_sniperson
Full Member
***
Offline Offline

Activity: 124


View Profile
June 04, 2011, 01:40:42 PM
 #195


What is this? Some trojan horse masked as free porn game?
Zagitta
Member
**
Offline Offline

Activity: 84


View Profile
June 04, 2011, 02:45:45 PM
 #196

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
Sr. Member
****
Offline Offline

Activity: 392


View Profile
June 04, 2011, 04:21:08 PM
 #197

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
Member
**
Offline Offline

Activity: 79


A Colt Crossed the River


View Profile
June 04, 2011, 06:05:05 PM
 #198

...

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

I cannot wait to hear your good news.  Smiley

btc123.com - bitcoin Info & Web directory
gat3way
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 04, 2011, 07:01:38 PM
 #199

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
Sr. Member
****
Offline Offline

Activity: 256


View Profile
June 04, 2011, 07:57:28 PM
 #200

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.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!