The rewrite of how work is gathered into a getwork scheduler is well underway and in the git master tree now undergoing testing. It would not be surprising if it introduces new instability, but I'm hoping for the master branch to be tested and debugged over the next week paving the way for the next version. For what it's worth, it's currently running fine for me. Other goodies including new mmq and ztex code are in there too.

I experimented with native cuda on nvidia GPUs here at home and it performed the same speed as opencl for bitcoin mining. The only advantage I found with native cuda was I could get the CPU usage down by disabling polling in it, which you cannot do with opencl on nvidia. So in summary, just use any miner with an opencl kernel that runs on your GPU. cgminer works fine.

You're welcome The price of continued development is temporary instability, and it's users that give feedback that allow me to achieve stability once more.

Make sure to test latest, it was addressed in 2.9.7

To be fair, kano is a valued coder and contributor to cgminer and its "defence" as it were, on these most unfriendly forums. However, he should most certainly not be considered the public face of cgminer, which I take full responsibility for. Kano has been, and will be, extremely valuable to the cgminer code, but we have also had our disagreements, and he has humbly accepted no as an answer since I remain the maintainer of the code. On the other hand, lack of humility is precisely why we are where we are with a hostile fork of cgminer. I and Kano have admitted we were wrong whenever appropriate. I don't want to play tit for tat and name calling and dick size comparisons, but the bottom line is, please don't think Kano is the face of cgminer. Look for where I have personally "attacked" someone on the forums before making a judgement about the public face of cgminer.

The slightly higher rejects with stratum+cgminer on this pool should now be addressed in cgminer 2.9.7. If not, we need to examine why.

You're right, it wasn't tagged. Tagged now (and be aware it's on the 2.9 branch).

New version: 2.9.7, 7th December 2012

Bugfix only release. There are lots of pending changes which will be a new point release, but this is concentrating only on the known bugs that have fixes for 2.9.


Human readable changelog

Fixed the problem where backup stratum pools specified with stratum+tcp:// first would never come online.
Fixed another crash with GBT.
Decrease rejects with stratum by tying in target difficulty only with the work difficulty, as discussed on this forum thread with slush et. al
Don't show WU with scrypt mining since the number is wrong.
Windows builds are built and shipped with a new libcurl (and libusb) dll that hopefully improves stability.
Better load balance with stratum.


Full changelog

- Set pool probed to true on successful authorisation with stratum to avoid it
being pinged later with pool_getswork.
- Allow pool active to be called on stratum or disabled pools in the watchpool
thread if the pool has not been probed.
- Remove unused variable.
- Use a variable length string array in submit_upstream_work to cope with
massive GBT submissions.
- Remove unused getwork times in getswork.
- Don't show broken WU value with scrypt mining.
- The specification for stratum has been elaborated to say that a changed diff
applies only to new work so do not retarget when submitting shares.

Yeah, are you specifying the stratum server with stratum+tcp:// ? There's an issue with backup pools specified that way at the moment. Try leaving out the prefix, or specify them as http:// and it will just do stratum.

There will shortly be some massive changes to the git master tree - no unfortunately it still isn't any ASIC driver, but it will be stuff to prepare for it. In anticipation, I have created a 2.9 branch for those who want just fixes to the stable tree in the meantime. Some fixes to existing issues have already been committed to the 2.9 branch, but lots of potential breakage will be making its way into the master tree.

Which will never happen now.

Funny, the 5 series ATI were faster than the 6 series ATI as well but at least we knew why that was the case there (vliw5 vs vliw4 architecture), while no one knows or cares for these poor nvidia cards and bitcoin mining. On the other hand, coinlab will eventually start having some cuda based workloads for nvidia to make them earn something at some stage in the future.

mingw32-curl 7.27.0-1 is what I'm distributing libcurl from.
The one people usually post as a bug is that their own IP address changed or something like that.

Longstanding bug on windows for when network goes down; it's my secret way to get people to move to linux.

Obviously not the case, but anyway I've not been able to reproduce it myself so must be some combination of windows or other issue. You could always try helping debug it following instructions in here:
http://ck.kolivas.org/apps/cgminer/debug/

I suspect it's just the libcurl implementation on windows... which would be bad news since it won't be something I can personally fix.

Never ceases to amaze me how many miners set up precisely one pool without a backup, at the highest fee, and virtually never update anything, nor check on whether it's working properly. Mining profitably just isn't like that... 

I'd go so far as to say no GPUs are designed to be maxed out 24/7. There's nothing special about "gaming cards". By default, the cooling/fan setup on GPUs is designed for bursts of heat to allow temps to rise to very high levels, with the fanspeed being a compromise between adequate cooling and fan noise. This is why it's so important to use a custom fan/cooling setup if you're planning on keeping the GPU loaded 24/7. Short bursts of very high heat are harmless, but sustained high temps seriously shorten lifespan.

Drop GPU engine overclock, not "difficulty", whatever you mean by that.

Except that litecoin is currently mining at an even bigger loss than btc.

Specifically I think it's inappropriate to ask for more than one set of transactions for each stratum notify push. I don't know what else you'd want to do to prevent them using this for every single stratum push.

Well this is what happens with his current approach to unsuspecting miners:
https://bitcointalk.org/index.php?topic=16385.msg1376838#msg1376838

luke-jr's code is intentionally checking far too often, trying to make stratum look worse than GBT. Enough of his crap, don't let his influence ruin stratum too.