Considering none of the opencl, GPU or kernel code was changed between 2.3.6 and 2.4.0, I find that a little more than a little unlikely.

LOL, you may be the first person to estimate even less than I would have.

Wrong, you should downgrade your driver and read the FAQ.

That's the code being polite... you should see what it would have done before.

The previous code definitely was not polite and had a "take no prisoners" approach so it would bombard by default for the miner's benefit and if anything went wrong at the pool end, the pool would get hammered.

I've spent a busload of time making cgminer be nice to pools and, more so, services like gpumax, so hopefully cgminer users and gpumax alike will find a much better experience upgrading to 2.4.0:

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

Hopefully the pool itself should also notice a significant decrease in load as people migrate to this version.

I definitely had services like yours in mind when I developed it, so I hope not   

NEW VERSION: 2.4.0 - May 3, 2012

This version has a fairly significant upgrade to the way networking is done, so there is a minor version number update instead of a micro version, but it has already been heavily tested.

Human readable changelog:
A whole networking scheduler of sorts was written for this version, designed to scale to any sized workload with the fastest networking possible, while minimising the number of connections in use, reusing them as much as possible.
The restart feature was added to the API to restart cgminer remotely.
If you're connected to a pool that starts rejecting every single share, cgminer will now automatically disable it unless you add the --no-pool-disable option.
Once a pool stops responding, cgminer won't keep trying to open a flood of extra connections.
Failing BFL won't cause cgminer to stop; it'll just disable the device, which an attempt may be made to re-enable it.
Hashrates on FPGAs may be more accurate (though still not ideal).
Longpoll messages won't keep going indefinitely while a pool is down.

Full changelog:
- Only show longpoll warning once when it has failed.
- Convert hashes to an unsigned long long as well.
- Detect pools that have issues represented by endless rejected shares and
disable them, with a parameter to optionally disable this feature.
- Bugfix: Use a 64-bit type for hashes_done (miner_thread) since it can overflow
32-bit on some FPGAs
- Implement an older header fix for a label existing before the pthread_cleanup
macro.
- Limit the number of curls we recruit on communication failures and with
delaynet enabled to 5 by maintaining a per-pool curl count, and using a pthread
conditional that wakes up when one is returned to the ring buffer.
- Generalise add_pool() functions since they're repeated in add_pool_details.
- Bugfix: Return failure, rather than quit, if BFwrite fails
- Disable failing devices such that the user can attempt to re-enable them
- Bugfix: thread_shutdown shouldn't try to free the device, since it's needed
afterward
- API bool's and 1TBS fixes
- Icarus - minimise code delays and name timer variables
- api.c V1.9 add 'restart' + redesign 'quit' so thread exits cleanly
- api.c bug - remove extra ']'s in notify command
- Increase pool watch interval to 30 seconds.
- Reap curls that are unused for over a minute. This allows connections to be
closed, thereby allowing the number of curl handles to always be the minimum
necessary to not delay networking.
- Use the ringbuffer of curls from the same pool for submit as well as getwork
threads. Since the curl handles were already connected to the same pool and are
immediately available, share submission will not be delayed by getworks.
- Implement a scaleable networking framework designed to cope with any sized
network requirements, yet minimise the number of connections being reopened. Do
this by create a ring buffer linked list of curl handles to be used by getwork,
recruiting extra handles when none is immediately available.
- There is no need for the submit and getwork curls to be tied to the pool
struct.
- Do not recruit extra connection threads if there have been connection errors
to the pool in question.
- We should not retry submitting shares indefinitely or we may end up with a
huge backlog during network outages, so discard stale shares if we failed to
submit them and they've become stale in the interim.

Thanks for the feedback. This update has been significant enough to release a new version so I'm planning on releasing 2.4.0 soon.

It's almost certainly the opposite. Major super miners care about profits, and profits are at their lowest on a hoppable prop pool with 3% fees or non-hoppable but heart-stopping PPS 10% fee. If anything's keeping people at deepbit, it's inertia, perceived advantage of mining with the biggest, language issues, and botnets. I work in concert with some of the biggest miners that use cgminer when developing it, and none of them use deepbit except as a backup pool.

127 is a "bug" value. It means the driver has crashed and is reporting nonsense. It does not actually mean the temperature is 127.

Massive update to git tree:

I've basically implemented a kind of "network scheduler" into cgminer. It is designed to increase the number of connections to cope with virtually any sized hashing (see the 91 device example above with 33GH on one machine), yet minimise the amount of open connections used at any time, and reuse connections as much as possible.

This is the relevant part of the changelog (reverse order), though there are other commits to the master branch as well:
Limit the number of curls we recruit on communication failures and with delaynet enabled to 5 by maintaining a per-pool curl count, and using a pthread conditional that wakes up when one is returned to the ring buffer.
Reap curls that are unused for over a minute. This allows connections to be closed, thereby allowing the number of curl handles to always be the minimum necessary to not delay networking.
Use the ringbuffer of curls from the same pool for submit as well as getwork threads. Since the curl handles were already connected to the same pool and are immediately available, share submission will not be delayed by getworks.
Implement a scaleable networking framework designed to cope with any sized network requirements, yet minimise the number of connections being reopened. Do this by create a ring buffer linked list of curl handles to be used by getwork, recruiting extra handles when none is immediately available.

That's very interesting and likely an issue with the difference between headers and implementation of pthread_cleanup_pop in that distribution/gcc and all the more modern ones we're compiling on. The reason is that the pthread_cleanup_* functions are implemented as macros so you can't see just why this is an issue unless you spit out the pre-processor output. Either way it should be easy to implement something like that as a fix, thanks.

One of the reasons I limited a previous version to only displaying 8 devices.  Sigh. The interface was never designed with so many devices in mind and with that many you should really be using a different front end via the API instead.

As per the readme... delete the .bin files when you change SDKs if you want the new SDK to "take".

I guess reading a value off is not likely to cause a problem, whereas updating it concurrently would. There is no locking around calls to ADL since it just hooks into the functions directly in the driver.

No point setting up pool software for this. If you use cgminer, set your primary pool to your local bitcoind, and then set just about any other actual pool as your backup, it will use the longpoll from the backup pools to help out your bitcoind.

Try: cgminer -n

Should report any SDKs installed and any OpenCL compatible GPUs detected. Presumably the GPUs need drivers that advertise their OpenCL capability.

If it's opencl then they should already work. Performance, on the other hand, is likely to be shit. Not because of my opencl code, but because they are pissweak.