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

[-ck]

how does one specify phatk110714.cl or poclbm110717.cl ?

One does not. The poclbm kernel is far far behind the phatk kernel in speed and any hardware that can run the phatk kernel is given it. The poclbm kernel is reserved for nvidia cards and ATI 4x cards only. The phatk kernel, even without bitalign patching, crashes on these lesser mining cards.

Phoenix with phatk worked on my 4850, and that was faster than poclbm.

You can now specify which kernel you want with the -k option.

[nebiki]

Not every work item has a solution. Thus you will not get always get the same number of submissions as queries. Conversely some work items have more than one solution. This leads to "efficiency" of greater than 100% (when not solo mining).

alright, i don't really get it, but it sounds like "it's not a bug". thanks for the answer!

As for the flag idea...  

ya,  it figures.

[-ck]

Would it be possible to add a multipool strategy that's similar to load balance, but with the first one having priory? So the second one is just active when the first one for some reason doesn't have enough work, for example because of latency.

That's basically failover that you're describing... That's the default policy. Or do you mean micro delays instead of macro ones?

Yes, to even out (very) short performance drops.

Updated git tree: Now the default policy will detect when the primary pool is lagging and use a backup pool if there's one available.

[-ck]

re: POST vs GET on longpoll

I am absolutely getting sick of this freaking problem of how to do a longpoll. I originally converted to GET because someone suggested that's what the deepbit unofficial guide suggested was the way to do a longpoll. Then I discovered lots of other longpolls didn't work because MANY operating systems could easily lose their longpoll connection through routers and so on because they didn't issue any sort of keepalive for up to 2 hours by default (7200 seconds). So with help I converted it to use keepalives much more frequently. In the meantime, deepbit longpolls were BROKEN by the use of GET. Now someone posts me a fix for deepbit longpolls, using POST again. As far as I can see, there is NO ADVANTAGE to using GET and unless someone can positively prove me otherwise, I will be converting every longpoll to POST once more and putting this issue to bed forever.

[Diapolo]

[2011-07-24 02:22:31] Failed to init GPU thread 0                                                                                                           

Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.

Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.

Great, glad it works, and thanks for testing!

Give it time. The statistics now start out at time = 0, and it can take a while before you get the real value (10+ mins). Perhaps I should go back to resetting the statistics like I used to, but that made for some nice funky high values initially. What do people think?

No funky values, but the truth , so leave it like it is!

Dia

[xcooling]

+1 for POST instead of GET.

Could you add an option [P]ause , so we could pause the current work, if we wanted to quickly use the gpu for another task, and then resume it later.

[-ck]

New release: Version 1.4.1

Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.1.tar.bz2

Linux x86_64 dynamic binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.1-x86_64-built.tar.bz2

Win 32 binary:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.1-win32.zip


I thought it was time for a mostly bugfix release. The only new feature in this version is the new trickle function which trickles work automatically to a backup pool if the primary pool is still responding but slow to ensure the GPU is always doing work even if it hasn't quite reached the stage where cgminer decides to switch pools. This happens by default with any pool management strategy choice. The rest of the changes are bugfixes to things reported mostly on this forum (thanks for your reports). The rest of the changelog follows:

 Do away with GET for dealing with longpoll forever. POST is the one that works
everywhere, not the other way around.
- Detect when the primary pool is lagging and start queueing requests on backup
pools if possible before needing to roll work.
- Load balancing puts more into the current pool if there are disabled pools.
Fix.
- Disable a GPU device should the thread fail to init.
- Out of order command queue may fail on osx. Try without if it fails.
- Fix possible dereference on blank inputs during input_pool.
- Defines missing would segfault on --help when no sse mining is built in.
- Revert "Free up resources/stale compilers." - didn't help.
- Only try to print the status of active devices or it would crash.
- Some hardware might benefit from the less OPS so there's no harm in leaving
kernel changes that do that apart from readability of the code.

[zaytsev]

