Nice, I'll give that a shot. So, the second -o/u/p set is not used at all unless the first is down? Will it automatically failback to the original? Can you have a third or fourth set as well?

Just wondering

You can have as many as you like, and it will trickle work to the 2nd and 3rd when the 1st is relatively slow, or fail over completely to the 2nd when the 1st dies. Alternatively you can change the pool strategy to load balance where it shares work between all of them, etc... check the readme or top post in this forum. Also you can do all of this live while it's running just by pressing P and checking the options.

Funroll_Loops, the theoretically quicker breakfast cereal!Check out http://www.facebook.com/JupiterICT for all of your computing needs. If you need it, we can get it. We have solutions for your computing conundrums. BTC accepted! 12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq

Current 110810 kernel on git has 1368 ALU OPs for 58XX and 1696 for 69XX, that's neither phatk 2.2 nor my latest result (which is 1364 / 1688), but a bit faster than the last official CGMINER kernel. I mailed my latest version to Con for review .

The added __attribute__((vec_type_hint(u))) is unknown to the compiler and throws a warning, but IS mentioned in the OpenCL 1.1 manual ... strange.

Dia

Correct, it's not 2.2, nor your most recent. It was an honest attempt at integrating *both* of them, but I think now that I missed a few things.

I had noticed the Kernel Analyzer threw an error about vec_type_hint, but it compiles without issue on linux. I don't have native windows (only virtualized) to test anything there. In testing, I was unsure as to whether vec_type_hint made an improvement, but I was certain that it wasn't the opposite.

After running it for a while on my 6970s, I find even this change is of no benefit either It's ever so slightly slower it appears. Not sure what to do now about all this.

After running it for a while on my 6970s, I find even this change is of no benefit either It's ever so slightly slower it appears. Not sure what to do now about all this.

I'll just be quiet and go back in my hole for a bit. :/

Don't be disheartened. I'm forever hacking up code and then deleting it. You wouldn't believe how much code I've thrown out so far working on cgminer. Not every experiment is successful.

I'll attest to that. I've fiddled around with the SSE4 code for what seemed like endless nights increasing and decreasing hash rates and came to realize the my second to the last post had the best hashing rate and that my last was slower than the original. But I'm curious to see if we'll ever come up with something that uses the CPU and GPU together in the same calculations via the math library I posted earlier. It'll be interesting to see what comes out of it.I'm still trying to figure out how to specify compiler options for cl code. I was going to test out the unsafe math optimization and see what comes out of it. There are actually quite a few optimizations to play around with for speeding up memory transfers via non-temporal writes, increasing data size, prefetching, using the differences between the initial constants instead of the actual values to shrink the table, etc.It's really like trying to solve a puzzle with many different answers. Only, you're trying to solve it better than anyone else has already.

Funroll_Loops, the theoretically quicker breakfast cereal!Check out http://www.facebook.com/JupiterICT for all of your computing needs. If you need it, we can get it. We have solutions for your computing conundrums. BTC accepted! 12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq

In experimenting with bitpenny and p2pool which both set work unit target difficulty to something other than 1, it is apparent that cgminer does not honor the target that is include in the getwork response and instead submits every share that passes difficulty 1 even if the actual target difficulty is higher. For example, on bitpenny, shares are all difficulty 8. This leads to most shares being rejected because they are not valid difficulty 8 shares. In the grand scheme of things, this doesn't hurt anything, except it makes the stats and output of cgminer fairly broken because the reject rate is very high and the log is filled with mostly rejected invalid shares.

I understand that the kernels appear to return any share that looks like it passes the difficulty 1 target. Instead of changing the kernels (which probably would slow them down), you could just double-check the returned hash to see if it is truely valid before submitting it. This appears to be what phoenix and the latest version of luke's (and maybe the mainline) poclbm do.

Summary: cgminer should now use the backup pools much less frequently, should drop in performance on a longpoll much less, communicate with the server less, have higher efficiency, and hopefully have less problems with dying GPUs. It also supports the --monitor command (linux only at this stage).

Full Changelog:

- Add new option: --monitor <cmd> Option lets user specify a command <cmd> thatwill get forked by cgminer on startup. cgminer's stderr output subsequently getspiped directly to this command.- Allocate work from one function to be able to initialise variables addedlater.- Add missing fflush(stdout) for --ndevs and conclusion summary.- Preinitialise the devices only once on startup.- Move the non cl_ variables into the cgpu info struct to allow creating a newcl state on reinit, preserving known GPU variables.- Create a new context from scratch in initCQ in case something was corrupted tomaximise our chance of succesfully creating a new worker thread. Hopefully thismakes thread restart on GPU failure more reliable, without hanging everythingin the case of a completely wedged GPU.- Display last initialised time in gpu management info, to know if a GPU hasbeen re-initialised.- When pinging a sick cpu, flush finish and then ping it in a separate thread inthe hope it recovers without needing a restart, but without blocking codeelsewhere.- Only consider a pool lagging if we actually need the work and we have nonestaged despite queue requests stacking up. This decreases significantly theamount of work that leaks to the backup pools.- The can_roll function fails inappropriately in stale_work.- Only put the message that a pool is down if not pinging it every minute. Thisprevents cgminer from saying pool down at 1 minute intervals unless in debugmode.- Free all work in one place allowing us to perform actions on it in the future.- Remove the extra shift in the output code which was of dubious benefit. Infact in cgminer's implementation, removing this caused a miniscule speedup.- Test each work item to see if it can be rolled instead of per-pool and rollwhenever possible, adhering to the 60 second timeout. This makes the periodafter a longpoll have smaller dips in throughput, as well as requiring lessgetworks overall thus increasing efficiency.- Stick to rolling only work from the current pool unless we're in load balancemode or lagging to avoid aggressive rolling imitating load balancing.- If a work item has had any mining done on it, don't consider it discardedwork.

What version of cgminer are you testing that does that? Because that's precisely what it does in submit_nonce:

/* Do one last check before attempting to submit the work */ if (!fulltest(work->data + 64, work->target)) return true;

Or am I missing something

Sorry, I am still on 1.4.something. I avoided 1.5.x because of the several reports of problems with it and because you were out of town. I'll try that now.

"forrestv" just informed me the fulltest function was disabled due to endian issues (I think) in the original cpuminer code that cgminer grew out of. Since cgminer pretty much only builds on little endian machines now anyway, it has been re-enabled, but only in the git tree. So this test is not active yet in the current release (1.5.4).