|
gat3way (OP)
|
 |
June 24, 2011, 02:37:05 PM |
|
hashkill-cpu does not support bitcoin mining (yet). Use hashkill-gpu.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
According to NIST and ECRYPT II, the cryptographic algorithms used in
Bitcoin are expected to be strong until at least 2030. (After that, it
will not be too difficult to transition to different algorithms.)
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
burp
Member
 Offline
Activity: 98
Merit: 10
|
|
June 24, 2011, 03:16:02 PM |
|
With fglrx 11.4 I got about 534MH/s with my two cards, with 11.6 I now get 350MH. Is this a hashkill or fglrx issue?
EDIT: Interesting, when I lower the memory clock from 900 to 340 I get my old 534MH/s back. But before it worked with 900MHz.
|
|
|
|
|
|
gat3way (OP)
|
|
June 24, 2011, 03:38:52 PM |
|
Rather strange, thanks for reporting this. What GPUs are those?
|
|
|
|
|
burp
Member
Offline
Activity: 98
Merit: 10
|
|
June 24, 2011, 03:48:44 PM
Last edit: June 24, 2011, 07:55:40 PM by burp |
|
5830 GPUs.
I upgraded to 11.6 because it allows overclocking over the limits. I'm running them now at 975/380 MHz for 297MH/s each. Lowering mem-clock decreases hashing speed while increasing it further locks the cards up.
EDIT: Here some more interesting results:
With hashkill the highest hashrate I can achieve is with 950/380; this gives me about 290MH/s for each card. Going just slightly above that clockrate gives me many invalid results. Going lower with the memory clock immediately results in a slower hashrate.
With poclbm miner (phatk kernel) I get the best results with 975/300 @ 298MH/s for each card. Going higher with the memory clock changes nothing. (Just one miner per card, more give just negligable benefit)
It would be interesting to understand the reason for these results, as it must depend on how the opencl-kernel crunshes the hashes.
|
|
|
|
|
teukon
Legendary
Offline
Activity: 1246
Merit: 1002
|
|
June 25, 2011, 07:59:01 AM |
|
Hi,
I'm trying to mine solo using hashkill and am confused by the program output. After 30 mins on the bitcoin testnet I have.
Speed: 695 MHash/sec [proc: 477] [subm: 2] [stale: 272] [eff: 0%]
Can anyone explain the seemingly large number of stale shares?
This is for 2 5850s both clocked at 890/900 at temperatures of 87C and 81C respectively. The reported MHash/sec is holding steady.
Checking with bitcoind and the testnet block explorer I can confirm that the two 'subm' shares are the 2 generated blocks. The difficulty on the testnet is currently 45.50177646 and has been for the entire 30 mins and the bitcoin generation calculator gives an average of 6.4 blocks for every 30 mins. Perhaps I've just been a little unlucky and I'll continue to run this for another 30 mins.
|
|
|
|
|
|
kripz
|
|
June 25, 2011, 08:04:24 AM |
|
I think it's because with solo it's either wrong or right (and you get the 50btc).
|
|
|
|
teukon
Legendary
Offline
Activity: 1246
Merit: 1002
|
|
June 25, 2011, 08:31:49 AM |
|
I think it's because with solo it's either wrong or right (and you get the 50btc).
That explains the small number of 'subm'. I guess I'm just trying to understand what 'proc' and 'stale' are all about. Perhaps hashkill is sending difficulty 1 shares to bitcoind which rejects most of them or something. By the way, when I mine with a pool I get practically no stale shares. After another 30 mins I have: Speed: 695 MHash/sec [proc: 1022] [subm: 8] [stale: 581] [eff: 0%] So it seems like I was just a little unlucky in the first 30 mins. |
|
|
|
|
|
gat3way (OP)
|
|
June 25, 2011, 04:16:28 PM |
|
In that case, it's not "stale" but actually invalid. hashkill checks just if H == 0, not G against target. I guess the difficulty setting of the testnet is set low, that's why you were able to get "subm" anyway.
|
|
|
|
|
|
gat3way (OP)
|
|
June 27, 2011, 05:39:19 PM
Last edit: June 27, 2011, 06:24:08 PM by gat3way |
|
A new version available with some improvements.
* Optimization on Ma function of sha256 (+2-3% on 5xxx hardware up to +4-5% on 69xx hardware) - thanks to bitless
* Use SO_KEEPALIVE for long polling connection to avoid stales on some networks with shorter TCP timeouts - thanks to Gary13579
* Fixed minor cosmetic bugs.
* Better handling of "lost connection" cases - eliminated some races there.
For downloads please refer the first post on the thread.
|
|
|
|
|
|
gat3way (OP)
|
|
June 28, 2011, 07:44:51 PM |
|
There appeared to be problems on 69xx cards with the last version. Those are now fixed. Also added another optimization to the kernel, adding up to about 1% performance on my 6870. Please redownload.
|
|
|
|
|
|
Keninishna
|
|
June 29, 2011, 03:26:19 PM |
|
Holy moly this app is quality. It is fast! I'm getting about a constant 710 mh/s with my two 6950s. Easy to install and easy to use and stops the card if it overheats too. The only issue ive seen so far is that after a new block is found occasionally the second card does not run untill the next block? I would say this is better than any miner in windows.
|
|
|
|
|
|
AngelusWebDesign
|
|
June 29, 2011, 04:31:36 PM |
|
After running it for 5 minutes, one of my 3 cards "dropped out" so my hashrate went from 960 down to 560.
The other card didn't seen to come back, either.
Any idea why?
The cards aren't overheating or anything; they run fine with poclbm (and connected to the same pool, too)
|
|
|
|
|
|
gat3way (OP)
|
|
June 29, 2011, 05:31:18 PM |
|
I have no idea about the dropping cards (cannot reproduce it)  Will work on this. BTW I fixed the BFI_INT replacement code which allows me to optimize the 69xx code a LOT! For all 69xx users, please redownload. It should be much better now  |
|
|
|
|
Tartarus
Newbie
Offline
Activity: 47
Merit: 0
|
|
June 29, 2011, 05:47:26 PM |
|
I have no idea about the dropping cards (cannot reproduce it) Will work on this. BTW I fixed the BFI_INT replacement code which allows me to optimize the 69xx code a LOT! For all 69xx users, please redownload. It should be much better now FYI, I had to install libjson0 and libcurl3-nss this time (using LinuxCoin v0.2a) which I hadn't before. On my 6950 (GPU @ 840, Mem @ 720) I get 342MHash/s which is just a hair below what I get on non-efficient phoenix+phatk. |
|
|
|
|
|
gat3way (OP)
|
|
June 29, 2011, 06:02:55 PM
Last edit: June 29, 2011, 06:17:44 PM by gat3way |
|
Ops...this was not supposed to be like that. For some reason I have mistaken the cross-compile flags. OK, fixing that and rebuilding a static-linked one...
OK reuploaded it. Also added a small edit to the vliw4 code in the kernel. Could you retry please (and sorry for that)?
P.S do not use -G3 or -G4 anymore, it makes no sense anymore. Still -D would give you some more MH/s.
|
|
|
|
|
Tartarus
Newbie
Offline
Activity: 47
Merit: 0
|
|
June 29, 2011, 07:10:37 PM |
|
Ops...this was not supposed to be like that. For some reason I have mistaken the cross-compile flags. OK, fixing that and rebuilding a static-linked one...
OK reuploaded it. Also added a small edit to the vliw4 code in the kernel. Could you retry please (and sorry for that)?
P.S do not use -G3 or -G4 anymore, it makes no sense anymore. Still -D would give you some more MH/s.
Still need libjson0 installed and same speeds as before (should have said 64bit before, sorry). One thing I was wondering is what size is the worksize here? I think 'auto' ends up being 64 on my card+2.4 SDK but manually setting to 128 in the other miners gives a noticeable speedup. EDIT: Bah, user error. |
|
|
|
|
|
gat3way (OP)
|
|
June 29, 2011, 07:28:07 PM |
|
No, there is no way to set it, it's hardcoded in the kernel so that the compiler makes better assumptions with register allocation. For most cases, 64 should be best though given the kernel parameters.
|
|
|
|
|
Tartarus
Newbie
Offline
Activity: 47
Merit: 0
|
|
June 29, 2011, 07:52:45 PM |
|
No, there is no way to set it, it's hardcoded in the kernel so that the compiler makes better assumptions with register allocation. For most cases, 64 should be best though given the kernel parameters.
reqd_work_group_size is the variable, yes? If so, OK, I'm not seeing any change here bumping that up here, so thanks for explaining why you do what you do |
|
|
|
|
|
gat3way (OP)
|
|
June 29, 2011, 08:28:10 PM |
|
Basically it is also limited in the host code to 64. Anyway I can build you a 128 version, all you need to do is change that in the kernel of course.
|
|
|
|
|
|
Keninishna
|
|
June 30, 2011, 03:43:31 AM |
|
I have no idea about the dropping cards (cannot reproduce it) Will work on this. BTW I fixed the BFI_INT replacement code which allows me to optimize the 69xx code a LOT! For all 69xx users, please redownload. It should be much better now woot! will try tomorrow. I'm sure there is a way to poll the video cards to see if they are working after a new block, which would fix the dropping card issue. I can post a screenshoot tomorrow as well. If there is any debug info I can give you let me know. |
|
|
|
|
|
