Gotta be some synchronization bug, I will have a look at that...
Topic: hashkill - testing bitcoin miner plugin - page 4. (Read 90911 times)
Yeah and I can clearly see that "GPU drop" effect
Gotta be some synchronization bug, I will have a look at that...
Gotta be some synchronization bug, I will have a look at that...
Here is my output:
Adding the -D option gave me about 5 mh/s extra
Adding the -D option gave me about 5 mh/s extra
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
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.
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.
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
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.
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.
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.
EDIT: Bah, user error.
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.
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.
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
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.
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
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
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)
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)
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.
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.
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.
* 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.
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.
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.
I think it's because with solo it's either wrong or right (and you get the 50btc).
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.
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.
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.
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.
Rather strange, thanks for reporting this. What GPUs are those?
Jump to: