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

[rb2k]

first of all: wow, I think it's awesome to see ckolivas here! Loved your BFS work

Just a short question about the statistics:

Code:

GPU 0: [360.6 Mh/s] [Q:22  A:23  R:0  HW:3841  E:105%  U:5.28/m]

What are the HW and E parameters?

[1714885850]

1714885850

[1714885850]

1714885850

[1714885850]

1714885850

[kripz]

ncurses is sexy when it works... with debug, intensity 8 and 2 cards at about 600mhash i get corruption all over the screen via ssh. Lines dissapear, reappear, all weird stuff.

Also,

With my 5770 ~180mhash/s i get 100% efficiency, this is for like 3000 shares. With 2 5850 at about 600mhash/s i get like 80% over about 2000 shares. Is there a reason for this?

Even with a short test i get the same result every time.

Code:

cgminer version 1.2.0
--------------------------------------------------------------------------------
Totals: [(5s):188.4  (avg):185.8 Mh/s] [Q:10  A:8  R:0  HW:1  E:80%  U:2.47/m]

GPU 0: [186.7 Mh/s] [Q:10  A:8  R:0  HW:1  E:100%  U:2.87/m]

With my 6970 i get

q: 44 a:36 r:2 e: 82%

The higher the hash rate the lower the efficiency.

I'm adding a third card to my 5850 machine so i expect the eff to be even lower, ill post back with results. Could just be confirmation bias or something (prob heat ).

EDIT:

5850 machine crashed, this is all i could get.

Code:

7-111-07-11 18:57:26] Failed json_rpc_call in get_upstream_work
[201 [18:250171:-072-6] 1j1 1s8:o57n:_rp2c6] _jcaslon_lrpc _caflalil ed foailend o ns suubbmimt_iwortk_, wroetrryk,  aftreetrry 1  safteeconrd s1 [ecKonds2011-07-11 18:57:29] submit_upstream_work json_rpc_call failed
20111-07-11 18:57:29] submit_upstream_work json_rpc_call failed
[201-07-[11 2108:517:216-07]- js1o1 1n8:5_7:2r6pc_]c jsaolnl_ faripc_lced aon lsublm faiit_wlorke,d  oretnr syu afbtmite_r 1w orks,eco nretdrsy aftr 1[ seKconds7-11 18:57:29] json_rpc_call failed on submit_work, retry after 1 seconds
7-111-07-11 18:57:29] Failed json_rpc_call in get_upstream_work
[201 1[8201:15-70:7-216]1  Fai1l8:5e7d j:s26]o nFa_irpcl_ecadll  in jgsone_t_urppc_sctreaall min_ worgket_uptr[eKam_work
7-111-07-11 18:57:31] [Rate (5s):0.0  (avg):485.16 Mhash/s] [Requested:229  Accepted:185  Rejected:13  HW errors:0  Efficiency:81%  Utility:5.89/m]
 --1 1[82:570:11-206] 7j-1s1on_ r18:p5c_c7a:26l]l f ajsoinled_ rpocn ge_t cwaoll rfk, arileedt onr yget  aftweorrk , 1r seetconrdys aftr [1 Kseconds
07-11-
   1[1201 1-017-811: 518:757::292]9]  subsmubmiit_utps_tuprseamt_reawmork_ jswoorkn _jsropn_rcpc__ccaalll lf ailfeailded

