And not enough power.

More of the same will happen.

Just let it go ffs 

Correct.

I still don't think we have an answer but more anecdotes to support the practice encouraged by my cgminer code based on my opinion. I had 4 7970s that ran at 100% load 24/7 for 12-14 months with variable fanspeed up to 85% to maintain temperatures constantly targetting 72-75 (as per the cgminer defaults when --auto-fan is enabled). The GPUs did not have a single problem and most have since been sold for a nice return.

No dotNet in the posix c code that is cgminer.

I'm guessing you're talking about windows. Windows does random things with the logging output it seems. Gotta love its (arse)soul.

win32 builds work on win64. However 2.11.3 is the latest stable release now and that's in the top cgminer directory.

Thanks it's a labour of love (and anger and hatred and frustration and trolling and headache and heartache and pain at times).

You sir have instantly promoted yourself to my friend with that comment See if you can find the link to the game translation project and the association shall then be clear.
(Post intentionally left obscure to those not in the know )

For windows users who can't set high thread concurrencies with the latest cgminer, use this in your batch file first before starting cgminer:

p2pool stratum for ltc uses difficulty based on btc difficulty. Unfortunately the defacto standard as used by many pools using ltc stratum now set difficulty according to the base ltc difficulty (65536 times larger) meaning p2pool is at odds with what everyone else is doing and thus is asking for way too low difficulties making cgminer submit shares of much lower difficulty than p2pool is expecting. As there is a precedent with other pools setting the defacto standard prior to p2pool, unfortunately the onus is on p2pool to come in line with the rest.

For scrypt mining on windows with high thread concurrencies, see "How to raise "Maximum buffer memory" in cgminer 2.11.3 ":

http://forum.litecoin.net/index.php/topic,1420.0.html

Summary:

I have received some further donations for scrypt, so I will briefly outline how to get the best hashrate for a 7970 as I understand it, that should work for any hardware combo.

EDIT: Preliminary actions:
On linux run this command:
export GPU_MAX_ALLOC_PERCENT=100
or on windows this:
setx GPU_MAX_ALLOC_PERCENT 100
in the same console/bash/dos prompt/bat file/whatever you want to call it,
before running cgminer.

First, find the highest thread concurrency that you can start it at. They should all start at 8192 but some will go up to 3 times that. Don't go too high on the intensity while testing and don't change gpu threads. If you cannot go above 8192, don't fret as you can still get a high hashrate.

Delete any .bin files so you're starting from scratch and see what bins get generated.

First try without any thread concurrency or even shaders, as cgminer will try to find an optimal value
cgminer -I 13

If that starts mining, see what bin was generated, it is likely the largest meaningful TC you can set.
Starting it on mine I get:
scrypt130302Tahitiglg2tc22392w64l8.bin

See tc22392 that's telling you what thread concurrency it was. It should start without TC parameters, but you never know. So if it doesn't, start with --thread-concurrency 8192 and add 2048 to it at a time till you find the highest value it will start successfully at.

Then start overclocking the eyeballs off your memory, as 7970s are exquisitely sensitive to memory speed and amazingly overclockable but please make sure it keeps adequately cooled with --auto-fan! Do it while it's running from the GPU menu. Go up by 25 at a time every 30 seconds or so until your GPU crashes. Then reboot and start it 25 lower as a rough start. Mine runs stable at 1900 memory without overvolting. Overvolting is the only thing that can actually damage your GPU so I wouldn't recommend it at all.

Then once you find the maximum memory clock speed, you need to find the sweet spot engine clock speed that matches it. It's a fine line where one more MHz will make the hashrate drop by 20%. It's somewhere in the .57 - 0.6 ratio range. Start your engine clock speed at half your memory clock speed and then increase it by 5 at a time. The hashrate should climb a little each rise in engine speed and then suddenly drop above a certain value. Decrease it by 1 then until you find it climbs dramatically. If your engine clock speed cannot get that high without crashing the GPU, you will have to use a lower memclock.

Then, and only then, bother trying to increase intensity further.

My final settings were:
--gpu-engine 1157  --gpu-memclock 1900 -I 20
for a hashrate of 725kH.

Note I did not bother setting a thread concurrency. Once you have the magic endpoint, look at what tc was chosen by the bin file generated and then hard code that in next time (eg --thread-concurrency 22336) as slight changes in thread concurrency will happen every time if you don't specify one, and the tc to clock ratios are critical!

Good luck, and if this doesn't work for you, well same old magic discussion applies, I cannot debug every hardware combo out there.

Your numbers will be your numbers depending on your hardware combination and OS, so don't expect to get exactly the same results!

Read the scrypt readme as well as the main readme since you're not mining bitcoin.

I'd love to say I'll make it 100 times faster but realistically no, just that I'll maintain support for it and keep the code in line with btc mining and fix any unique scrypt bugs instead of letting it rot in hell which is what I'm tempted to do. It's no secret I find the scrypt code annoying and difficult to support because of its non-deterministic behaviour. I'm not against alternative cryptocurrencies or LTC per se, it's just that I primarily care about BTC. There already have been very big scrypt updates behind the scenes in cgminer the last 6 months and no one gave a rat's arse till they abandoned GPU mining on BTC. As I've said elsewhere, I got a big donation to add scrypt support to cgminer originally, and then in the 6 months since then got a sum total of 3.6LTC in donations until a week ago. I'm only giving it some foreground attention now because of the recent donations. The fact is I have to hold onto a GPU to even try and keep support for it when I was planning on selling all of them (I've sold 3 of my 4 GPUs).  Yes, I can be "paid to care", I admit it. Keep the donations coming and I'll even stop complaining about it (as much)  

See this litecoin thread for a failed attempt to start a "bounty" as such.
http://forum.litecoin.net/index.php?topic=1389

GPU monitoring requires  constant same-user access to the values. This is a known OS limitation and there is no workaround if you are switching users.

And so my master plan to make scrypt even harder to mine with and eventually kill off litecoin starts coming to fruition

So you can see why I had avoided touching the scrypt code due to lack of interest +/- donations till now for it is witchcraft and one minor change angers the hashing gods and they expect new sacrifices but reward those  who do the correct sacrifice even more than the old faithful.

Start low. Go slowly up. Do not increase -g count. Do not assume what worked on mine will work on yours. Read the scrypt readme. No two systems are alike.

--gpu-engine 1135 --gpu-memclock 1890 --thread-concurrency 22392 -I 20

Was worth 715kH, but it also drew 305W from the one GPU and was on my machine with my hardware running my OS.

I am NOT going to say this again. Everyone experiment for yourselves. Scrypt tuning is witchcraft and you need to find the right incantation for your device and sacrifice the correct number of goats while facing towards your holy centre.

Me? After upgrading the scrypt code, I'm back to mining bitcoin like I always have been.

Don't suppose you tried the larger thread concurrencies... everything needs retuning.

The new version of cgminer, 2.11.3, with the scrypt updates is out:

https://bitcointalk.org/index.php?topic=28402.msg1633258#msg1633258

Don't forget it was donations that made me improve it