OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

Why intensity 9 now?

And what does this mean?

Don't leak work to backup pools when primary pool is lagging

Why 9? I thought I explained that. I get more mhashes now with 9 than 8. With previous versions I didn't.

Normally work gets leaked to backup pools if the primary pool is detected as lagging before it has actually failed. Enabling this new flag means no work will go to backup pools unless the primary one has failed completely. This was a requested feature by a donor.

[1713559784]

1713559784

[1713559784]

1713559784

[1713559784]

1713559784

[Tasty Champa]

ckolivas,
thanks for the reply about ask rate and scan time.
I don't completely comprehend yet what it does really but thanks!

I was wondering, is there anymore specific flags I should pay more attention to when solo mining?

I'm also trying to figure out how to do FASTLOOP=false with cgminer, is this possible or is this set automagically?

[-ck]

ckolivas,
thanks for the reply about ask rate and scan time.
I don't completely comprehend yet what it does really but thanks!

I was wondering, is there anymore specific flags I should pay more attention to when solo mining?

I'm also trying to figure out how to do FASTLOOP=false with cgminer, is this possible or is this set automagically?

None of the variables from other miners are directly portable to cgminer. Presumably what you want is the dynamic mode OFF which happens whenever you set an intensity with -I (number).

[Furyan]

This has probably already been answered but honestly.... some people have better things to do than re-read 60 pages of a thread.

When I use cryptopp_asm32 mode for the CPU miner, I get ridiculously wrong values for the hash rate - things like 150 MH/s, wildly fluctuating up and down and the 5 sec average frequently displaying Nan.  Is there a bug in the rate calculation for that algorithm?

[-ck]

This has probably already been answered but honestly.... some people have better things to do than re-read 60 pages of a thread.

When I use cryptopp_asm32 mode for the CPU miner, I get ridiculously wrong values for the hash rate - things like 150 MH/s, wildly fluctuating up and down and the 5 sec average frequently displaying Nan.  Is there a bug in the rate calculation for that algorithm?

I'd say the cryptopp_asm32 on windows is likely broken.

[JinTu]

This has probably already been answered but honestly.... some people have better things to do than re-read 60 pages of a thread.

When I use cryptopp_asm32 mode for the CPU miner, I get ridiculously wrong values for the hash rate - things like 150 MH/s, wildly fluctuating up and down and the 5 sec average frequently displaying Nan.  Is there a bug in the rate calculation for that algorithm?

I'd say the cryptopp_asm32 on windows is likely broken.

I'm seeing the same wildly inaccurate hash rate reporting on Linux with cryptopp_asm32 as well. it looks like this is just the reporting though as the pool is reporting normal values from my miner.

[Furyan]

This has probably already been answered but honestly.... some people have better things to do than re-read 60 pages of a thread.

When I use cryptopp_asm32 mode for the CPU miner, I get ridiculously wrong values for the hash rate - things like 150 MH/s, wildly fluctuating up and down and the 5 sec average frequently displaying Nan.  Is there a bug in the rate calculation for that algorithm?

I'd say the cryptopp_asm32 on windows is likely broken.

I'm seeing the same wildly inaccurate hash rate reporting on Linux with cryptopp_asm32 as well. it looks like this is just the reporting though as the pool is reporting normal values from my miner.

Agreed, it seems to be fine from the pool side but the reporting is way off.

ckolivas, any idea what needs to be done to fix this? I'm happy to take a look and submit a pull request if I can fix the problem.

[dlasher]

ok, I've been beating my  head on this for 24 hours, figured I'd ask.

How do I get cgminer to log ONLY summary data, like "[(60s):1076.3  (avg):1070.2 Mh/s] [Q:146  A:115  R:3  HW:0  E:79%  U:14.70/m] " to the syslog, and leave out the rest of the messages?

I'm remote-syslogging all my miners to a central syslog.. Even "Quiet" mode gives a lot more information than I want/need, at far more often than the configured interval. Example:

