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

New release: 2.11.3, 17th March 2013

Building further on the stability of 2.11 with more bugfixes, and the first significant scrypt update in some time thanks to a surge in its popularity and virtually the first ever donations towards developing and maintaining it since it was first added to cgminer.


Human readable changelog:

- Updated USB detection code by Kano will now show known devices with cgminer -n, and you can manually select devices to mine with using the new --usb option - read the README for full documentation! (Yeah right, no one reads documentation  )
- Fixes for certain USB communication problems should make them more reliable.
- Workaround for the rare crash on switching pools with stratum with older libcurl builds.
- Adding a pool now from the menu will return quickly while it leaves probing it to the background.
- Internal improvements in scalability in preparation for ASIC devices (must be close now? )
- Changes to the hashmeter to update it more frequently - for fast devices it will update smoother but for long-return devices (like slow FPGAs) it will look worse. This is in preparation for faster devices...
- Scrypt updates:
 Fixed the failure to create high thread concurrencies.
 Intensities above 13 will not lead to garbage being generated on GCN (7xxx) hardware now.
 Decreased default GPU threads to 1. Intensities above 13 cannot handle more.
 Changed the default choice of thread concurrency if no options are passed to cgminer as a hint, based on amount of available GPU ram.
 Scrypt mining now shows the Work Utility as BTC mining does (total amount of diff 1 work done per minute).
 Extensive updates to the SCRYPT-README file in line with changes to the code and new information (but no one reads documentation anyway )


Full changelog:

- Update the hashmeter at most 5 times per second.
- Usbutils use its own internal read buffer
- Calculate work utility for devices that support target diffs of greater than
1, and update scrypt code to use it.
- usbutils allow read termination match to be a string
- Set default GPU threads to 1 for scrypt.
- Connect backup stratum pools if the primary pool cannot deliver work.
- Use a new algorithm for choosing a thread concurrency when none or no shader
value is specified for scrypt.
- Do not round up the bufsize to the maximum allocable with scrypt.
- Remove the rounding-up of the scrypt padbuffer which was not effectual and
counter-productive on devices with lots of ram, limiting thread concurrencies
and intensities.
- bufsize is an unsigned integer, make it so for debug.
- Update the hashmeter once per second but only display the extra logs every
opt_log_inteval.
- add a dummy ztex to usbutils so cgminer -n lists ztex also
- nDevs required for -n with usb
- USB device list - convert some common error numbers to messages
- USB -n 'known' text only without ---usb-list-all
- USB modify -n and --usb-dump to only show known devices or use new
--usb-list-all option to see all
- Make pool adding while running asynchronous, using the pool test thread
functionality.
- Only curl easy cleanup a stratum curl if it exists.
- Sacrifice the ram of curl handles in stratum disconnects when we have built
with old libcurl to avoid crashes.
- cgminer -n to include a USB device list
- usbutils allow call of usb_all() from other code
- Convert gbt_lock to a cg_lock.
- Add intermediate variants of cglocks that can be up or downgraded to read or
write locks and use them for stratum work generation.
- Move the stratum and GBT data to be protected under a new cg_lock data_lock.
- Convert the ch_lock to cg_lock.
- Convert the control_lock to a cg_lock.
- Remove unused qd_lock.
- Implement cg_lock write biased rwlocks.
- do usb_initialise() after the started message so we see it
- --usb-dump display brief dump if value = 0
- USB add --usb options to limit USB device selection v0.1

Current development code only which you can get if you're building from git, but there's a sample executable linked a few posts back for windows. Next version 2.11.3 will have a few scrypt improvements.

I did find and fix a race condition in the stratum code going to cgminer 2.11.2.

Pretty sure with the right driver and SDK combo there should be no difference between the  OSes. However win7 does offer some extra options for overclocking/undervolting that many find advantageous for mining, and apart from OS stability, there is no mining performance advantage to linux. It's up to you.

Driver and SDK versions matter but in a different way to those for bitcoin mining. There is no reason you can't ltc mine the same on linux for 5xxx with the right driver/sdk combo. I'd recommend AMD driver 12.8 with SDK 2.7 for litecoin mining.

The first is not required on windows (it's on by default anyway). The second decreases CPU usage, so if you have that problem on windows, the only way to improve on it is use linux.

That may be, but without source code available, unlike all other mining software, one will be far more suspicious.