I've noticed in reaper, if you tell it to run 5 threads it says it starting 10! Don't know if that has anything to do with it??
There's definitely not enough resources at 10240 gap 2 to run 5 actual threads on a 7970, and since the values don't line up with raper, who knows what it's doing, so long as we get good performance... I've lost interest at looking at the raper code itself since I got the kernel working well. |
|
|
|
|
Yeah I'm not really sure why I can use 10240 on raper and not on this since they're structurally virtually the same kernels.
|
|
|
|
|
I don't get an increase in rejects with 4 threads, and I let it choose the default worksize for 7970 which is 64, not 256.
|
|
|
|
|
Yes this definitely needs sdk2.6+
EDIT: and make sure you delete any .bins already generated with older SDKs if you upgrade.
|
|
|
|
|
Found a sweet spot with my 7970s. Memory 1375 Engine 1135. Increasing engine slows it down beyond that. There is definitely a relationship between engine and memory clock, scrypt settings and even motherboard speed. Assuming higher is better is not going to necessarily be true.
|
|
|
|
I found some REALLY interesting results with my 6850 and my 5770! 6850: https://i.imgur.com/fZgEk.png5770: https://i.imgur.com/ti0Cr.pngSo, the memory clock on the 6850 had no effect on my hashrate (at least at those high settings)! I set it down to 500 and the hashrate didn't change. Now I wasn't paying attention to the share count, but it seemed to be sending as much as it should be. Overclocking the memory of a 6850 reduces hashrate. Likes worksize 128. The 5770 isn't like that. Higher memory doesn't change hashrate, but lower memory clock lowers it. Two threads pulled an extra few kh/s. A concurrency of somewhere in 3000s is what your looking for, for the 5770. Likes worksize 256. I'll do more testing later, but I'm happy with my results. This is amazing, great work ckolivas. And it seems stable already. Thanks  I'm pretty sure we'll need to create a database with suitable values. Every card seems to want something completely different. My 7970s really need all 1375MHz of memory or hashrate drops off. Ironically they seem to do the opposite with engine clock - there's a ceiling to how high the hashrate gets and then turning the engine up further doesn't speed things up any more. |
|
|
|
ckolivas, could you also set a user-definable parameter to adjust the difficulty needed for submitting a share?
Instead of reading off the difficulty from the pool? I guess so... but not right now. Oh, sorry, I didn't realize that each pool sends its difficulty requirement to the miner. Just when I was mining with P2Pool (Bitcoin), it would send difficulty 1 shares to my local P2Pool node even though the P2Pool share difficulty is much higher. Yes cgminer supports higher difficulty shares, which is why I've been trying to get BTC pools to start supporting it with all this faster hardware coming around. Ironically with LTC being much easier to mine difficulty 1 shares, the LTC pools needed to support higher difficulty shares first. P2pool however doesn't actually ask cgminer for higher difficulty shares, it asks for difficulty 1 shares and then internally decides if it's a "true share" based on the target difficulty it meets. It works either way, but cgminer uses less CPU so it makes much more sense to allow the mining software to do the testing. In the scrypt version of cgminer, it actually does the target difficulty even on the GPU for anything less than 4,294,967,295 where difficulty 1 shares on litecoin are only 65,535. |
|
|
|
with the new, i have set the -I to 16, and i get 210, with almost 0 stales, reaper could get 210 MAX, with 10% stales, this is soo goood!
Yup, increase in intensity certainly helped. Now at 338 at 16 and 340 at 17. At 18, kh/s jumps around a lot. Time is averaged over 5 seconds, and at those high intensities the threads wont report in for over 5 seconds potentially so you'll get serious aliasing artefacts. |
|
|
|
Hey all,
I been running cgminer for a while now with no problems (4 GPU and 2 BFL). I just got another 4 BLF and I am now getting a weird problem. The BFL that cgminer labels as BFL 0 show crazy high hash rates (I wish 13000 M/s) but is actually not doing any work (U=0). See photo
-I've verified all the BLFs work independently on another system.
-It does matter which unit is at the cgminer position BLF0 but that is the spot that always acts up.
Any ideas
Thanks
Nanook
Try specifying bitforce: before the port like "bitforce:\\.\COM5" |
|
|
|
ckolivas, could you also set a user-definable parameter to adjust the difficulty needed for submitting a share?
Instead of reading off the difficulty from the pool? I guess so... but not right now. |
|
|
|
And ckolivas, usually the drop in intensity is more detrimental than change in threads. It's why I was curious.
There's a tipping point and it's very much dependent on hardware. What works on one gpu/sdk/driver combo may be meaningless on another. I fought with it for a while to find the sweet spot for my 7970s with my drivers... |
|
|
|
worksize 256: ~180 kh/s
worksize 128: ~190 kh/s
worksize 64: ~192.5 kh/s
Yea, I changed my post. How many threads is that? Still the 6144? yes, using 6144, cant find something that do better then that on my cards How many stales are you getting with that though? Whenever I use 6144, I get about 10% stales. If the rejects start to shoot up, dropping intensity by 1 usually cures it. Of course the hashrate drops but you'll probably end up submitting more valid shares. The whole relationship between the different variables, the different hardware, and the drivers seems quite a mess... |
|
|
|
|
Okay I updated the git tree to allow intensities up to 20. Bad idea on 7970, perhaps it's quite ok on 5/6xxx.
|
|
|
|
|
Right, well underlined... Memory speed affects hashrate a lot with ltc mining. I ran memory at default speeds which meant I also had to turn my gpu engine overclock speeds down slightly to not crash.
|
|
|
|
|
Oh yes and driver 12.6 worked the least worst on my 7970s, though it was truly easy to crash with the wrong settings so I rebooted literally dozens of times...
|
|
|
|
If other cards like intensity 14, then I should change the scale.
In Reaper, 7970s would ONLY run well using 13 Intensity, whereas 5/6xxx cards benefited from up to 19 for dedicated rigs and saw huge performance increases at higher intensities..... <EDIT> Reaper Aggression = CGMiner Intensity ? They're equivalent at the moment, but 14 is the max allowed in the code. If you want to bump it up, edit miner.h and look for: #define MAX_INTENSITY 14 #define _MAX_INTENSITY_STR "14" and change those 14s to 20 or something. |
|
|
|
My hash rates look good...but is Solo Mining broken by chance ? .........either that, or my luck just took a huge turn for the worst, especially considering the hashing capabilities I have at the moment...lol
<EDIT>
..and of course, as soon as I return back to my miners after posting this, I get a block...LOL
Everything looks good over here.
What I have noticed:
- 5/6xxx Cards like -I 14
- 7970 does not like Intensity over 13.
- 4096 and LESS (by either 512 or 1024 increments) as low as 2048 seem to work well for anything from a 5770 to a 6950.
Anything *might* be broken still at this early stage. You tell me how often you'd get a block and whether it's about right or not. If other cards like intensity 14, then I should change the scale. |
|
|
|
|
BTW don't try to use this git tree code for regular bitcoin mining as it's likely broken for now.
|
|
|
|
excuse the solidcoin icon too thats from way back  one question do you have share threads 18 default i know thats what i have in reaper im not a programer so was just wondering Share threads have nothing to do with cgminer's functioning. |
|
|
|
|
I'm not taking any "bug reports", only what works. Try lower threads for higher concurrencies and vice versa and so on. All combinations that worked on raper consider irrelevant on this code.
|
|
|
|
|
Show Posts
