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.

Unfortunately, on my 6970s it is actually appearing to be slower   I may have to revert this change.

edit: On my 6770 it's clearly faster and clearly slower on the 6970s... now I'm really confused.

It's interesting that it should be faster

a = (b == c);
is the same as
if (b == c) a = 1; else a = 0;

as far as code is concerned and ends up being compiled into the same thing in c.

Perhaps it's a weakness in the opencl compiler, or maybe it's just the jump path is inefficient since there are multiple statements in the if {} loop.

Anyway I've merged it for what it's worth, and updated poclbm accordingly as well.

(EDIT: By the way, I'm not seeing any improvement).

I would say you need to attribute ZERO value to any perceived changed to utility and efficiency. It's entirely network dependent, so please do not place any value on it. When pools with 3Thash or more can go from -40 to +10% efficiency, it's impossible to use those to determine performance.

Sorry I mixed you up with ah42. I'm quite aware of the changes required to make it work though, thanks.

I was mistakenly under the impression your changes incorporated everything from the latest kernels. Perhaps I may have to roll them all back and start porting it all myself. Darn. 

ALUs are not the only way to judge performance.

I have incorporated his changes into the main git tree now.

Don't be scared. You're doing good work. I'll play with your changes and see if they break anything

Also be aware that it may silently pretend to set the values but not actually do so. Although my 6970s report ram speeds possible of 320-1450, if I set them to anything below 825, it actually just resets them to normal values.