I have a question and potentially a future feature to implement (maybe !)

I have a scrypt question. I have a rig with very bastardly cards, 6970, 7970, 5970 and 5870. I can get everything working fine -but- ! 7970 works best in scrypt with -g 2, but when I turn it on it makes my ATI driver crash, I reboot, etc, sometimes PC after reboot goes nuts, safe mode, reboot again. If I run -g 1 all works well but 7970 isn't mining as optimal as it should (175KH less than optimal super hashing speed).

I tried the -d option, but cgminer still compiles a scrypt*.bin for the scrypt setting and doesn't run properly. If let's say I run --gpu-fan at like 55, it sets 55 on ALL cards, even if I only tell it to mine from -d 1. I was thinking of running one instance of cgminer on 7970 card with -g 2, then another instance with -g 1, but I don't seem to be able.

Is there any reason i can't use a thread concurrency of 1600? My gpu posts 720kh/s with it but all as errors. as soon as i use 8192 it only posts 550ish max. Perhaps this is why ghz card perform so badly?

I have a Bitcoin machine running W8 Pro, Radeon 7850 + 7970 and CGminer 2.11.4I am looking for finer tuning suggestions, and wanted your thoughts as to what you think I may have overlooked or should consider trying. Of the configs I've tried the following seems to run the best, but I'm sure there are more refinements I've not tried, including worksize.

cgminer 3.1.0, I have found blocks with best share > diff & the pool has confirmed my share. but the counter of found blocks stayed 0. it may introduced in around 2.11.4 with your new block checking logic? (I'm running inside openwrt)

Is there any downside to running cgminer as root? I'm getting ready for when my Jalapeno arrives and I can't find the 01-cgminer.rules file anywhere. Ah, I just found it. Still, running as root is much easier.

I'm trying to solo-mine FTC (scrypt, 2.5 min/block) with GPUs. From what I can found, the usual recommended practice is to add stratum or longpoll pools to the list of pools, so cgminer will know when there is a new block.

However, from my own experiment, I found that existing FTC pools are slow to send out new block notifications. The following is a screenshot of cgminer running on 2 different machines.

Using "--scan-time 1" with a local feathercoind gives me new blocks detections 0-30 seconds faster than the stratum/longpoll connections (as seen above).

However, the statistics for the machine on the right show 60 new blocks (NB), 177 discarded work items (DW), and 1 rejected block (R). Having "DW > NB" and "R > 0" makes me feel that it might I may be doing something wrong. Naively I think that cgminer discards work only when a new block forces it to do so.

and it just sits there indefinitely. tried a few different .conf settings, and get ther same. without a .conf and specifying url and such, it crashes a few seconds after hitting return after entering password.

Con, can you address the best way to determine settings for scantime & expiry when mining the latest scrypt coins? Do you lower them to try to equal the block frequency? Like chinacoins were every second and mincoins are every minute, so it seems like leaving at default is a bad idea...

Con, can you address the best way to determine settings for scantime & expiry when mining the latest scrypt coins? Do you lower them to try to equal the block frequency? Like chinacoins were every second and mincoins are every minute, so it seems like leaving at default is a bad idea...

That's like going back to how we mined bitcoins >2 years ago before pools and longpoll. The answer is set the scantime as low as you can before the hashrate drops. If you're solo mining, something like 5s is usual for sha coins. However it can be slow to return results for scrypt so you'll have to experiment.

Its like priority in the windows task manager, it sets how important the hashing is to the GPU. 'd' setting is good for computers being used while mining, while most dedicated mining cards see performance benefits in the 9-15 intensity range, from what I've seen.

GPU-README (yeah another of the files people don't read)INTENSITY INFORMATION:

Intensity correlates with the size of work being submitted at any one time toa GPU. The higher the number the larger the size of work. Generally speakingfinding an optimal value rather than the highest value is the correct approachas hash rate rises up to a point with higher intensities but above that, thedevice may be very slow to return responses, or produce errors.

NOTE: Running BTC intensities above 9 with current hardware is likely to onlydiminish return performance even if the hash rate might appear better. A goodstarting baseline intensity to try on dedicated miners is 9. 11 is the upperlimit for intensity while BTC mining, if the GPU_USE_SYNC_OBJECTS variableis set (see FAQ). The upper limit for sha256 mining is 14 and 20 for scrypt.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!