I'm not sure if the config file works. Probably not yet. I spent an awful lot of time getting this feature working and then wanted to release it because the demand for it was high. I was hoping people would test it and then I could worry about the interface...

One does not. The poclbm kernel is far far behind the phatk kernel in speed and any hardware that can run the phatk kernel is given it. The poclbm kernel is reserved for nvidia cards and ATI 4x cards only. The phatk kernel, even without bitalign patching, crashes on these lesser mining cards.

You shouldn't need to delete the .bin files on each startup unless you change the SDK you are using.

Sample output on exiting now:

Zaytsev is supplying RPMs of cgminer now:
http://forum.bitcoin.org/index.php?topic=29667.0

Major update version 1.3.0:
Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.3.0.tar.bz2

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

- Massive infrastructure update to support pool failover.
- Accept multiple parameters for url, user and pass and set up structures of
pool data accordingly.
- Probe each pool for what it supports.
- Implement per pool feature support according to rolltime support as
advertised by server.
- Do switching automatically based on a 300 second timeout of locally generated
work or 60 seconds of no response from a server that doesn't support rolltime.
- Implement longpoll server switching.
- Keep per-pool data and display accordingly.
- Make sure cgminer knows how long the pool has actually been out for before
deeming it a prolonged outage.
- Fix bug with ever increasing staged work in 1.2.8 that eventually caused
infinite rejects.
- Make warning about empty http requests not show by default since many
servers do this regularly.


In a nutshell, apart from bugfixes, this version now implements smart failover support of virtually unlimited pools. It selectively probes each server for what it supports and adjusts accordingly how to manage poor network conditions. If a server supports x-roll-ntime it will use local generation of work for up to 5 minutes (half a block's duration) and then if it is still unable to connect it will then switch pools. If a server does not support local generation, it will wait for up to a minute and then switch pools. Once a switch has occurred it will try to switch longpolls to the appropriate server as well.

To use multiple pools, simply pass multiple urls and credentials. eg:

./cgminer -o http://url1:port -u user1 -p pass1 -o http://url2:port -u user2 -p pass2 ...

[note: url must come before username/password now]

Yes. Instructions are in the README. You need to install a recent yasm to get the assembly to compile as well. gluck.

I suspect the timeout is just too long with the GET so that even if it works it's eventually reset. I'll change that shortly in my git tree.

Yes I've experimented with the updated phatk kernel and haven't been able to demonstrate any measurable advantage :s Nonetheless I'll eventually implement it.

Ah yes. The windows binary version is a 32 bit compile which includes NONE of the high speed assembly code so it only has a very slow cpu mining algorithm. All the cpumining assembly included in cgminer is 64 bit only. I have no experience in assembly to make a 32 bit assembly version, but perhaps I can convince ycros to make a 64 bit windows build.

-g 0 will give you only CPU mining

Looks like the longpoll dies when communicating with your pool's server. Should be harmless since it can detect block changes itself, but it's not ideal. Something funny going on with longpoll, and it seems to be every time I try converting from post to get.

It's in the README.

Updated git tree:
The longpoll message was almost always being dropped in 1.2.8 and it thought it always detected the new block itself - should be fixed in the git tree.
It was possible to queue an ever increasing amount of staged work which would eventually lead to a rise in rejects as the shares submitted would eventually be quite old. Fixed.

Not sure, but it's likely due to the high CPU requirements of the windows build (which I can't do much about since I'm led to believe it's in the pthread library in use for the windows build). I can't reproduce the problem on linux. What happens if you run two instances of cgminer, one CPU mining and one GPU mining?

New release, version 1.2.8:
Source tarball:
http://ck.kolivas.org/apps/cgminer/cgminer-1.2.8.tar.bz2

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

Changes:
- More OSX build fixes.
- Add an sse4 algorithm to CPU mining.
- Fix CPU mining with other algorithms not working.
- Rename the poclbm file to ensure a new binary is built.
- We now are guaranteed to have one fresh work item after a block change and we
should only discard staged requests.
- Don't waste the work we retrieve from a longpoll.
- Provide a control lock around global bools to avoid racing on them.
- Iterating over 1026 nonces when confirming data from the GPU is old code
and unnecessary and can lead to repeats/stales.
- The poclbm kernel needs to be updated to work with the change to 4k sized
output buffers.
- longpoll seems to work either way with post or get but some servers prefer
get so change to httpget.


Executive summary:
Less rejects, less idle time at longpoll, less false messages, cpu mining fixed, nvidia gpu mining fixed, should build on osx.

No hashes should be lost. It doesn't work that way. It queues everything asynchronously for upload in a separate thread that has nothing to do with the hashing so everything eventually gets pushed to the server if it was found.

Efficiency 14 can take up to 15 seconds to return data from the GPU. That's a long time to not have reported back any shares. So it usually is less efficient to give such a big chunk of work to the GPU at any one time without reporting in more frequently, even though in theory it would be nice to keep the GPU as busy as possible. It's the law of diminishing returns where there doesn't seem to be any benefit beyond 8 or 9, and it starts introducing more problems.

The hashrate reported by cgminer is just how many hashes it's doing. Nothing more, nothing less. The pool is reporting an estimated hash rate based on returns. If your returns are relatively low (for whatever reason) then the pool will think you're hashing less. Now as for why you're having a bad return, I'm not really sure, but the high intensity is only doing you harm. Are you putting in a big queue? Are you running lots of threads?

Yes sorry, noted and fixed in the git tree with nvidia mining. The poclbm kernel was not updated to match the other changes and has been since fixed. Need to do a git clean -f and get the latest tree to fix it. The cpu mining issue... I dunno yet but the c algorithm seems dodgy though the assembly 64 bit one works fine here. Too much else to look at.

Because your efficiency is low. The pool reports back what it thinks your hash rate is based on the number of accepted shares you return.

Your efficiency is particularly low. That may be the result of setting the intensity too high. Drop it from 14 to 8.

The windows build has gpu mining built into it. You cannot do plain cpu mining on the generic windows build unless you build it without GPU mining support.