Ego? That's easy to say. I don't see where they're coming from and why they're lower with other miners so I don't know what to fix.

Fine, it's broken. Go use guiminer thanks.

There are instructions for the most convenient way of installing libs and includes in the README.

You build from a release tarball. Then you can go straight to ./configure
Building from git you need to apt-get install autoconf automake
Then you can ./autogen.sh fine
Don't try to start building it any other way.

Prolonged outage is meant to be longer than that. There's some race there which is occasionally hit and does it very soon after. I'll work on that.

Lots of stales? Stale shares are harmless as they never get counted, it's just the app telling you it won't submit them.
Lots of rejects? You get paid according to accepted, so judge the effectiveness on the accepted. cgminer just happens to be brutally honest.

Still using POST? Yes we've been through this, check the discussion earlier on.

Windows build:
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.7-win32.zip

No it does not. It compiles one kernel once for all similar hardware and then loads the binary from that point on. Since you have to run cgminer from the source directory currently, that's where it also stores the binary file.

New version (windows build soon):
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.7.tar.bz2

Changelog:
- Show last 8 characters of share submitted in log.
- Display URL connected to and user logged in as in status.
- Display current block and when it was started in the status line.
- Only pthread_join the mining threads if they exist as determined by
pthread_cancel and don't fail on pthread_cancel.
- Create a unique work queue for all getworks instead of binding it to thread 0
to avoid any conflict over thread 0's queue.
- Clean up the code to make it clear it's watchdog thread being messaged to
restart the threads.
- Check the current block description hasn't been blanked pending the real
new current block data.
- Re-enable signal handlers once the signal has been received to make it
possible to kill cgminer if it fails to shut down.
- Disable restarting of CPU mining threads pending further investigation.
- Update longpoll messages.
- Add new block data to status line.
- Fix opencl tests for osx.
- Only do local generation of work if the work item is not stale itself.
- Check for stale work within the mining threads and grab new work if
positive.
- Test for idle network conditions and prevent threads from being restarted
by the watchdog thread under those circumstances.
- Make sure that local work generation does not continue indefinitely by
stopping it after 10 minutes.
- Tweak the kernel to have a shorter path using a 4k buffer and a mask on the
nonce value instead of a compare and loop for a shorter code path.
- Allow queue of zero and make that default again now that we can track how
work is being queued versus staged. This can decrease reject rates.
- Queue precisely the number of mining threads as longpoll_staged after a
new block to not generate local work.


Sample display:

 cgminer version 1.2.6 - Started: [2011-07-16 23:28:05]
--------------------------------------------------------------------------------
 [(5s):173.9  (avg):182.0 Mh/s] [Q:36  A:37  R:0  HW:0  E:103%  U:3.00/m]
 TQ: 1  ST: 1  LS: 0  SS: 0  DW: 0  NB: 1  LW: 1  LO: 1  RF: 0  I: 3
 Connected to http://ozco.in:8332 as user ckolivas.1
 Block 0001c18ef64e55b54f0d8cbabb09ff12  started: [2011-07-16 23:35:48]
--------------------------------------------------------------------------------
 GPU 0: [182.5 Mh/s] [Q:36  A:37  R:0  HW:0  E:106%  U:3.02/m]
--------------------------------------------------------------------------------

[2011-07-16 23:28:28] Share fbbbfd7a accepted from GPU 0 thread 0
[2011-07-16 23:28:38] Share 366da5b7 accepted from GPU 0 thread 0
[2011-07-16 23:28:46] Share fce072de accepted from GPU 0 thread 1
[2011-07-16 23:29:47] Share e7918c2d accepted from GPU 0 thread 1
[2011-07-16 23:29:47] Share 3ca2631b accepted from GPU 0 thread 1
[2011-07-16 23:30:11] Share 2c8ceab5 accepted from GPU 0 thread 1
[2011-07-16 23:30:58] Share b556d2f9 accepted from GPU 0 thread 0
[2011-07-16 23:31:27] Share cc065b5a accepted from GPU 0 thread 1
[2011-07-16 23:35:46] Server not providing work fast enough, generating work locally
[2011-07-16 23:35:48] New block detected on network before longpoll, waiting on fresh work
[2011-07-16 23:35:48] Resuming with work from server
[2011-07-16 23:35:58] Share e99bc71d accepted from GPU 0 thread 1

About cpu usage:

Currently the windows build always uses a lot more CPU than the linux build. It has to do with the windows library that gives support for the linux features and I'm not sure there's anything to do about it. Beyond that, some drivers use a lot more CPU when more than one card is in use. The other big CPU user is when dynamic mode is enabled, as it constantly monitors the GPU usage and throttles it accordingly, but conversely spends more CPU time doing this. To decrease CPU usage, disable dynamic mode by choosing an intensity with -I.

About dynamic mode:

The intensity level is determined by cgminer to be that which will keep the desktop GUI fluid based on how quickly it refreshes. If you have a low power card, the intensity will almost always be low because of this. If you have a high power GPU, it may well get to quite high intensity levels even when still in use.

About the OSX build:

It should build if you have the right tools for it. Ycros is helping me out there.

About shares rejected:

When doing solo mining, you are constantly trying to find a block for yourself and anything that looks like it might be a block is submitted to the network. Most of the time it will be rejected because it's not the real block you've found.

About stopping in windows:

I'm working on trying to make it more robust, but ctrl-break is the only way to stop it at the moment.

Other stuff:

Low priority while I try to get cgminer as stable as possible with the most frequently requested or sponsored features. While I have spent a LOT of time on this project, I do not have infinite time to implement everything in such a short time space.