RPM for EL6, still broken on EL5 because of curl :-(

ck, -O2 -g is not helping either, it still doesn't segfault under gdb, but reliably segfaults when run from the terminal. Look, I managed to make it to dump core with -O0, then loaded in gdb and did bt full. Does it help?

Core was generated by `/opt/cgminer/bin/cgminer --cpu-threads 4 --gpu-threads 0 --url xxx'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt full
#0  memset () at ../sysdeps/x86_64/memset.S:1016
No locals.
#1  0x00007ff9732ad842 in wredrawln () from /lib/libncurses.so.5
No symbol table info available.
#2  0x000000000040ab0a in watchdog_thread (userdata=0x0) at main.c:2991
        y = 17
        logx = 131
        i = 4
        x = 131
        logy = 17
        now = {tv_sec = 1311508655, tv_usec = 958182}
        interval = 2
        rotate_tv = {tv_sec = 1311508643, tv_usec = 956086}
        zero_tv = {tv_sec = 0, tv_usec = 0}
#3  0x00007ff9736e09ca in start_thread (arg=<value optimized out>) at pthread_create.c:300
        __res = <value optimized out>
        pd = 0x7ff968a9a700
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140709179533056, -1219236616075443200, 0, 0, 4, 0, 1217862590511481856,
                1217801615496348672}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0,
              cleanup = 0x0, canceltype = 0}}}
        not_first_call = <value optimized out>
        robust = <value optimized out>
        freesize = <value optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#4  0x00007ff972ff570d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#5  0x0000000000000000 in ?? ()
No symbol table info available.

[iopq]

I was comparing this to diablominer, and they're about the same at -I 7, at -I 8 there's desktop lag and I'm getting about 155Mhash/s in both +/- 1 Mhash

without -I 7 the GPU utilization drops below 99% which affects the speed

[ancow]

With 1.4.1 (unmodified) on OS X, somehow the kernel isn't built:

Edit: seems I stumbled on the "need to reboot to get a kernel" bug.

[Clipse]

Does cgminer allow external adjustments to the gpu utilization, or would it be possible to add support for such a feature?

What I need to do is feed from external source to phoenixminer specific gpu utilization ie. external source parses to cgminer instance to utilise 29% of gpu cycles etc.

[Viceroy]

Version 1.4.1 will not compile on CENTOS, same error as below.

Code:

util.c:254: error: expected declaration specifiers or â...â before âcurlsocktypeâ
util.c: In function âjson_rpc_callâ:
util.c:347: error: âCURLOPT_SOCKOPTFUNCTIONâ undeclared (first use in this function)
util.c:347: error: (Each undeclared identifier is reported only once
util.c:347: error: for each function it appears in.)
make[2]: *** [cgminer-util.o] Error 1
make[2]: Leaving directory `/root/building/cgminer-1.4.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/building/cgminer-1.4.1'
make: *** [all] Error 2

What is the fix???

Version 1.4.0 no longer builds on RHEL5:

checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.15.5
checking for libcurl >= version 7.10.1... yes
checking whether libcurl is usable... yes
checking for curl_free... yes
...
gcc -DHAVE_CONFIG_H -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib  -DHAS_YASM -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O3 -Wall -MT cgminer-util.o -MD -MP -MF .deps/cgminer-util.Tpo -c -o cgminer-util.o `test -f 'util.c' || echo './'`util.c
util.c:254: error: expected declaration specifiers or '...' before 'curlsocktype'
util.c: In function 'json_rpc_call':
util.c:348: error: 'CURLOPT_SOCKOPTFUNCTION' undeclared (first use in this function)
util.c:348: error: (Each undeclared identifier is reported only once
util.c:348: error: for each function it appears in.)
make[2]: Leaving directory `/builddir/build/BUILD/cgminer-1.4.0'
make[2]: *** [cgminer-util.o] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/cgminer-1.4.0'
RPM build errors:
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.75423 (%build)
    Bad exit status from /var/tmp/rpm-tmp.75423 (%build)
Child returncode was: 1

Could be old gcc or curl... is it possible to put a conditional to fix this? Previous versions did build just fine... The full log is here: http://rpm.zaytsev.net/test/cgminer/build.log

P.S. The fix by ycros doesn't help, I tried to replace util.c.

P.P.S. Yes, that's the curl version that is too old. Is it possible to make longpoll optional via configure??? It doesn't have all this CURLOPT_SOCKOPTFUNCTION stuff. It would suck if the support for RHEL5 would have to be dropped completely.

[zaytsev]

Version 1.4.1 will not compile on CENTOS, same error as below. What is the fix???

As I said the curl version is too old, there is no fix unless ck makes longpoll optional / figures out how to implement this functionality only using old curl's features.

[smurfix]

As I said the curl version is too old, there is no fix unless ck makes longpoll optional / figures out how to implement this functionality only using old curl's features.

The fix is to add a check to configure.ac, for "new curl" (i.e. version and/or data type and/or library call) and to refuse to continue if that's not present.

Should be straightforward to implement.

[zaytsev]

Should be straightforward to implement.

Well, that's not a fix as it won't make it work on RHEL5, that's just making the failure message more informative. I guess I can try compiling static builds against newer curl, but I don't really understand if anyone is interested in RHEL5 builds other than me.

[Viceroy]

but I don't really understand if anyone is interested in RHEL5 builds other than me.

Much of the world.  If this doesn't work on Centos, it's worthless.  Kinda like coming up
with windows only mining software

To the author, this is what was required to build poclbm under centos:
http://forum.bitcoin.org/?topic=7534.0

RedHat and Centos uses older (proven stable) versions of their software.

Unfortunatly I, like zaytsev, am stuck using poclbm atm.

* Viceroy sadly drops his head and walks away

[smurfix]

Well, that's not a fix as it won't make it work on RHEL5, that's just making the failure message more informative.

Good thing IMHO. configure.ac is supposed to test for minimum features, after all.

I guess I can try compiling static builds against newer curl, but I don't really understand if anyone is interested in RHEL5 builds other than me.

The problem with this idea is that network-using static libraries are not supported by glibc.

You should be able to build your own version of "new" libcurl and compile+link against that.
Adding a --with-libcurl=/usr/local/src/newcurl option to configure is reasonably simple.

[cyberchriss]

With version 1.4.0 and 1.4.1, I have some trouble connecting to the rpc server.

cgminer exists with code:

Code:

No pools active! Exiting.

I tried it several times with the same starting parameters:
./cgminer -o http://uswest.btcguild.com:8332 -u myusername -p mypassword -w 256 -I 8 --verbose

and got only 1 connect where only the first gpu was starting to work.

I tested 1.4.0 and 1.4.1 precompiled version for ubuntu with the same behavior.

Version 1.3.1 is working fine.
Got 14.42 shares per minute
with
2 * 5850 @ 900,300
1 * 5850 @ 820,300

[zaytsev]

The problem with this idea is that network-using static libraries are not supported by glibc.

Errr... what?

Adding a --with-libcurl=/usr/local/src/newcurl option to configure is reasonably simple.

This isn't even needed, because curl gets picked up by pkgconfig (which actually doesn't seem to work, it's rather curl-config that does the trick).

Viceroy, I have tried my static curl twist and it worked, updated RPMs here. You know which way to throw your coins ;-)

[Viceroy]

what's the fix?

* Viceroy picks his head up and starts to listen again

I ain't pickin up your precompiled code