Thanks. The "algo c" does nothing with GPU mining, it's for CPU mining. That is pretty much the best settings for your hardware. The 5 second average unfortunately is always going to jump around (due to it being coarse intentionally to avoid overhead, and in your case you have it set to 2 seconds with -l 2) and the overall average settles down after about 5 minutes or so.  That is a true all time average of hashes done / time running.

There is no windows build with the sse2 and sse4 support. Someone needs to build a 64 bit version to get those.

So your shell was also 80 columns

You're welcome! The issue was that windows opens a standard dos shell in 80 columns and the default text was slightly wider than 80 so I made it more concise.

Oversight.

Darn. You do have the 2.4 SDK installed don't you?

That should not be the case (the infinite rejects). There was an older version which had a bug with the nvidia implemented kernel and that would happen, but shouldn't happen with the latest version. cgminer only uses bfi int patching on cards that support it, and uses a separate kernel for nvidia cards.

Re the high cpu usage: Setting an intensity level usually uses a lot less CPU than letting it figure it out dynamically, but the windows build just uses a lot more cpu in general.

I suggest you don't give it a -g parameter at all. The default of 2 is often the best, but feel free to experiment.

It does not support "make install" just yet.

Thread restart was temporarily disabled on 1.3.0 pending further changes. It's been reimplemented in 1.3.1 so please upgrade. Sometimes the GPU code just gets stuck and the GPU never returns, killing off the thread. That's why I put the thread watchdog in there but I had to disable it in 1.3.0 till more code went in to match architectural changes.

Reboot?

-o http://pit.deepbit.net:8332

Looks like it never got the threads started. Grab a fresh tarball, uninstall sdk2.1 and install sdk2.4 perhaps. The phatk kernel in it may no longer be compatible with 2.1.

Thanks for positive feedback Don't know about the nvidia gpus thing, sorry.

You can't mix bitcoin and namecoin in the same instance as the blocks won't match and it will continue to think every work item is from a new block. That's how it detects new blocks without a longpoll.

The runtime summary only happens if the program exits cleanly. Windows just doesn't like me and the program has to be killed instead of stopped at this stage which is why you never get that summary. The hash rate per thread will add no useful information since the work is spread precisely evenly between each thread going to the same CPU.

When I've seen this bug before, those who had it reported that it got better after a reboot. Why, I don't know. Something to do with leaving the GPU in some indeterminate state from old code maybe. Make sure you delete any filenames with .bin in their name on the next boot before running it if it hasn't started successfully please.

New release: 1.3.1
Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.3.1.tar.bz2

Windows binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.3.1-win32.zip

Executive summary:
Multiple failover strategies available by user choice. More lax with inputting values for multiple pools. Faster switch on pool change. Watchdog thread for dead GPU threads reinstated.


- Feature upgrade; Multiple strategies for failover. Choose from default which
now falls back to a priority order from 1st to last, round robin which only
changes pools when one is idle, rotate which changes pools at user-defined
intervals, and load-balance which spreads the work evenly amongst all pools.
- Implement pool rotation strategy.
- Implement load balancing algorithm by rotating requests to each pool.
- Timeout on failed discarding of staged requests.
- Implement proper flagging of idle pools, test them with the watchdog thread,
and failover correctly.
- Move pool active test to own function.
- Allow multiple strategies to be set for multipool management.
- Track pool number.
- Don't waste the work items queued on testing the pools at startup.
- Reinstate the mining thread watchdog restart.
- Add a getpoll bool into the thread information and don't restart threads stuck
waiting on work.
- Rename the idlenet bool for the pool for later use.
- Allow the user/pass userpass urls to be input in any order.
- When json rpc errors occur they occur in spits and starts, so trying to limit
them with the comms error bool doesn't stop a flood of them appearing.
- Reset the queued count to allow more work to be queued for the new pool on
pool switch.


New options:
--load-balance      Change multipool strategy from failover to even load balance
--rotate <arg>      Change multipool strategy from failover to regularly rotate at N minutes (default: 0)
--round-robin       Change multipool strategy from failover to round robin on failure


From the README:

FAILOVER STRATEGIES WITH MULTIPOOL:
A number of different strategies for dealing with multipool setups are
available. Each has their advantages and disadvantages so multiple strategies
are available by user choice, as per the following list:

FAILOVER:
The default strategy is failover. This means that if you input a number of
pools, it will try to use them as a priority list, moving away from the 1st
to the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it will
move back to the higher priority ones.

ROUND ROBIN:
This strategy only moves from one pool to the next when the current one falls
idle and makes no attempt to move otherwise.

ROTATE:
This strategy moves at user-defined intervals from one active pool to the next,
skipping pools that are idle.

LOAD BALANCE:
This strategy sends work in equal amounts to all the pools specified. If any
pool falls idle, the rest will take up the slack keeping the miner busy.

There isn't a binary distribution packaging command, only a source one (make distdir). Ycros has been packaging the 3 necessary dlls, the 2 .cl files, the executable and READMEs himself into zips. He may have automated it for himself, I'm not sure.

Updated tree: Re-enabled the watchdog thread code (which was disabled in 1.3.0), reworked to be smarter and only restart threads not waiting on work and have gone idle for some other reason (gpu overheated, gpu code stuck etc.).

Updated git tree:
- The order of urls/user/pass is not critical any more so long as you give it the same number of urls and credentials
- json config file is now working again. json does not allow the same entry to be used twice so for the time being, to get two or more pools working you need to create a config file for each and pass multiple -c to cgminer. I'm considering options for how to tackle this, but likely using a urlX counter in the parameters will be the solution I go with. Or move to a different format entirely.