I really don't see anything obvious and tried building it from scratch again with a fresh tarball and have no problem. Are you building from git or tarball? If from git, are you running ./autogen.sh first?

That's perfectly normal, as you are submitting less shares at higher difficulty. That's precisely why there's a WU column instead to compare and they're about the same within margin for normal variance over that time frame. Note they're *all* supposed to be variable difficulty by now as you can see since your U and WU  don't match, displaying that.

No?

New release - Version 2.7.6, 24th September 2012

In anticipation of more instability once I start implementing the stratum protocol, I have released this updated version with only safe changes that can be relied upon to be stable.


Human readable changelog:

Should have finally fixed the "dynamic intensity gets stuck at a low value" bug.
Build will detect default SDK installation on linux now that AMD SDK 2.7 exports variables defining it.
Fixed the disabled/enabled/disabled thread when changing to dynamic intensity
The share hash display has been compacted further and the difficulty is now shown in anticipation of many pools moving to variable difficulty shares.
If a pool's server was alive but not returning work cgminer could have bombarded it with requests instead of failing.
Lots of goodies thanks to Kano who was working hard while I was away; I'll let him elaborate next post


Full changelog:

- Display share difficulty on log with a shortened hash display on submission.
- API stats add some pool getwork difficulty stats
- Ignore any pings pushed to the worker threads if the thread is still paused to
prevent it being enabled and disabled repeatedly.
- README - FAQ - usermod group - shouldn't remove other groups
- Test for sequential getwork failures on a pool that might actually be up but
failing to deliver work as we may end up hammering it repeatedly by mistake.
- reduce windows compile warnings
- util.c - bug - proxy - no data end condition
- As we average gpu time over 5 work intervals for dynamic GPU intensity, there
is no need to maintain a rolling average and it avoids the potential long term
corruption of a single overflow value.
- Test for the now-automatically exported variable AMDAPPSDKROOT when looking
for the presence of the OpenCL headers.
- API don't change 'Diff1 Shares' - backward compatability FTW
- miner.php highlighting correctly handling difficulty
- API - Add last share difficulty for devices and pool
- Store and report Accepted,Rejected,Stale difficulty in the summary and API
- WorkTime - display prevblock for scrypt
- api.c remove compile warnings
- Calculate work difficulty for each getwork and display with WorkTime debug
- remove MMQ unused variable warning
- FPGA - allow long or short device names in detect code + style police
- WorkTime - multiple nonce per work and identify the work source
- Optional WorkTime details with each Accepted/Rejected work item
- Icarus - ignore hardware errors in timing mode
- miner.php oops - mistype
- miner.php by default don't display IP/Port numbers in error messages
- api.c all STATUS messages automatically escaped
- api.c add missing escape for comma in MSG_PGAUNW
- API add display of and setting queue,scantime,expiry
- HW: dont submit bad shares
- save individual pool proxy settings to config
- --default-config - allow command line to define the default configuration file
for loading and saving
- API-README update for pools proxy info
- README URL proxy must use quote so show in the example
- bug: remove proxy: from the front of the proxy used
- CURL support for individual proxy per pool and all proxy types
- README spelling/etc
- README - FPGA device FAQ
- HW: error counter auto for all devices - ztex code not fixed
- API pgaidentify - unsupported message should be a warning
- API/BFL identify a device - currently only BFL to flash the led
- BFL add throttle count to internal stats + API
- BFL: missing device id in log message
- miner.php correct to new Diff1 Work field names
- API add device diff1 work
- API-README update
- api.c Correct diff1 field name
- count device diff1 shares
- API-README more debug parameter information
- API allow full debug settings control

If you use cgminer and set solo mining as your first pool and set up a real pool which has longpoll as your 2nd pool, cgminer will use the longpoll from the backup pool to help speed up block change on the solo mining.

Probably haven't loaded the module for the bitforce devices.

BAMT has no support for later versions of cgminer and they've officially dropped support for it I believe in the next version.

Since you went to the effort of really trying hard and providing lots of info, I will try my best to decipher what your problem may be. Fortunately it's a little bit more than "dunno" but not certain.

AMD/ATI in their usual wisdom decided that their SDK version number would tell you nothing about what fucking version it actually is. They did the same with the driver and the SDK

You have
Which from memory is the pre-release of SDK 2.6 that came with the december 2011 driver (11.12). 2.6 SDK is the minimum required to do scrypt mining.

"curses" is the software component that gives you the running menu and "header" as you called it, and it's never getting to that stage.

The one thing about your setup that may be the cause of your problem is this:
I have a suspicion that the scrypt kernel may not even run on that particular hardware in any form with the settings you are choosing.

This is what makes me suspicious:
You'll see that GPU1 never actually gets going. There's a good chance the code just gets stuck waiting for this device to respond and it never happens, and meanwhile the rest is already underway with GPU0.

I doubt a driver update will do anything for you, but I suggest you try mining with just GPU0 by adding something like
(edited was -D 0 but meant to be -d 0)
and see if that gets it going. There's a good chance that GPU1 will be so bad at scrypt mining even if you do get it working that it's not worth it.

Slush, Eleuthria, glad to see you agreed on and developed a nice protocol for the future. I've been swamped by real life issues for a while now, but I will look to implementing native cgminer support when time permits which will hopefully be soon.

Heh, the more things change, the more they stay the same   Nuff said.

Anyway unfortunately for some (one?), I'm not dead and was not going to abandon cgminer, but family comes first. Things are still bad there but I'm finding my feet again.

I'll look at the stratum protocol at some stage soon.

This is a quick heads up to tell you all that I'll be taking a brief break from development and support for cgminer due to a family tragedy. I will not be receiving notifications from the forum nor checking on messages for a little while, so please use the resources of the many other helpful people on these forums. Thanks.

No one said to start bitcoin mining with nvidia hardware. The nvidia hardware is pretty much useless till specific workloads that suits it comes around (and I finish the code to make the most of it). At no stage will nvidia hardware suddenly become profitable to bitcoin mine with. On the other hand, there may come a time when the ATI cards are no longer profitable to use (should ASICs really hit at the their target performance and timeframe), and that's what this current guarantee is - to extend that useful lifetime beyond.

Nothing would stop you at the moment because you can mine with any client for now. In the future when you will only be able to use the coinlab client, you will be limited to GPU only.

I bet you're loading *2* configuration files...

1. no

2. because the dyn interval timing means something when only 1 thread is running otherwise they overlap ... if you want high throughput increase the interval

3. it shouldn't...

Set an intensity

No.

If you get a pause of no accepted shares before longpoll followed by big run of stales after a longpoll that is delays with your pool that is holding off processing the last shares and taking its time to get the longpoll out. I see this with mtred which struggles under the load, but not with other pools.

I don't really think there's much point even trying to work it out on a reward basis... People running cgminer will be able to see how much variance affects them by comparing their WU (work utility which is based on diff 1 share production) versus their true U (utility which is based on successful target shares submitted). Having said that, I think this is getting too complicated for most people already and I'd rather see the pool take care of the difficulty setting based on hashrate myself...

Intensity 9, worksize 128  (default), gpu memdiff -125