Other vector sizes have been tried. They suck.

About this, I have confirmed there is a bug in 2.7 where it can get into a situation where it can't queue enough work and continually thinks one pool is not providing enough work. I have fixed this in git but this has introduced a new crash which kano is trying to help me track down. In the meantime, anyone on 2.7.0 should probably enable --failover-only to mitigate its problems.

Yes this is precisely what's expected in anticipation of much faster hardware (if asics ever appear). If you mine solidly on one reliable efficient pool, the efficiency can reach legendary proportions.

It crashes other rigs completely. Presumably the -lack- of a gpumap breaks it completely and tries to tie everything to device 0. I'll look into re-importing your patch and making it work.

On second thought, there may be a bug here... will investigate tomorrow.

Very much depends on local hardware capabilities and network conditions it seems. Clearly in farfie's case it's just barely keeping up and cgminer is detecting it. Note that farfie's actual WU is the same mining in failover-only, so it's actually enough to keep the singles busy, but cgminer notes the buffer dropping very low often and ends up sending it elsewhere... either that or farfie has a different mode set up and doesn't know it (like in a configuration file that cgminer is loading without him knowing).

It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.

Thanks, much appreciate the useful filtering, and thanks luke-jr for your debugging.

Great feedback, thanks. Please email me the old binaries kernel@kolivas.org (one at a time or email will reject them), thanks!

Your crash is entirely within the AMD driver, so either you are having a hardware problem (dodgy card, too much overclocking, overheated vrms etc) or a driver problem. Can't see anything in the backtrace related to cgminer.

Yes it's definitely a bug introduced in 2.6.5 when I tried to work around windows' timers. Why, I dunno cause I can only try it on a laptop with windows that does 9.5Mhash so it's not a very useful piece of hardware to test it on...

Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...

If a pool screws up somehow (and the proxy pools are the ones most likely to) and starts rejected *all* your shares, cgminer will disable it after 3 minutes and only re-enable it when it starts accepting shares again already.

Server being relocated.

Thanks for feedback and much more for the donation

Startup GPU difference is just luck variance showing up. Perfectly normal.

Glad to hear failover works better.

Dynamic will show the "chosen" current intensity, which for an awesome 7970 works out to about 7. Perfectly normal. (shame it only works properly on linux it seems).

New release - 2.7.0, August 18th 2012

Normally a minor version (2.6->2.7) update brings with it instability, but in fact this release includes some very heavily tested code that was a long time in the making and because of its magnitude and impact it warranted a version update.


Human readable changelog:

The main change in this version is a complete rewrite of the getwork requesting mechanism. I've been slowly hacking away at it for some time, but finally gave up in disgust and have rewritten it almost entirely. Previously mining threads would occasionally throw out a request for more work, some arbitrary test would be done on whether more work should be requested, and it handed off the message to another thread which spawned another thread and that then sent the request and ... anyway the mechanism was so asynchronous that the arse didn't know what its head was doing by the time it was deciding on what to do for work. Worse yet it was hard to find the right place to reuse work and so it was never reused to its utmost potential. This is mostly my fault for gradually hacking on more and more asynchronous threaded components to cgminer and the demands for getting work have been increasing sharply of late with new hardware. The rewrite involves scheduling a new request based on the rate the old work items get used up, and is much better at predicting when it needs to leak work to backup pools and less likely to throw a "pool is not providing work fast enough" message. Overall you should now see much more Local Work (LW), the efficiency will be higher on pools that support rolltime, less work will be discarded, any magnitude rig will be kept solidly busy - note this MAY mean your overclocks will become that much more stressed if you have set clocks very aggressively. Thanks to numerous people who tested this on IRC during its development phase. For many of you, you'll be wondering what the fuss is about cause it will just appear as business as usual.

New pool strategy: Balance.
--balance           Change multipool strategy from failover to even share balance
This is to differentiate itself from the existing pool strategy, Load balance:
--load-balance      Change multipool strategy from failover to efficiency based balance

With the change to queueing and more roll work being possible than ever before, the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy. To offset that, and since the number of people using load balance has been increasing, the new strategy was added to try and give roughly the same number of shares to each pool. This required some code to estimate a rolling average work completion rate that was not dependent on difficulty, and would cope with dips and peaks as pools are enabled/disabled/fail. Otherwise you could end up mining 100% on solo since you would rarely be submitting only possible block solutions, and not shares.

New statistic: Work Utility. With higher difficulty share supporting pools in the testing phase, it is going to be hard to monitor overall work performance based on successful share submission. To counter this, work utility is a value based on the amount of difficulty 1 shares solved, whether they're accepted or rejected by the pool. This value will always be higher than the current "utility". (Note that difficulty 1 share counting on scrypt is not supported since the work is compared to the target on the GPU itself, but the total shares solved will be displayed).

Other minor bugfixes.


Full changelog:

- Introduce a new statistic, Work Utility, which is the number of difficulty 1
shares solved per minute. This is useful for measuring a relative rate of work
that is independent of reject rate and target difficulty.
- Implement a new pool strategy, BALANCE, which monitors work performed per pool
as a rolling average every 10 minutes to try and distribute work evenly over all
the pools. Do this by monitoring diff1 solutions to allow different difficulty
target pools to be treated equally, along with solo mining. Update the
documentation to describe this strategy and more accurately describe the
load-balance one.
- Getwork fail was not being detected. Remove a vast amount of unused variables
and functions used in the old queue request mechanism and redefine the getfail
testing.
- Don't try to start devices that don't support scrypt when scrypt mining.
- 0 is a valid return value for read so only break out if read returns -1.
- Consider us lagging only once our queue is almost full and no staged work.
- Simplify the enough work algorithm dramatically.
- Only queue from backup pools once we have nothing staged.
- Don't keep queueing work indefinitely if we're in opt failover mode.
- Make sure we don't opt out of queueing more work if all the queued work is
from one pool.
- Set lagging flag if we're on the last of our staged items.
- Reinstate clone on grabbing work.
- Grab clones from hashlist wherever possible first.
- Cull all the early queue requests since we request every time work is popped
now.
- Keep track of staged rollable work item counts to speed up clone_available.
- Make expiry on should_roll to 2/3 time instead of share duration since some
hardware will have very fast share times.
- Do the cheaper comparison first.
- Check that we'll get 1 shares' worth of work time by rolling before saying we
should roll the work.
- Simplify all those total_secs usages by initialising it to 1 second.
- Overlap queued decrementing with staged incrementing.
- Artificially set the pool lagging flag on pool switch in failover only mode as
well.
- Artificially set the pool lagging flag on work restart to avoid messages about
slow pools after every longpoll.
- Factor in opt_queue value into enough work queued or staged.
- Roll work whenever we can on getwork.
- Queue requests for getwork regardless and test whether we should send for a
getwork from the getwork thread itself.
- Get rid of age_work().
- 0 is a valid return value for read so only break out if read returns -1.
- Offset libusb reads/writes by length written as well in ztex.
- Cope with timeouts and partial reads in ztex code.
- fpga serial I/O extra debug (disabled by default)

Yes, and it is going to get MUCH worse on the next release as I clean up the queueing to make it as efficient as possible.