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

[-ck]

Try decreasing --queue to 1 if you start getting more rejects. I'm not sure 2 is better than 1. More testing needed.

[Naven]

Why it is impossible to mine now without supported gpu?

[-ck]

Updated tree:

I've fixed a logic error in the queuing of extra work that would generate more rejects. No new windows binary as yet, sorry.

[burp]

Best results ever, you are surpassing poclbm now
I have a hard time getting rejected shares now

[2011-07-02 14:52:59] [619.41 | 617.64 Mhash/s | eff.: 626.28 Mhash/s] [296 Accepted] [0 Rejected] [0 HW errors]

eff is accepted * 2^32 / (total_time * 1E6)

EDIT: Somehow mining stopped after ca. 400 blocks, I will try again (but it ran with 0 rejected shares!).

[ulee]

If I use minerd on two different GPU's (5830+5770), the second one always produces 100% HW-Errors. This doesn't happen with other mining software.

EDIT: No, not always, can't reproduce it reliably.

[ulee]

Updated tree:

Attribute correct GPU for accepted/rejected shares.
[...]

This doesn't work for me, shares from both GPU's show up with "GPU: 0" at the beginning of the line.

[dc740]

Tried setting 1 gpu thread and 1 cpu thread and got a segmentation fault:

Works:
./minerd --gpu-threads 2 --url --pass --user

Segmentation fault:
./minerd  -a sse2_64 -t 1 --gpu-threads 1 --url --pass --user

Code:

[2011-07-02 11:37:12] Init GPU thread 0
[2011-07-02 11:37:12] List of devices:
[2011-07-02 11:37:12] 	0	GeForce 8600 GT
[2011-07-02 11:37:12] Selected 0: GeForce 8600 GT
[2011-07-02 11:37:23] Initialising kernel poclbm.cl without BFI_INT patching, 1 vectors and worksize 512
[2011-07-02 11:37:32] initCl() finished. Found GeForce 8600 GT
[2011-07-02 11:37:32] 1 gpu miner threads started
[2011-07-02 11:37:32] 1 cpu miner threads started, using SHA256 'sse2_64' algorithm.
[2011-07-02 11:37:34] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
*** glibc detected *** ./minerd: corrupted double-linked list: 0x00007f8bb4586020 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x76bb6)[0x7f8bbf21fbb6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7a931)[0x7f8bbf223931]
/lib/x86_64-linux-gnu/libc.so.6(+0x7b112)[0x7f8bbf224112]
/lib/x86_64-linux-gnu/libc.so.6(realloc+0xf9)[0x7f8bbf225b19]
./minerd[0x420610]
./minerd[0x41f44d]
./minerd[0x41fd5e]
./minerd[0x41fd69]
./minerd[0x42013e]
./minerd[0x405fd5]
./minerd[0x403229]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6d8c)[0x7f8bbf748d8c]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f8bbf28f04d]

BTW... the help lists -g as a valid option to set gpu threads, but if you use -g 1 it says it's invalid.

[-ck]

Sorry for some reason short options and invalid options are broken at the moment. Please use the long option names.

[burp]

OK, I can confirm my previous result that somehow mining for one or multiple GPUs just stops. There is no indication of a crash, and no overheating possible. I can just restart minerd for normal operation.

[2011-07-03 12:18:58] [310.07 | 391.56 Mhash/s | eff.: 385.04 Mhash/s] [4016 Accepted] [3 Rejected] [0 HW errors]

Code:

[2011-07-03 03:11:53] GPU: 0  Accepted: 830  Rejected: 2  HW errors: 0
[2011-07-03 03:11:56] [618.30 | 617.98 Mhash/s | eff.: 582.11 Mhash/s] [1623 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:01] [619.46 | 617.98 Mhash/s | eff.: 581.87 Mhash/s] [1623 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:03] GPU: 0  Accepted: 831  Rejected: 2  HW errors: 0
[2011-07-03 03:12:06] [617.86 | 617.98 Mhash/s | eff.: 581.98 Mhash/s] [1624 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:07] GPU: 1  Accepted: 794  Rejected: 0  HW errors: 0
[2011-07-03 03:12:12] [435.91 | 617.85 Mhash/s | eff.: 582.07 Mhash/s] [1625 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:17] [390.26 | 617.72 Mhash/s | eff.: 581.82 Mhash/s] [1625 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:22] GPU: 1  Accepted: 795  Rejected: 0  HW errors: 0
[2011-07-03 03:12:22] [346.60 | 617.58 Mhash/s | eff.: 581.93 Mhash/s] [1626 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:27] [329.83 | 617.46 Mhash/s | eff.: 581.69 Mhash/s] [1626 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:32] [318.97 | 617.33 Mhash/s | eff.: 581.45 Mhash/s] [1626 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:34] GPU: 1  Accepted: 796  Rejected: 0  HW errors: 0
[2011-07-03 03:12:37] [313.34 | 617.20 Mhash/s | eff.: 581.56 Mhash/s] [1627 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:42] [308.59 | 617.07 Mhash/s | eff.: 581.32 Mhash/s] [1627 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:47] [309.94 | 616.94 Mhash/s | eff.: 581.07 Mhash/s] [1627 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:52] GPU: 1  Accepted: 797  Rejected: 0  HW errors: 0
[2011-07-03 03:12:52] [309.93 | 616.81 Mhash/s | eff.: 581.19 Mhash/s] [1628 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:12:57] [309.95 | 616.68 Mhash/s | eff.: 580.94 Mhash/s] [1628 Accepted] [2 Rejected] [0 HW errors]
[2011-07-03 03:13:03] [306.25 | 616.55 Mhash/s | eff.: 580.70 Mhash/s] [1628 Accepted] [2 Rejected] [0 HW errors]