x-roll-ntime is supported, but indirectly. The "local generation of work" cgminer does is rolling ntime, and is only done when network connectivity cannot keep up with demand for work. I'm not sure how much I'll be expanding on this feature in the future. I'd be surprised if cgminer couldn't keep massive hashes busy already given how the work is gathered for the worker threads at the moment.

Updated git tree:

- Disable restarting of CPU mining threads pending further investigation.
- Update longpoll messages.
- Add new block data to status line.
- Fix opencl tests for osx.
- Only do local generation of work if the work item is not stale itself.
- Check for stale work within the mining threads and grab new work if
positive.
- Test for idle network conditions and prevent threads from being restarted
by the watchdog thread under those circumstances.
- Make sure that local work generation does not continue indefinitely by
stopping it after 10 minutes.
- Tweak the kernel to have a shorter path using a 4k buffer and a mask on the
nonce value instead of a compare and loop for a shorter code path.
- Allow queue of zero and make that default again now that we can track how
work is being queued versus staged. This can decrease reject rates.
- Queue precisely the number of mining threads as longpoll_staged after a
new block to not generate local work.

Install the ati amd sdk:
http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx

That's even better news since it confirms the validity of cgminer's ability to continue doing useful work in the network outage. Thanks.

@ewal: Thanks very much for that test.

I will likely be adding a timeout where it can only do locally generated work for 20 minutes since 10 minutes is the average duration it takes for a new block to appear on the network. Best to not keep mining forever with a real network outage.

Updated git tree:

Made the kernel code ever so slightly smaller and faster. It does not appear to be significantly faster unless you squint real hard when looking at the hash rates. Anyway, it's there because it's a good thing [tm]. You'll need to do ./autogen.sh again with this change to the tree if building from git.

More stuff planned when time allows.

New windows build:
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.6-win32.zip

Quick bugfix release version 1.2.6:

Source
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.6-1.tar.bz2

(windows build soon hopefully)

- Put a current system status line beneath the total work status line
- Fix a counting error that would prevent cgminer from correctly detecting
situations where getwork was failing - this would cause stalls sometimes
unrecoverably.
- Limit the maximum number of requests that can be put into the queue which
otherwise could get arbitrarily long during a network outage and increase rejects.
- Only count getworks that are real queue requests.
- Allow queued to be zero again since you can now see the queued versus staged value and tune it better. This can also decrease stales.


New status line has the following:
TQ: 2  ST: 2  LS: 0  SS: 0  DW: 0  LW: 0  LO: 0  RF: 0  I: 2

from README:
TQ is Total Queued work items.
ST is STaged work items (ready to use).
LS is Longpoll Staged work items (mandatory new work)
DW is Discarded Work items (work from block no longer valid to work on)
LW is Locally generated Work items (during slow server providing work)
LO is Local generation Occasions (server slow to provide work)
RF is Remote Fail occasions (server slow to accept work)
I is current Intensity (changes in dynamic mode).

If you find the STaged value is often at zero despite your TQ being high then your server may be slow at providing work and you can use this to tune the number of work items in the queue with -Q. It should always be great than 0 if TQ is greater than 0.

This version is slightly faster on average thanks to not slowing down as often during the getworks

Searched out more discussions on other threads and it was decided this was incorrect. I'm leaving it as is with POST after taking it under advisement from other people since I have no actual opinion on the matter.

7 theads per gpu is really not going to help you. Stick with the default of 2. Plus try some other values, like not setting -w or set it to 128 or set intensity to no higher than 8.

New release version.

Source only at the moment:
http://ck.kolivas.org/apps/cgminer-1.2.5.tar.bz2

New features:
- I removed the -n option being no dynamic and left it how it was as number of devices
- Setting an intensity now of any value automatically disables the dynamic feature. It was basically completely overrided if dynamic was enabled, so these are now mutually exclusive features.
- I've added signal handling to try and clean up at the end and return the shell/console neatly if you press ctrl-c. I believe you need to use ctrl-break on windows still (when the binary comes out).
- There is a new option:
 --text-only|-T      Disable ncurses formatted screen output
- I've made it so that the watchdog thread only restarts threads if they're inactive in the setting of normal network conditions and will not try to restart them if the network connectivity is down.
- cgminer now tests on startup that it can connect at least once with the url and credentials to not try and reconnect indefinitely.
- There is no "fake work" at startup now with one hard lot of work handed to the gpu mining thread which should prevent the false positive hardware errors reported.
- CPU mining has been fixed, it was not resetting back properly on getting a new work item.
- The status window in curses mode will update more reliably and do less work now.
- Modifications to build on mingw32 for windows and now to build on osx courtesy of Ycros
- A status summary is now printed on exiting cgminer. It looks like this:

---
Summary of runtime statistics:

Started at [2011-07-15 01:05:28]
Runtime: 0 hrs : 12 mins : 13 secs
Average hashrate: 178.4 Megahash/s
Queued work requests: 33
Share submissions: 28
Accepted shares: 24
Rejected shares: 4
Reject ratio: 14.3
Hardware errors: 0
Efficiency (accepted / queued): 73%
Utility (accepted shares / min): 1.97/min

Discarded work due to new blocks: 4
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 0
Work items generated locally: 0
Submitting work remotely delay occasions: 0
New blocks detected on network: 2

Summary of per device statistics:

 GPU 0: [178.4 Mh/s] [Q:33  A:24  R:4  HW:0  E:73%  U:2.04/m]


... I think I need a little break now

You can log to a file with the curses output. Just redirect stderr to a file.
./cgminer blah 2>mylogfile.txt

cgminer detects if stderr is going to a file or just the console and decides on whether to log to it or not.

Crashes are part of the game early on in code, and hopefully I can close in on all of them.

More code to come shortly (most in git tree already)...