I haven't decided yet because this is not a sign of BFL supporting the community, the developer or the clients. Of course taking a stand when BFL are guaranteed of sales monopoly and cornering the market will just make me look like I'm taking a stance when no one gives a shit, but then, I'm not sure what I get out of doing the hard work for them.

Thanks 

You need to differentiate target temp from overheat from cutoff temps. cgminer has a graded response depending on which of the 3 it is reaching, and you have to remember there is the hysteresis (3 default). So if you use the first of your numbers, and get rid of the overheat value, but enable autogpu, then it will start throttling the engine speed when it gets to about 78 degrees. ie you probably want:
--gpu-fan 30 --gpu-engine 600-1100 --auto-gpu
and that will keep the fan at static 30%, start the engine at 1100 and then if the temperature gets to 78 will start decreasing the engine speed. If 78 is too high, you can set the --temp-target to something besides 75.

There's certainly nothing private about the #cgminer logs as far as I'm concerned, otherwise it wouldn't be an open public channel.

Others are using this binary without any problems and I can't think of anything that would do this. I suggest you delete any .bin files you have and start again, or just extract it fresh and start again, doing the windows three finger salute (reboot) first.

If you use my precompiled binary you need opencl.dll. If you build it yourself it will require whatever you build it for.

Odd, disables here:

Intensity: Dynamic (only one thread in use)
Thread 0: 190.1 Mh/s Enabled ALIVE
Thread 1: 0.0 Mh/s Enabled ALIVE paused

Performance should be pretty much dependent on intensity so it will be very different to before since it appears you're going up to intensity 4 where previously it would have been stuck at 0 +/- 1.

In the meantime you can upgrade to cgminer 2.4.4 which I just released which should support massive hashrates anyway with a dramatic rise in efficiency. The faster the device, the higher the efficiency.

New version - 2.4.4, 1st July 2012

I plugged my main PC's hard drive into an external USB reader to allow me to build this on my laptop since I really wanted this release out.

Human readable changelog:
Massive overhaul of the nrolltime mechanism now should cause a huge rise in efficiency on pools that support it. This allows much lower getwork bandwidth for much higher hashrates.
Support for the expire= feature. This works in concert with nrolltime when pools support it to allow more local generation of work.
Support for the x-mining-hashrate feature. I'm sure some pool somewhere cares about this, even though I'm not convinced, but it was trivial to add.
Better damping of GPU temperature changes should cause much less overshoot when temps rise or fall outside the optimal range in autofan mode.
Reinstated the application restart should adl fail - disabling this did not fix the crashes for those who had cgminer crash after 1 week of uptime in windows fail land when their ATI driver would fail, and disabled the advantage of it fixing the problem for those who simply lost their fanspeed.
API groups features - this is squarely aimed at grouping privileges for remote access for services like P4man's hopping puppetmaster service.
Support for unlimited devices
Support for unlimited pools
Massive fix for the "dynamic" feature for GPUs. Somehow in the many device abstractions it had gotten broken and wasn't really doing what it was intended. It should be much more dynamic now.
FPGA fixes.
Fixes for builds on other platforms.
Lots of other things under the hood.


Full changelog
- Fix builds on non gnu platforms.
- api.c ensure old mode is always available when not using --api-groups + quit()
on param errors
- Implement rudimentary X-Mining-Hashrate support.
- Detect large swings in temperature when below the target temperature range and
change fan by amounts dependant on the value of tdiff.
- Adjust the fanspeed by the magnitude of the temperature difference when in the
optimal range.
- Revert "Restarting cgminer from within after ADL has been corrupted only leads
to a crash. Display a warning only and disable fanspeed monitoring."
- api.c fix json already closed
- implement and document API option --api-groups
- Put upper bounds to under 2 hours that work can be rolled into the future for
bitcoind will deem it invalid beyond that.
- define API option --api-groups
- api.c allow unwell devices to be enabled so they can be cured
- miner.php - fix/enable autorefresh for custom pages
- miner.php allow custom summary pages - new 'Mobile' summary
- Work around pools that advertise very low expire= time inappropriately as this
leads to many false positives for stale shares detected.
- Only show ztex board count if any exist.
- There is no need for work to be a union in struct workio_cmd
- fpgautils.c include a debug message for all unknown open errors
- Don't keep rolling work right up to the expire= cut off. Use 2/3 of the time
between the scantime and the expiry as cutoff for reusing work.
- Log a specific error when serial opens fail due to lack of user permissions
- Increase GPU timing resolution to microsecond and add sanity check to ensure
times are positive.
- Opencl code may start executing before the clfinish order is given to it so
get the start timing used for dynamic intensity from before the kernel is
queued.
- fpgautils.c - set BAUD rate according to termio spec
- fpgautils.c - linux ordering back to the correct way
- miner.php remove unneeded '.'s
- miner.php add auto refresh options
- miner.php add 'restart' next to 'quit'
- miner.php make fontname/size configurable with myminer.php
- Make the pools array a dynamically allocated array to allow unlimited pools to
be added.
- Make the devices array a dynamically allocated array of pointers to allow
unlimited devices.
- Dynamic intensity for GPUs should be calculated on a per device basis. Clean
up the code to only calculate it if required as well.
- Use a queueing bool set under control_lock to prevent multiple calls to
queue_request racing.
- Use the work clone flag to determine if we should subtract it from the total
queued variable and provide a subtract queued function to prevent looping over
locked code.
- Don't decrement staged extras count from longpoll work.
- Count longpoll's contribution to the queue.
- Increase queued count before pushing message.
- Test we have enough work queued for pools with and without rolltime
capability.
- As work is sorted by age, we can discard the oldest work at regular intervals
to keep only 1 of the newest work items per mining thread.
- Roll work again after duplicating it to prevent duplicates on return to the
clone function.
- Abstract out work cloning and clone $mining_threads copies whenever a rollable
work item is found and return a clone instead.
- api.c display Pool Av in json
- Take into account average getwork delay as a marker of pool communications
when considering work stale.
- Work out a rolling average getwork delay stored in pool_stats.
- Getwork delay in stats should include retries for each getwork call.
- Walk through the thread list instead of searching for them when disabling
threads for dynamic mode.
- Extend nrolltime to support the expiry= parameter. Do this by turning the
rolltime bool into an integer set to the expiry time. If the pool supports
rolltime but not expiry= then set the expiry time to the standard scantime.
- When disabling fanspeed monitoring on adl failure, remove any twin GPU
association. This could have been leading to hangs on machines with dual GPU
cards when ADL failed.
- modminer: Don't delay 2nd+ FPGAs during work restart
- Disable OpenCL code when not available.
- Fix openwrt crashing on regeneratehash() by making check_solve a noop.
- FPGA - allow device detect override without an open failure
- Fix sign warning.

