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