Seems to me like you've got it all under control, so I'll leave you to finish up. Thanks for your involvement. However I don't want multiple phatk kernels so just replace the current one in-situ and don't bother enumming a different kernel. As for the output code, I prefer to use 4k so feel free to do it your way, but be aware I plan to change it back.

Yes indeed, that's what I've spent weeks working on to get right. To restart it if it can only. The 5 minutes was a nominal choice based on the theory that if it gets sick, giving it a few minutes to cool down will make it more likely to respond. Note that if it gets sick a LOT, you may benefit from decreasing the intensity and sacrificing a few MH just to get a more stable throughput (eg -I 7 instead of .

Good idea. Though I might just put the pool number rather than the whole URL because the URL can be quite long leading to a very long log message. ?

You could just tell me what to do to interface it with cgminer (i.e. what new variables you want) and I'd copy most of your kernel across. Only the return code and define macros are actually different in cgminer in the kernel itself.

New version. NOTE the windows binary should CPU mine again (-O3 was unstable, but -O2 works) and includes a cpumine only executable as well.

Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.5.tar.bz2
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.5.tar.lrz

Ubuntu:
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.5-x86_64-built.tar.bz2
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.5-x86_64-built.tar.lrz

Windows 32 bit binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.5-win32.zip


Version 1.5.5 - August 16, 2011

- Rework entirely the GPU restart code. Strike a balance between code that
re-initialises the GPU entirely so that soft hangs in the code are properly
managed, but if a GPU is completely hung, the thread restart code fails
gracefully, so that it does not take out any other code or devices. This will
allow cgminer to keep restarting GPUs that can be restarted, but continue
mining even if one or more GPUs hangs which would normally require a reboot.
- Add --submit-stale option which submits all shares, regardless of whether they
would normally be considered stale.
- Keep options in alphabetical order.
- Probe for slightly longer for when network conditions are lagging.
- Only display the CPU algo when we're CPU mining.
- As we have keepalives now, blaming network flakiness on timeouts appears to
have been wrong.     Set a timeout for longpoll to 1 hour, and most other
network connectivity to 1 minute.
- Simplify output code and remove HW errors from CPU stats.
- Simplify code and tidy output.
- Only show cpu algo in summary if cpu mining.
- Log summary at the end as per any other output.
- Flush output.
- Add a linux-usb-cgminer guide courtesy of Kano.

Courtesy of znort:
    Add automated benchmark of the CPU hashers
   
        The --algo switch now accepts the "auto" argument.
   
        When "auto" is passed to --algo, cgminer starts by benchmarking
        all the CPU algorithms it nows about and picks the fastest.
   
        This is useful for benchmarking, but also for folks who run
        cgminer on a large number of heterogeneous computers because
        it saves them from having to configure each instance optimally.
   
        Caveat emptor: depending on the platform, some algorithms will
        fail with "illegal instruction" (e.g. via padlock code on non via
        platforms, or SSE4 code on non SSE4 platforms).
   
        To protect against this, cgminer runs the benchmarks in a child
        process. The crash, if any occurs in the child, and the parent
        marks this algo as "fails" and continues benchmarking the next
        algorithm.

You need pkg-config installed.

Well it's the wrong thing for the pool to be accepting stale shares since that work is likely useless, so it's in the pool's best interest to not do so. On the other hand, if you're mining for such a pool, I guess you get to "cheat" with this useless work, so I can see how it would be an advantage to you. I could easily add another switch to the command line such as --submit-stale .

edit: This option has been committed to the tree.

Okay so I had some generous people offer me BTC online to get the windows binary version working, and I DID see someone offer a BTC bounty to get the windows binary working, so I've fluffed around for the last 2 days on a windows virtual machine to build some win32 binaries.

http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4-win32.zip

Hopefully people appreciate the effort.

I see. Well I can't even get it compiling on mingw32. Can't figure out how to install the remaining dependencies of libcurl though I've installed it 10 different ways and even ended up building it myself which took hours. Gotta remember I haven't used windows in over a decade in any meaningful way.

Don't be so sure. The windows binaries till now have been provided by Ycros, not me. I've never compiled anything on windows before and spent a day yesterday trying to do it in a virtual machine and have so far failed. I will keep trying today but if I give up in disgust then I may ping you for your help. Alas I don't know you that well so the web of trust between us needs to be built up for me to be happy to distribute your binaries.

HEADS UP TO GIT USERS.

The default branch is now "master" once more. Please use that instead of the branch called cgminer.

"forrestv" just informed me the fulltest function was disabled due to endian issues (I think) in the original cpuminer code that cgminer grew out of. Since cgminer pretty much only builds on little endian machines now anyway, it has been re-enabled, but only in the git tree. So this test is not active yet in the current release (1.5.4).

You cannot.

New release 1.5.4:

Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4.tar.bz2
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4.tar.lrz

Linux x86_64 ubuntu binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4-x86_64-built.tar.bz2
http://ck.kolivas.org/apps/cgminer/cgminer-1.5.4-x86_64-built.tar.lrz

Hopefully we can get a windows version from someone somewhere soon :O

Summary: cgminer should now use the backup pools much less frequently, should drop in performance on a longpoll much less, communicate with the server less, have higher efficiency, and hopefully have less problems with dying GPUs. It also supports the --monitor command (linux only at this stage).


Full Changelog:

- Add new option: --monitor <cmd> Option lets user specify a command <cmd> that
will get forked by cgminer on startup. cgminer's stderr output subsequently gets
piped directly to this command.
- Allocate work from one function to be able to initialise variables added
later.
- Add missing fflush(stdout) for --ndevs and conclusion summary.
- Preinitialise the devices only once on startup.
- Move the non cl_ variables into the cgpu info struct to allow creating a new
cl state on reinit, preserving known GPU variables.
- Create a new context from scratch in initCQ in case something was corrupted to
maximise our chance of succesfully creating a new worker thread. Hopefully this
makes thread restart on GPU failure more reliable, without hanging everything
in the case of a completely wedged GPU.
- Display last initialised time in gpu management info, to know if a GPU has
been re-initialised.
- When pinging a sick cpu, flush finish and then ping it in a separate thread in
the hope it recovers without needing a restart, but without blocking code
elsewhere.
- Only consider a pool lagging if we actually need the work and we have none
staged despite queue requests stacking up. This decreases significantly the
amount of work that leaks to the backup pools.
- The can_roll function fails inappropriately in stale_work.
- Only put the message that a pool is down if not pinging it every minute. This
prevents cgminer from saying pool down at 1 minute intervals unless in debug
mode.
- Free all work in one place allowing us to perform actions on it in the future.
- Remove the extra shift in the output code which was of dubious benefit. In
fact in cgminer's implementation, removing this caused a miniscule speedup.
- Test each work item to see if it can be rolled instead of per-pool and roll
whenever possible, adhering to the 60 second timeout. This makes the period
after a longpoll have smaller dips in throughput, as well as requiring less
getworks overall thus increasing efficiency.
- Stick to rolling only work from the current pool unless we're in load balance
mode or lagging to avoid aggressive rolling imitating load balancing.
- If a work item has had any mining done on it, don't consider it discarded
work.

What version of cgminer are you testing that does that? Because that's precisely what it does in submit_nonce:

   /* Do one last check before attempting to submit the work */
   if (!fulltest(work->data + 64, work->target))
      return true;

Or am I missing something

Don't be disheartened. I'm forever hacking up code and then deleting it. You wouldn't believe how much code I've thrown out so far working on cgminer. Not every experiment is successful.

After running it for a while on my 6970s, I find even this change is of no benefit either  It's ever so slightly slower it appears. Not sure what to do now about all this.

You can have as many as you like, and it will trickle work to the 2nd and 3rd when the 1st is relatively slow, or fail over completely to the 2nd when the 1st dies. Alternatively you can change the pool strategy to load balance where it shares work between all of them, etc... check the readme or top post in this forum. Also you can do all of this live while it's running just by pressing P and checking the options.

And that's almost certainly the return code which affected mine also. I'll be reverting it shortly.

edit: reverting just that change fixes it instantly.

Was on 2.4, tried 2.5 and it's still consistently slower.