I don't think people have yet realised how scalable and low overhead the cgminer code is. I basically wrote it like it was the core of an operating system, since my programming background is writing for the linux kernel. I estimate the current cgminer code for 2.4.4 can get 30TH of work out of every getwork every 30 seconds, and xiangfu has confirmed that 90 icarus FPGA devices (34 GH) still only uses 4% CPU, so scaling to ASIC hashrates will be  almost trivial, even for low spec hardware, even WITHOUT a getwork protocol change. Pool software, on the other hand, might be inundated by the amount of difficulty 1 shares returned so they really need to be looking towards higher difficulty shares (which I have posted about before here and cgminer already supports) to cope.

Thanks guys. I'm watching BFL's movements closely on this one as it likely will determine what I'll be doing long term with bitcoin mining.

Here is what Kano had to say about the whole icarus code issue which is one of the issues that caused the fork in the first place:
https://bitcointalk.org/index.php?topic=28402.msg997424#msg997424

1. Precisely why I tried getting sponsorship from BFL themselves in the form of hardware, so yes.
2. Not my area of expertise and the project progress appears slow...

Very kind words about supporting cgminer they be, thank you. Alas BFL care not.

It did indeed and I was most impressed by the community's generosity at the time. I had issues with FPGA and never wanted to invest or even develop for them because they really did not look like they'd ever pay themselves off - and indeed if ASIC really does come in any time in the next year, pretty much not one single FPGA will have made a profit before they're defunct technology and just doorstops. On the other hand I can still sell my GPUs if they become defunct technology and they've never made a loss. ASIC is a different beast entirely. They polarise the issue into one of being 100% you MUST bet on bitcoin being successful, like FPGAs, but they are very different in that they will also be the ONLY way to make a profit mining should they eventuate.

Personally I don't like sending money into a black hole and hoping the universe will spit out a device in response. I'm disappointed, but not remotely surprised, by BFL's silence in response to my emails and polite posts on the forum. To be able to code a meaningful set of device drivers for their devices I would need access to each of the devices on offer. I'm not expecting anyone to donate a $30k device, but the lower spec devices would be very reasonable sponsorship for the work, and at least giving me temporary remote access to develop for the $30k device would be beneficial for all in my opinion. On the other hand, if the community doesn't care one bit about what software they're mining with, and a software solution arises that is a "turn on and it just mines", I'm just wasting my time here. That is definitely a huge factor in my thought process.

While that may be true, cgminer is now only about 5% of the original cpuminer code since 20 times more code replaced what was there, so it's hardly a comparison.

No, it's always a difficulty 1 share at the moment, so it's dependent on MH/s and LUCK. So over short periods luck matters and the utility can't be relied upon for at least an hour.

Maybe this is what leads to the end of the world? Maybe with all those hashes the bitcoin network becomes self aware and destroys the world?

re: The ASIC revolution

I'm in two minds about what I'll do if/when the ASIC revolution comes. I've tried to engage BFL as potentially developing software for their hardware somehow sponsored by them, but they're completely silent in response. Furthermore any software developed to drive them will likely be based on existing fgpa code which I had no input into, which means that if I don't do the development, it will be luke-jr who does as the fpga code was done by luke-jr who now maintains a semi-hostile fork of cgminer and I guess he's ideally positioned to take over maintainership of the project entirely as that fork if I pull out. I'd hate my baby to end entirely in his hands but it's looking inevitable unless I fork cash out to BFL who I don't even trust, to do the code for their own hardware. They obviously realise they'll corner the market in the interim regardless of what their software and community support will be like so they are guaranteed to make huge profits and they need not engage the community and developer(s) in a positive way.

I will most definitely be maintaining cgminer and actively developing it right up to the moment some real ASIC hardware appears, so don't think I'm abandoning anything any time soon. Ironically a lot of the recent development has been towards making cgminer scale to massive hashrates, devices and pools.

Comments please.

Calm down guys ffs.

Read point 5 I put here years and years ago:
http://ck.kolivas.org/faqs/replying-to-mailing-list.txt

I said it would be the new version. I didn't say it was the new version.