cgminer - CPU/GPU miner in C for linux/windows

[bumbox]

There is a problem with worksize autodetection on nvidia gtx 570. By default it is autodetected as 1024 but that leads to segfault:

Code:

./minerd --userpass xxx:xxx --url http://xxxxxx:8332/
[2011-06-29 02:51:01] Init GPU thread 0
[2011-06-29 02:51:01] List of devices:
[2011-06-29 02:51:01]   0       GeForce GTX 570
[2011-06-29 02:51:01] Selected 0: GeForce GTX 570
[2011-06-29 02:51:18] Initialising kernel poclbm.cl without BFI_INT patching, 1 vectors and worksize 1024
[2011-06-29 02:51:18] initCl() finished. Found GeForce GTX 570
[2011-06-29 02:51:18] Init GPU thread 1
[2011-06-29 02:51:18] List of devices:
[2011-06-29 02:51:18]   0       GeForce GTX 570
[2011-06-29 02:51:18] Selected 0: GeForce GTX 570
[2011-06-29 02:51:18] Long-polling activated for http://xxxxx:8332/LP
Segmentation fault

If I set worksize 512 or less it works fine:

Code:

./minerd --userpass xxx:xxx --url http://xxxx:8332/ --worksize 512
[2011-06-29 02:53:56] Init GPU thread 0
[2011-06-29 02:53:56] List of devices:
[2011-06-29 02:53:56]   0       GeForce GTX 570
[2011-06-29 02:53:56] Selected 0: GeForce GTX 570
[2011-06-29 02:54:12] Initialising kernel poclbm.cl without BFI_INT patching, 1 vectors and worksize 512
[2011-06-29 02:54:12] initCl() finished. Found GeForce GTX 570
[2011-06-29 02:54:12] Init GPU thread 1
[2011-06-29 02:54:12] List of devices:
[2011-06-29 02:54:12]   0       GeForce GTX 570
[2011-06-29 02:54:12] Selected 0: GeForce GTX 570
[2011-06-29 02:54:12] Long-polling activated for http://xxxxxx:8332/LP
[2011-06-29 02:54:13] [3.27 | 3.27 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-29 02:54:18] [70.47 | 18.51 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-29 02:54:23] [89.52 | 31.64 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-29 02:54:28] [69.74 | 37.58 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-29 02:54:33] [69.03 | 41.83 Mhash/s] [0 Accepted] [0 Rejected]
...

[gat3way]

Well then welcome to the wonderful world of experimental programming and cursing AMD and Nvidia

It's a lot of fun though GPGPU stuff is among the most interesting things I've got into for sure.

[bumbox]

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

Please add : after //, broken link

[-ck]

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

[bumbox]

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

Well, I understand that nvidia is not the best hardware for mining but anyway could I somehow help in resolving this bug? Maybe some additional information or debug data are needed?

[-ck]

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.

[gat3way]

clGetDeviceInfo() tends to return BS sometimes Anyway, I don't think using the maximum allowed worksize is optimal as you are resource-constrained anyway. Bad thing is that it is hard to determine the optimum without experimenting with the workgroup size (starting from 32 on nvidia all the way to 512 in multiples of 32).

[-ck]

clGetDeviceInfo() tends to return BS sometimes Anyway, I don't think using the maximum allowed worksize is optimal as you are resource-constrained anyway. Bad thing is that it is hard to determine the optimum without experimenting with the workgroup size (starting from 32 on nvidia all the way to 512 in multiples of 32).

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.

[Naven]

Any ideas how to compile that static?

Code:

CFLAGS="-O3 -static -Wall -msse2 -I/usr/include/nvidia-current/" ./configure

Gives me next error:

Code:

checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.21.3
checking for libcurl >= version 7.10.1... yes
checking whether libcurl is usable... no
configure: error: Missing required libcurl >= 7.10.1

Code:

# apt-cache policy libcurl4-gnutls-dev 
libcurl4-gnutls-dev:
  Installed: 7.21.3-1ubuntu1.2

[figvam]

The last version with poclbm kernel and intensity=3 gives me 25.1 Mh/sec - already very close to the baseline 29.5 Mh/s of other miners! Higher intensity doesn't increase the hash rate much but slows down the desktop alot.

[theowalpott]

Any ideas how to compile that static?

Code:

CFLAGS="-O3 -static -Wall -msse2 -I/usr/include/nvidia-current/" ./configure

Gives me next error:

Code:

checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.21.3
checking for libcurl >= version 7.10.1... yes
checking whether libcurl is usable... no
configure: error: Missing required libcurl >= 7.10.1

Code:

# apt-cache policy libcurl4-gnutls-dev 
libcurl4-gnutls-dev:
  Installed: 7.21.3-1ubuntu1.2

try sudo apt-get-install libcurl4-openssl-dev

had this issue yesterday and it seemed to work with that package installed, rather than the other libcurl4 types.

[Naven]

i tried with openssl-dev, nss-dev and also with curl from http://curl.haxx.se/download.html.
Everything works when i build minerd dynamic, but static dont wanna be so polite

[bumbox]

Recent git version works fine on nvidia. Thanks! Good job!

One more thing. I do not exactly understand how bitcoin generation works but I have noticed the following thing.

oclHashCat-lite (http://www.hashcat.net/oclhashcat-lite/) gives me about ~290M/hash sha256 password bruteforce speed but gpumine only ~120M/hash. Are there any differences with sha256 password bruteforce and bitcoin mining process?
Maybe is it possible to improve the gpumine using kernels from hashcat?

here is the way I start hashcat:

Code:

./cudaHashcat-lite64.bin -m 1400 762d689acf34b57c52be4fad090626d4f44d3cfd83bbd2cceb4526bd95c54551
...
Hash.Type....: SHA256
Speed........:  292.6M/s

Of course I've tried to play with gpumine parameters like threads, intensity, worksize and vectors and was unable to increase the mining speed significantly.

[bumbox]

i tried with openssl-dev, nss-dev and also with curl from http://curl.haxx.se/download.html.
Everything works when i build minerd dynamic, but static dont wanna be so polite

I have the same problem with static linking. Even tried to compile curl from curl.haxx.se manually. But still no luck.

[-ck]

i tried with openssl-dev, nss-dev and also with curl from http://curl.haxx.se/download.html.
Everything works when i build minerd dynamic, but static dont wanna be so polite

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

[-ck]

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.

[Tartarus]

FYI I'm seeing an odd error (and will try and track it down later in the day if I can) where short-opts are ignored and -n/--ndevs just returns the help message.

[gat3way]

Hm, that's rather strange. I actually ship binaries statically linked with curl. However I disabled SSL support in curl as well as support for some unneeded protocols and compiled it myself. It's quite possible until you need SSL support. My attempts to build curl statically linked with libssl and libcrypto then build hashkill statically linked with curl failed as well.

[-ck]

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...

[-ck]

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.