Aug 31 10:08:41 miner9 cgminer[2681]: GPU 2  Q:29  A:20  R:1  HW:0  E:69%  U:7.10/m
Aug 31 10:08:42 miner9 cgminer[2681]: GPU 0  Q:27  A:22  R:1  HW:0  E:81%  U:7.81/m
Aug 31 10:08:47 miner9 cgminer[2681]: GPU 2  Q:29  A:21  R:1  HW:0  E:72%  U:7.46/m
Aug 31 10:08:47 miner9 cgminer[2681]: GPU 0  Q:27  A:23  R:1  HW:0  E:85%  U:8.17/m
Aug 31 10:08:53 miner9 cgminer[2681]: [(60s):1074.0  (avg):1065.9 Mh/s] [Q:74  A:61  R:3  HW:0  E:82%  U:15.98/m]
Aug 31 10:08:53 miner9 cgminer[2681]: GPU 0  Q:27  A:24  R:1  HW:0  E:89%  U:6.29/m
Aug 31 10:08:56 miner9 cgminer[2681]: GPU 1  Q:11  A:18  R:1  HW:0  E:164%  U:4.72/m
Aug 31 10:09:11 miner9 cgminer[2681]: GPU 0  Q:27  A:25  R:1  HW:0  E:93%  U:6.55/m
Aug 31 10:09:15 miner9 cgminer[2681]: GPU 0  Q:27  A:26  R:1  HW:0  E:96%  U:6.81/m
Aug 31 10:09:25 miner9 cgminer[2681]: GPU 0  Q:27  A:27  R:1  HW:0  E:100%  U:7.07/m
Aug 31 10:09:26 miner9 cgminer[2681]: GPU 2  Q:38  A:22  R:1  HW:0  E:58%  U:5.76/m
Aug 31 10:09:28 miner9 cgminer[2681]: GPU 0  Q:27  A:28  R:1  HW:0  E:104%  U:7.34/m
Aug 31 10:09:36 miner9 cgminer[2681]: GPU 1  Q:20  A:19  R:1  HW:0  E:95%  U:4.98/m
Aug 31 10:09:50 miner9 cgminer[2681]: GPU 1  Q:20  A:20  R:1  HW:0  E:100%  U:5.24/m
Aug 31 10:09:52 miner9 cgminer[2681]: GPU 1  Q:20  A:21  R:1  HW:0  E:105%  U:5.50/m
Aug 31 10:09:53 miner9 cgminer[2681]: [(60s):1072.4  (avg):1067.0 Mh/s] [Q:92  A:71  R:3  HW:0  E:77%  U:14.73/m]
Aug 31 10:09:53 miner9 cgminer[2681]: GPU 2  Q:38  A:23  R:1  HW:0  E:61%  U:4.77/m
Aug 31 10:09:56 miner9 cgminer[2681]: GPU 0  Q:27  A:29  R:1  HW:0  E:107%  U:6.02/m

It would be nifty to have a "log-level" like syslogs levels for OUTPUT MODE:

0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages


Things like "DEAD GPU" would be 1 or 2, accepted could be 6, rejected could be 5, etc.

(while I'm asking, it would be nice to be able to pass "Facility" as a command-line option to the "--syslog" option... local3 for example)

Thanks again for a great program, hope there's an easy way to do what I'm asking..

[zaytsev]

Sorry for being a PITA, but the ncurses bug is still there. The memleak seems to be gone in 1.6.1 though, it's been an hour already and the process is at 370M. Let's see if it leaks overnight or not. Also, it still doesn't build with older curl (at least make it fail at configure stage :-( ):

util.c:249: error: expected declaration specifiers or '...' before 'curlsocktype'
make[2]: *** [cgminer-util.o] Error 1

Thanks!

[zaytsev]

Also, it is not clear to me what is the purpose of the following check in configure.ac:

AC_CHECK_LIB(curl, curl_easy_init, ,
<------>AC_MSG_ERROR([Could not find curl library - please install libcurl-dev]))

it comes *before* PKGCONFIG detection, so unless curl is installed in a standard location it just can't succeed. Also, LIBCURL_CPPFLAGS / LIBCURL_LIBS are substituted after the pkgconfig check, and if the check fails, then configure fails. So they don't make much sense, because if pkgconfig is non-existant or doesn't find the lib, it will AC_MSG_ERROR.

 LIBCURL_CFLAGS
              C compiler flags for LIBCURL, overriding pkg-config
  LIBCURL_LIBS
              linker flags for LIBCURL, overriding pkg-config

My suggestions:

1) Only pkgconfig if  LIBCURL_CPPFLAGS / LIBCURL_LIBS are NOT set
2) Move AC_CHECK_LIB *after* pkgconfig
3) Add LIBCURL_CPPFLAGS / LIBCURL_LIBS to CPPFLAGS / LDFLAGS before AC_CHECK_LIB and restore afterwards

Right now I basically can't compile cgminer against a statically linked libcurl.a

[-ck]

Ok, configure scripts are witchcraft to me.

I'm having trouble finding any interest in supporting older distributions and libraries in light of that knowledge limitation of mine. If you have patches, I'd be more than happy to accept them 

[zaytsev]

Ok, got it, I'll try to make you some working patch tomorrow as I'll have to spend the time on train... The problem is as always the lack of time, so I'm hoping till the very end that someone else will do it for me :-)

P.S. I've checked on the CPU mining memleak and it's still leaking albeit slower. Like 200 mb per day or so.

[The LT]

A typical mining rig isn't your production-class server running old stable userland. I don't see any point putting developer time in working on older curl compatibility. It probably won't be used by many, if anyone at all.