[2[02110-071-1-101 178-:5171 1:829]: 57:s2ubm9i] stu_upbsmitt_reaumpst_rworekam_ wjsoonrk _jsorn_rppc_ccal_l fcaalli ledfail[Kd
[
 2011-07-1[Segmentation fault

dmesg

Code:

[   23.564791] eth0: no IPv6 routers present
[29222.255373] cgminer[18711]: segfault at 1a4 ip b77a6ad6 sp a9d15050 error 4 in libncurses.so.5.9[b778a000+36000]

Time to add third card while it's down

[-ck]

Wow kripz you got all the luck.

I guess I never really tested debug output very well. All in good time

As for the efficiency, I did notice a slight trend towards lower efficiency with more Mhash but I have one machine with a 5770 (~200MH) and another machine with 4x6970 (~1700MH) and they're both running to within 3% of the same efficiency after 10,000 shares on the big box. I've considered a number of reasons for why the shares may be lower in your case, but nothing really seems convincing. I wonder if bitcoind actually hands out the same work and you might well be doing overlapping work between the multiple cards. I've found that even if the efficiency drops off, the total accepted is higher and that's what ultimately matters? Check what your pool is reporting since they report back the hash rate according to how many accepted shares you return (but you'll need to get a few samples from the pool since they average over too small a period and it will fluctuate a lot).

As for your crash, I found a small bug that I pushed a couple of changes to fix, and hopefully it's one and the same thing.

[-ck]

first of all: wow, I think it's awesome to see ckolivas here! Loved your BFS work

Just a short question about the statistics:

Code:

GPU 0: [360.6 Mh/s] [Q:22  A:23  R:0  HW:3841  E:105%  U:5.28/m]

What are the HW and E parameters?

Thanks

It's in the readme. HW is hardware errors and E is efficiency. There is an issue where cgminer can have a run of apparent HW errors when you first start it, and it's harmless. I'm looking into that. If the hardware errors continue to rise after that, though, be concerned about your hardware.

[-ck]

Oh and kripz, hardware overheating/failing will not cause low "efficiency", but hardware errors... Low efficiency is when you queue much more work than you return generally (like CPU mining does). You can have that effect if you decrease the scantime or increase the gpu threads per card (not the overall number of gpus, but the number of threads per card).

[dikidera]

....and compatibility for windows is comletely broken....i think rollback...for you ckolivas.

[-ck]

....and compatibility for windows is comletely broken....i think rollback...for you ckolivas.

Dunno what you're talking about
Windows build:
http://ck.kolivas.org/apps/cgminer-1.2.0.1-win32.zip

[dikidera]

Ok, a suggestion for the CPU miner thread. Instead of new work for each thread, every thread should work on the same work. I.e, the nonces to be tried are split by the number of threads.
So thread 1 does X nonces, thread 2 does XX nonces and so on and so forth.

[-ck]

Ok, a suggestion for the CPU miner thread. Instead of new work for each thread, every thread should work on the same work. I.e, the nonces to be tried are split by the number of threads.
So thread 1 does X nonces, thread 2 does XX nonces and so on and so forth.

Very interesting idea considering how inefficient cpu mining is. I'll consider it after sorting out all the new bugs from the new interface.

[Nobu]

Techwtf mentioned longpolling was slow in the pool's thread; I guess that could have been part of the problem.

[-ck]

Updated tree:

Fixed lots of little bugs here and there in the curses code, some of which would lead to screen corruption and some of which would lead to crashes.

[dikidera]

Dunno if it's a bug or not, but:
In sha256 4way.c you declare the doubleblock sha function's prototype like this

static void DoubleBlockSHA256(const void* pin, void* pout, const void* pinit, unsigned int hash[8][NPAR], const void* init2);

However when you declare the function it's

static void DoubleBlockSHA256(const void* pin, void* pad, const void *pre, unsigned int thash[9][NPAR], const void *init)

[kr105]

I have a fresh setup of Ubuntu 11.04 and tried to compile this miner, it failed on the last step saying something about syntax error on main.c.

Short history:
change:

Code:

config = json_load_file(arg, &err);

to

Code:

config = json_load_file(arg, 0, &err);

on main.c

Long history:
LibJansson changed it API structure on the new 2.1 version, it added a flag parameter on the json_load_file function and that is why the compiler cry when i try to compile this.
My suggested patch just set that flag to 0, and problem solved.

This also will need a change on the ./configure to make it compatible with 2.1 and pre-2.1 versions.

[c00w]

Hello,

It appears that you use post instead of get when doing Long Polling. That is contradictory to the unofficial spec and really annoying when trying to debug software LP failures.

See https://deepbit.net/longpolling.php

-C00w

[-ck]

Hello,

It appears that you use post instead of get when doing Long Polling. That is contradictory to the unofficial spec and really annoying when trying to debug software LP failures.

See https://deepbit.net/longpolling.php

-C00w

That's good to know, thanks. I didn't implement any of the original communications parts that cgminer grew out of, so I had no idea. I'll look into correcting that.

[kripz]

Debug results in this:



Uploaded with ImageShack.us

EDIT: Fixed with latest commit 76b233a.

[kripz]

14310 user  20   0  248m  96m  29m S   17  9.7   0:14.11 ./cgminer -O miner:miner -o http://192.168.1.10:81 -R 1 -D

14398 user  20   0  254m  97m  29m S   17  9.8   0:15.46 ./cgminer -O miner:miner -o http://192.168.1.10:81 -R 1 --verbose

14488 user  20   0  245m  96m  29m S   17  9.7   0:05.97 ./cgminer -O miner:miner -o http://192.168.1.10:81 -R 1 -q

14546 user  20   0  249m  97m  29m S   17  9.8   0:12.93 ./cgminer -O miner:miner -o http://192.168.1.10:81 -R 1

Verbosity has no impact on CPU usage and is IMO, quite high.

CPU: G620

My AMD x4 640 has <1% usage.

620e   
2.6 GHz   
45nm SOI   
2MB    
socket AM3   
45W

[-ck]

Would you like a no-curses version as an option? It's using hardly any CPU here but clearly it will use more CPU with curses than a basic printf.

[kripz]

That would be nice and probably save some watts.

Though shouldnt -q do that? It doesnt update anything on the screen at all..

[-ck]

That would be nice and probably save some watts.

Though shouldnt -q do that? It doesnt update anything on the screen at all..

Good point.

Updated tree: Fixed the debug output by using locking around any screen updates. Made quiet mode not enable curses at all. Changed longpoll calls to not use POST.