Whatever that is, it's something else... Whatever it is... seems to be related to your move to the new phatk kernel. My 6970s on the other hand, like it a lot. Something to do with you mixing cards perhaps? Really no idea offhand

So I worked on fixing bugs only in this quick release, especially with the performance regression in there. Interestingly, 6970s didn't mind at all having the 4K output buffers, but other cards did.

Version 1.5.8 (download links in first post):

- Minimise how much more work can be given in cpu mining threads each interval.
- Make the fail-pause progressively longer each time it fails until the network
recovers.
- Only display the lagging message if we've requested the work earlier.
- Clean up the pool switching to not be dependent on whether the work can roll
or not by setting a lagging flag and then the idle flag.
- Only use one thread to determine if a GPU is sick or well, and make sure to
reset the sick restart attempt time.
- The worksize was unintentionally changed back to 4k by mistake, this caused a
slowdown.

EXECUTIVE SUMMARY:
Pool switching should be fixed, performance should be better. GPU SICK/DEAD confusion should be fixed.

I found some hardware that I can reproduce the slowdown on and have found the offending change. It was actually unintentional. I've pushed the fix to git and it will be in the next version.

Is this built by yourself in linux, a binary in linux, built by yourself in windows, or a binary in windows? If it's the binary in windows, there were some slight differences in the compilation of it. That's the only thing I can think of that was different. The performance is usually only strongly linked to the kernel and not the code within cgminer which makes your results most unusual.

Hmm. The threads are on the same GPU. There is indeed some confusion in the code it seems (i.e. a bug). I've only reproduced this once and a restart made it go away. I'll see if I can fix it next version.

That looks like you've run out of networking capacity to even send anything. Hrm. In this case it might be worth increasing the retry time from 5 seconds to something like 30. -R 30. Meanwhile I'll look at the pool switch code myself as I'm considering getting rid of the 5 minute switch and make it shorter.

No, actually the kernels from 1.5.6 and 1.5.7 should be interchangeable as they take the same arguments and return the same output, provided the filename is changed to suit the release version.

Yes it was just limited to windows, but I've not found any workaround apart from downgrading to 11.6 on linux. All mining software is affected, not just cgminer.

High CPU usage has been plaguing recent driver versions, to the point of increasing CPU usage on linux to match that of the windows driver. On Linux at least, downgrading to the 11.6 driver makes a massive difference to the CPU usage. Some new code in the driver that does busy-waiting to improve throughput on the GPU also causes 100% (of one core) load. It's been annoying the hell out of me and someone else on this forum found the small sacrifice in GPU throughput by downgrading his driver was well worth the massive drop in CPU usage.

Copy the old phatk110816.cl file from 1.5.6 into your 1.5.7 directory and rename it phatk110817.cl (overwriting the new one). Then delete any .bin files created and start again. See if that restores the speed. The kernel may behave differently depending on which core it is.

If it's the first GPU, could be coincidence involving a change to your setup, like having the monitor connected, or the screensaver being enabled that wasn't just a blank screen, or... power supply now failing or... some other random who knows what. Does 1.5.5 still give you the higher rate?

Version 1.5.7 - (links in 1st post as usual)

- Fix a crash with --algo auto
- Test at appropriate target difficulty now.
- Add per-device statics log output with --per-device-stats
- Fix breakage that occurs when 1 or 4 vectors are chosen on new phatk.
- Make rolltime report debug level only now since we check it every work
item.
- Add the ability to enable/disable per-device stats on the fly and match
logging on/off.
- Explicitly tell the compiler to retain the program to minimise the chance of
the zero sized binary errors.
- Add one more instruction to avoid one branch point in the common path in the
cl return code. Although this adds more ALUs overall and more branch points, the
common path code has the same number of ALUs and one less jmp, jmps being more
expensive.
- Explicitly link in ws2_32 on the windows build and update README file on how
to compile successfully on windows.
- Release cl resources should the gpu mining thread abort.
- Attempt to restart a GPU once every minute while it's sick.
- Don't kill off the reinit thread if it fails to init a GPU but returns safely.
- Only declare a GPU dead if there's been no sign of activity from the reinit
thread for 10 mins.
- Never automatically disable any pools but just specify them as idle if they're
unresponsive at startup.
- Use any longpoll available, and don't disable it if switching to a server that
doesn't have it. This allows you to mine solo, yet use the longpoll from a pool
even if the pool is the backup server.
- Display which longpoll failed and don't free the ram for lp_url since it
belongs to the pool hdr path.
- Make the tcp setsockopts unique to linux in the hope it allows freebsd et. al
to compile.

Not yet. The only way currently is to specify multiple config files, each with different pool settings (i.e.: -c 1.cfg -c 2.cfg )

It will generate local work from a failed pool for up to 5 minutes after a pool has gone down. If in that time the pool still hasn't come back up, only then will it switch.

Everyone thinks the feature they want is the killer feature.

Long term output shows how evenly things really are:

@Okama: I wouldn't pay much attention to the rates till much longer has passed. If you get different rates after many hours, check stability of different cards (see mine for how stable the rates can be long term with identical cards).

Not currently, unless you run multiple instances of cgminer, one for each pool, bound to just one GPU.

cgminer -d 0 -o pool1...
cgminer -d 1 -o pool2...
cgminer -d 2 -o pool3...

I have no intention of adding the feature of binding one pool to one gpu as it's a really inefficient way of managing resources in my opinion, and you can get the same effect by running multiple instances of cgminer anyway.

You could try decreasing the stale rate overall by running less threads per GPU with '-g 1'. While it will decrease your mhash slightly, it might be worth the compromise since the share submissions will start happening earlier (since each thread will find shares in less time).

It is supposed to detect the number of CPUs and set it automatically. The only time it does not set number of cpu threads is if it detects any mineable GPU cores. Then it disables CPU mining.

As for hyperthreading, it's a two edged sword. If you set it to the total number of threads, your overall hash rate will be marginally higher (on the order of 15%, but depends on type of CPU) but the efficiency will drop down dramatically because each individual thread will be slower. Also the perceived desktop slowdown will be more dramatic if you use number of threads. Overall, I'd be recommending setting it to number of cores rather than number of threads since then each core can operate most effectively, and be more efficient. Note, however, that there is no reliable cross platform way of determining what's a core and what's a thread. All operating systems return the total number of threads as processors, so by default, auto-detect will give you number of threads.

You can already monitor the output on windows ... just as it describes in the README.txt file. (hint add: 2>log.txt)

The --monitor command allows someone to start an executable automatically with cgminer to act upon the log. That's almost certainly not what you're wanting on windows...