just my 2c.

[zaytsev]

Obviously, I need it. It's not because I care so much about other people that might need it that I am asking for it. Having to do it myself is a logical answer though.

[dlasher]

A typical mining rig isn't your production-class server running old stable userland.

Given the single purpose of the mining rig, the smaller, the more stripped, the more stable, the better.. that does not match, sadly, the goals of most new distros. I've been running on Fedora14/15 and am actually trying to move backwards to Centos5 for the greater stability... currently being stopped short compiling 1.6.1 with:

if gcc -DHAVE_CONFIG_H -I. -I. -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib   -O3 -Wall -msse2 -I/usr/src/AMD-APP-SDK-v2.4-lnx32/include -g -MT cgminer-main.o -MD -MP -MF ".deps/cgminer-main.Tpo" -c -o cgminer-main.o `test -f 'main.c' || echo './'`main.c; \
        then mv -f ".deps/cgminer-main.Tpo" ".deps/cgminer-main.Po"; else rm -f ".deps/cgminer-main.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib   -O3 -Wall -msse2 -I/usr/src/AMD-APP-SDK-v2.4-lnx32/include -g -MT cgminer-util.o -MD -MP -MF ".deps/cgminer-util.Tpo" -c -o cgminer-util.o `test -f 'util.c' || echo './'`util.c; \
        then mv -f ".deps/cgminer-util.Tpo" ".deps/cgminer-util.Po"; else rm -f ".deps/cgminer-util.Tpo"; exit 1; fi
util.c:227: error: expected declaration specifiers or ‘...’ before ‘curlsocktype’

which sounds a lot like problems with older curl to me..
.

[-ck]

Hi ckolivas,

I can confirm the high number of rejects (100% on my boxes) with CPU mining has been fixed. The only algo that wouldn't generate rejects for me was the sse2_64. So great work.

Compiling 1.6.1 is a different story though. I notice the configure script checks for curl_easy_init and after that does the pkg-config check for libcurl. Since it doesn't know where to look for curl yet, the former check obviously fails. Also, you use LIBCURL_CPPFLAGS, but on FreeBSD (and possibly other systems), pkg-config only returns LIBCURL_CFLAGS. Since they should be the same, could you change it to make use of CFLAGS instead of CPPFLAGS ?

Thanks in advance.

libcurl.m4 defines LIBCURL_CPPFLAGS and CFLAGS would be something completely different as far as I understand it, so you're missing the m4 file from some package.

[-ck]

New version: 1.6.2

Executive summary:
New --failover-only feature for those who complain too much work goes to the backup pool even without the primary pool failing. NOTE that you may get more idle periods with this enabled (which is why it leaked work to the backup pool in the first place).
New scheduling features to specify a start and stop time.
Various fixes and more verbose pebkac warnings.


Full changelog:

- Add --failover-only option to not leak work to backup pools when the primary
pool is lagging.
- Change recommendation to intensity 9 for dedicated miners.
- Fix the bouncing short term value by allowing it to change dynamically when
the latest value is very different from the rolling value, but damp the change
when it gets close.
- Use the curses_lock to protect the curses_active variable and test it under
lock.
- Go back to requesting work 2/3 of the way through the current scantime with
CPU mining as reports of mining threads running out of work have occurred with
only 5 seconds to retrieve work.
- Add start and stop time scheduling for regular time of day running or once off
start/stop options.
- Print summary on quit modes.
- Put some sanity checks on the times that can be input.
- Give a verbose message when no active pools are found and pause before
exiting.
- Add verbose message when a GPU fails to initialise, and disable the correct
GPU.
- Cryptopp asm32 was not correctly updated to the incremental nonce code so the
hash counter was bogus.
- Get rid of poorly executed curl check.
- If curl does not have sockopts, do not try to compile the
json_rpc_call_sockopt_cb function, making it possible to build against older
curl libraries.
- Most people expect /usr/local when an unspecified prefix is used so change to
that.
- Rename localgen occasions to getwork fail occasions since localgen is
unrelated now.


Links in top post.

[Lightspeed]

working on one PC, but will not run on others

tried 2 different pools, internet is working, pools up

i get a message saying no servers were found

it just exits straight away

vista 32bit fresh install :/

[PLaci1982]

working on one PC, but will not run on others

tried 2 different pools, internet is working, pools up

i get a message saying no servers were found

it just exits straight away

vista 32bit fresh install :/

What GPU does include the PCs, and what driver/SDK version are installed?

[zaytsev]

which sounds a lot like problems with older curl to me...

Yes, yours are the problems that I mentioned above. I am preparing an RPM that you can rebuild with rpmbuild if you need GPU mining or use it as is if you only need CPU mining this evening, which features a static build against curl, so which version is in the base system repos would be irrelevant.