#define CL_OUT_OF_HOST_MEMORY                       -6

Looks like you're overloading the memory bandwidth for that hashrate.

Intensity is the amount of work in one go the GPU has to do before it can return its results. It needs to be large enough to keep the device fully utilised yet not so overloaded that the device becomes unresponsive. The faster the GPU, the higher the sweet spot is. Ram is of no use to mining whatsoever. They could even mine fine with only a few MB of ram.

2.1 sdk does NOT work with the newer 12.x drivers at all. They are simply incompatible I'm afraid.

Try running it in text mode only to see if you're one of the unlucky ones getting bitten by the windows version of the text interface that crashes (i.e., start it with the -T parameter).

Calm down guys, for fuck's sake it's not like he's a botnet operator asking for help (which has happened).

If you change driver/sdk combo and wish cgminer to use the new combination for its performance, you must delete any .bin files generated by cgminer first, or extract the cgminer archive afresh (for the same effect).

Hoppable prop pools will not be wanting to give out that much information... of course that's their problem.

I ran 6970s fine with 7970s, albeit on linux.

32 bits? Only 4 devices will work on 32 bit operating systems. If not, then increase your PCI latency to 64 or something like that I've heard it said...

This really doesn't have much to do with p2pool as p2pool is impossible to use as anything other than the primary pool, or a backup pool in pure failover-only mode. Using p2pool in load balance with it as anything other than the primary would be a mess for shares going to p2pool.

That's a good idea as rotate is much more robust since it has a firm concept about which pool is the primary.

No. Hash rate reported by your pool is your hashrate*luck for that period and can and will fluctuate wildly.

As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain 

By the way, windows virus software must have reached an all time new record for false positives. When I was compiling the 2.4.2 version for release on a windows xp virtual machine, microsoft security essentials detected the cgminer executable as a potential threat as soon as it was created. Of course I just told MSE to ignore it, but that was impressive...

Yes I already said that the best way of working with many devices is to just use cgminer as a backend and work through the API using a different front end, which is why I see no point killing myself over the limited text interface. There are already quite a few front ends that do that, even on windows.

A most enlightened response. Thanks. All I can do is try my best within reasonable effort.

I don't disagree, but the problem is it does different things on different operating systems and different shells. Working with curses is painful on a scale that almost puts it on par with working with Luke-jr as it never does something predictable or logical. I fixed stuff after that old cgminer and yeah it broke other stuff. It's an endless tirade of one piece of shit after another and I'm sick of fighting with it, like Luke-jr.

Thanks! Donations rock!

Repackaged the source as 2.4.2-1 because 2 of the READMEs were missing. Binary packages are unchanged.

This multi device display issue is because it gets corrupt at 14 devices with the old code. The curses display was never designed with people throwing so many devices at it and I never anticipated people would do it. Then I made it stop showing all the devices if there were over 8 - and people complained bitterly, so I made it scale to draw as many devices as you can fit. However pdcurses isnt as smart as ncurses which is used on linux so it just decides to crash instead of display them. SOOOOOOooooo what we're left with is yet another moronic scenario where the choice is either don't display devices and don't crash, or do something to your window before it runs to display them all and not crash, or it will crash. Solution? If you are using LOTS of devices - don't run cgminer with the display enabled by using -T and use a monitoring app to manage that many devices. The basic display was not designed with bucketloads of devices in mind.

Summary: Fuck you windows.