[-ck]

Yeah thanks. There is likely a logic error in the queueing of extra requests. I'm currently completely rewriting all that to preemptively request work before it's needed to help cope with dodgy network connectivity and other goodies. Actually it's complete but I'm testing it before pushing it.

[-ck]

Updated tree and windows binary:

After an extensive period of poor connectivity with my pool I decided to make minerd much more robust with respect to networking and caching of work items. I modified to code to find when a worker thread is 2/3 of the way through completing that search and will then queue a new work request in advance at that point. This allows getting work over slow or intermittent connections asynchronously from the worker thread without having to have a large buffer of increasingly stale work. Then I added code to flush out all the old items of work when a longpoll is detected -and- queue a whole new set of work for each and every thread in advance since they'll all need new work. I've also updated the cpumining code to properly work to the end of a work item (and not be counted as inefficient mining), and made some of the log updates more robust. Minerd should cope better with spotty connections under periods of server stress now, and rejects across longpolls should be rarer.

New windows binary:
http://ck.kolivas.org/apps/cpuminer-ycros-2011-07-04.zip

Known bugs:
It does not work with short options (only --long time options), and will crash with invalid options.
Sometimes there's a crash deep within libcurl that looks like this:
*** longjmp causes uninitialized stack frame ***
This happens deep within the libcurl code and appears to be not related to minerd at all. The only thing it seems I can do about it is move to a different library. This is the only recurring problem and because of it I put minerd to auto-restart for myself though it's quite rare (sometimes happens immediately on starting on windows).

[Tartarus]

With 17faaea and a local network interrupt (I think anyhow, VoIP call hung-up, ssh/etc stuff recovered fine) minerd stopped getting new work or doing anything else on the network for at least 5 minutes (then I ^C'd it).  Retry was the default value.

[ulee]

I tried this ↑ new version of minerd, but I still get 100% HW-Errors on my second GPU.  
This bug doesn't occur with an old Version of minerd.

[jgarzik]

New windows binary:
http://ck.kolivas.org/apps/cpuminer-ycros-2011-07-04.zip

Can you change the name to something other than the now-misleading "cpuminer"?

[-ck]

I tried this ↑ new version of minerd, but I still get 100% HW-Errors on my second GPU.  
This bug doesn't occur with an old Version of minerd.

What does the output look like with -D until it has started getting HW errors?

[ulee]

What does the output look like with -D until it has started getting HW errors?

Output from minerd
I didn't set --queue, --gpu-threads or --intensity, so these were at default values.
These lines look interesting:

Code:

[2011-07-04 01:42:48] GPU 1 found something?
[2011-07-04 01:42:48] No best_g found! Error in OpenCL code?

This only happens with the last few versions of of minerd, an older version (before your "What next..." post) worked fine with both GPUs. Unfortunately I don't know at which exact version it stopped working.

[-ck]

What does the output look like with -D until it has started getting HW errors?

Output from minerd
I didn't set --queue, --gpu-threads or --intensity, so these were at default values.
These lines look interesting:

Code:

[2011-07-04 01:42:48] GPU 1 found something?
[2011-07-04 01:42:48] No best_g found! Error in OpenCL code?

This only happens with the last few versions of of minerd, an older version (before your "What next..." post) worked fine with both GPUs. Unfortunately I don't know at which exact version it stopped working.

Thanks. I'm pretty sure I know what that is. The different cards need different kernels and they're both loading the same binary. I'll get to fixing that.

[-ck]

New windows binary:
http://ck.kolivas.org/apps/cpuminer-ycros-2011-07-04.zip

Can you change the name to something other than the now-misleading "cpuminer"?

I'll get around to it sooner or later. Trying to consolidate everything now to make sure it's all actually working :s

[-ck]

Thanks. I'm pretty sure I know what that is. The different cards need different kernels and they're both loading the same binary. I'll get to fixing that.

Updated tree: The binary kernel stored now includes the GPU name in the filename. This will allow separate binary kernels to be saved for each unique GPU type on the same machine which should fix this problem.

[-ck]

Updated tree:

I put a careful counter on the number of queued items to ensure we don't fall between the cracks during an updated block and clearing of work that we end up without any work and one ore more threads idle. Also, since minerd now pre-queues work before the previous work is finished, there is no need to have extra queued work by default, so I've changed the default queue value to 0 and made it mean extra queued work instead.