Heh, it's okay. I can implement anything I like if I feel like it, but I was just trying hard not to make any significant changes to the code for fear of breaking the heard-earned stability it now has.

It's possible, but currently cgminer can't differentiate a GPU being disabled from the menu or at startup from being disabled due to overheating, so it was chosen as being intrinsically safe to be that way. I'll think about it.

If the ADL library is returning unsupported as the value from a device, cgminer won't try and show temp/fanspeeds for that device. If it's failing sometimes only for you, then the library is doing something funky :\ It's a miracle we ever got the library to control and monitor those values but it's an even bigger miracle that it works mostly as advertised. Unfortunately it's not always very reliable...

Glad to see people are appreciating the many facets of cgminer now...

I have one major mining box that's been mining for 6 months solid at 1750+MH/s without ever changing the drivers from the reliable 11.6 drivers... oh and it's never once crashed.

I just had to point out to them that you had done the work and there was no point procrastinating any further...

Kano has been very responsive and quick to develop this, but very few have tested it, and no one has paid him yet. I quite like what I see so far.

The source code for cgminer is available online:

https://github.com/ckolivas/cgminer

You or the antivirus makers can audit it or build it yourself for windows and be guaranteed it's not a virus if you don't trust the binaries I supply. However, I'm the one who wrote the software so if you can't trust me despite the source code being available, then you are in deep shit. Soon every single windows user who wants to mine will be alienated by the antivirus software makers because every single piece of mining software *can* be bundled with a trojan. That doesn't make the mining software a virus trojan adware spyware keylogger or other random fucking shit that poor windows users suffer.

No.

Looks like you have dual GPU cards in there. The fan is controlled entirely by the first GPU and reports back the correct fan speed in RPM. When the device does not support reporting speed in RPM, cgminer will report it back in percentage. The fact that that GPU reports a lower speed is because it's trying to set the fan lower because the temperature is below 75, but the value is of course meaningless since no fan is actually connected to the output on that GPU; it's entirely dependent on the fan of its twin GPU.

Once you disable a pool in cgminer, what it does is stop requesting work from that pool. Now since work may be underway already from that pool, it will continue to look for shares in the existing work until all the work expires. The default expiration for work is set to 60 seconds. Then it will continue to try submitting shares if it has found any until the shares expire. The default expiration is set to 120 seconds. There is no point in throwing away work it has already started on. Anyway the practical upshot of this is that shares may be submitted for up to 2 minutes after you disable a pool. Furthermore, if your primary pool (pool 0) was disabled, the longpoll will still be coming from the primary pool and longpoll itself generates more work so after every longpoll you will still get a few small work items from that pool. I used to make longpoll switch from one pool to another whenever you changed your pool choice, but it led to crashes so it was simpler to just leave longpoll going to the one pool. I may revisit that code in the future but for the most part it doesn't matter who the longpoll comes from unless you're mixing merged mining and non-merged. In that case you should probably be using a merged mining pool as your primary pool so that longpoll goes to that and then you can throw out more work since that's what you want to do when merged...

--auto-gpu

cgminer will not assume you want it to automanage anything unless you tell it to

cgminer does not touch fan speed unless you enable --auto-fan

Thanks very much for the sentiment. A few more people have donated, and some previous people have donated more since I made that comment. Indeed it was hundreds of hours as I spent the greater proportion of my time working on cgminer when I had 3 months off work.

For those talking about the windows version, perhaps you missed this:

As coretechs said "aticonfig -f --initial --adapter=all" is probably what was missing. It sounds like you only had one GPU configured and the second is limping along purely by being attached by crossfire. You shouldn't need crossfire.

If and when it's finalised, I will be merging it into my tree, and then eventually I will make a windows version from it when I release a new official version of cgminer. However I would appreciate kano fixing any windows builds before then since things inevitably break when trying to port it.

Yeah I remember deepbit's uber long round, but I think that was when difficulty was closer to 2mill.

Anyway poor ozcoin's round isn't over yet so we'll see how this one pans out for them 

12.3x difficulty has to have hurt. I was  speaking specifically of shares/difficulty since that correlates most strongly with the worst luck.

Most pools have had their fair share of bad luck over their runtime, but I wonder what is the all time worst recorded hashrate / difficulty of any pool recorded so far? ozcoin is having an exceptionally bad run right now with almost 12 million shares on their current block over the current difficulty of 1192498. Of course one block is no marker for how a pool will perform after that...

It would be quite nice if people helped get them out of this rut.