Updated tree:

I put a lot more effort into avoiding rejected blocks. I've reworked the get work code to not require locking and to be flagged itself if longpoll has notified us of a new block. If that happens it will discard and queued work. It also now stores the current block's header once it's known, and on block submission it compares the result being submitted and if it belongs to an older block it will discard it instead of trying to upload it. With these accumulated changes, the block reject rate is lower than ever.

Cause I'm hopeless with asm. Happy to include it if someone can port the 32 bit assembly to something more portable.

Updated tree:

Fixed the high stale block rate. Now it should be equivalent to other miners unless you set the intensity absurdly high.

Updated tree:

The work submission and get work was done from the same "curl" and one would block the other. This would mean that delays on one would delay the other and could slow down processing unnecessarily. While trying to split them into different threads I discovered they would crash on using the same curl so each component has its own thread and own curl now. This should make it much less likely that stalls occur due to poor network connectivity. The separate curl instances may also fix other bugs (like the infinite rejects loop).

I've debugged the binary kernel loading and re-instated it. Now it should be much faster to begin after the first time it is started as it will generate an appropriate binary and then load it thereafter.

Still todo:
I'd like to use the block information received to tell submission threads to not both submitting queued stale blocks after longpoll has informed it of a change.
Find other ways of decreasing stale block rate.
Increase throughput (pipedream).
Start looking at cleaning things up for better building, configuration, windows builds and so on, to perhaps make a real release version.
Lots of other things... but sleep first zzzzz....

The code doesn't support make install yet... You have to run it from the directory where it's built for now. And you happened to try it at an unfortunately quite unstable development time. I'm working very hard at fixing the instability right now.

No worries, bear in mind this is still all new code and maturing.

Keep going down, or try dropping gpu threads to 1 ?

There are a few reasons for this. The reject rate goes up if you set the intensity too high on minerd because it can literally take 10 seconds before the gpu returns its results from one single request at high levels! In that time the blocks can get stale. Also, setting the number of gpu threads high basically slows down how long each request takes as well (the purpose for multiple threads is to make sure the gpu remains busy). Finally, some stale blocks are still sneaking through when a new block is detected. I'm working on all of these issues to try and minimise them, but for the time being, you may find less stale blocks with an intensity around 8-9, and the rate doesn't really go up substantially at higher levels anyway.

Yeah thanks. It's killing me trying to figure out / instrument that as well since it happens only after a long time. There is also a bug with cpu mining at the moment where block submission can cause a segfault. I spent hours and hours coding today and threw out heaps of code. Oh well, there are days like this.

Thanks to the other anonymous donor! If you make a donation and want a specific feature, feel free to drop me a line when you donate and I'll see if I can do it.

I've temporarily backed out the binary loading of kernels till I get it working properly everywhere. A couple of potential fixes have also been committed that could have caused segfaults due to memory dereferencing. It should be stable again but I still have more stuff I want to do...

Temporary breakage... hold on please...

Updated tree:

Build binaries with unique filenames from the kernel generated and save them. Try to load this cached binary if it matches on next kernel instantiation. This speeds up start-up dramatically, and has a unique kernel binary for different kernel configurations.

Thanks very much to those donating. Even tiny donations are most appreciated.

About the libcurl static thing, I had read this elsewhere, I have no real experience in the area, so there may be only some aspects of networking that cannot be compiled statically. What they are, I don't know.

I'll check out the options parsing eventually, as I do see the problem you're reporting.

There appears to be a bug where it starts rejecting all blocks after an extended period, somewhere in the order of ~2500 accepted blocks. I'm trying to investigate why that is, but it's rather hard to reproduce on my slower equipment

More improvements to come...

Updated tree:

I put some effort into minimising the risk of rejects and cl errors and to not miss shares close to each other. I did this by creating an array for the buffer variables passed to and from the GPU to make it extremely unlikely for a race to occur over the same slot in the array. Then I scan over the entire array when it is flagged as a match being found, but it's scanned in a separate thread to not delay further work being passed to the GPU. This change should allow you to use the higher values for intensity without it increasing the reject or error rate.

In the interim I discovered a nice bug whereby there was a chance the struct with the thread id had its memory freed before an attempt was made to detach the thread with pthread_detach which would lead to a segfault.

You can't build a truly static build of something that sends or receives network packets, sorry.

No of course not. I use max work size / vectors. That works surprisingly well as a default starting setting when none are chosen

So is anyone actually finding this client useful? It's getting quite mature now but apart from Burp's feedback I don't really get a sense that anyone's finding it useful. I find a huge improvement in throughput from it at intensity levels that don't affect my desktop.

Updated tree

I've modified the log to only show the summary and not the testing information unless in debug mode. There are now counters stored to say which gpu or cpu found the share, and hw errors are stored as well. The added information can be used to determine whether to turn down intensity or to overclock less.

The output looks like this now:

[2011-06-29 10:46:19] GPU: 0 Accepted: 100 Rejected: 4 HW errors: 0
[2011-06-29 10:46:24] [230.23 | 218.86 Mhash/s] [105 Accepted] [4 Rejected] [0 HW errors]
[2011-06-29 10:46:29] [227.39 | 218.88 Mhash/s] [105 Accepted] [4 Rejected] [0 HW errors]
[2011-06-29 10:46:34] [218.19 | 218.88 Mhash/s] [105 Accepted] [4 Rejected] [0 HW errors]
[2011-06-29 10:46:40] [239.39 | 218.94 Mhash/s] [105 Accepted] [4 Rejected] [0 HW errors]
[2011-06-29 10:46:45] [230.92 | 218.97 Mhash/s] [105 Accepted] [4 Rejected] [0 HW errors]
[2011-06-29 10:46:45] GPU: 0 Accepted: 101 Rejected: 4 HW errors: 0

Also I've updated the code to not allow automatically setting work sizes greater than 512 as a simple way of preventing the nvidia bug mentioned earlier.

EDIT: I've also made the 1st rate reported (the log interval one) a decaying average so it doesn't jump around as much.

Thanks and thanks. I wondered why they returned 1024. Looks like more phayl from nvidia with opencl

Actually I'm very new to opencl and bitcoin. Just started a week ago, and had to learn all about opencl. I've put in over a hundred hours on this code already  to get up to speed

To see what I'm doing with linux kernel, check out http://ck-hack.blogspot.com

Not rude at all. Yes it is me and I still do