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

[-ck]

Great work, ckolivas.

Just being unclear about the mining-speed hinders me from switching all my miners to cgminer. I'm on Windows 7 (x86) with a 6950

phoenix shows 245.5 Mh/s with these settings:

Code:

phoenix -u http://user:pass@nl.btcguild.com:8332/ -k phatk DEVICE=0 VECTORS AGGRESSION=11 BFI_INT WORKSIZE=128 FASTLOOP=false

With cgminer the avg value is like 244.0 Mh/s (the momentary value show next to GPU 0 is like 252.5 Mh/s).with:

Code:

cgminer --algo c -o http://nl.btcguild.com:8332 -u user -p pass -I 8 -l 2

Which of the values shown are comparable?

I don't really want to run long-term tests to compare the number of shares produced by each one of them.

Thanks. The "algo c" does nothing with GPU mining, it's for CPU mining. That is pretty much the best settings for your hardware. The 5 second average unfortunately is always going to jump around (due to it being coarse intentionally to avoid overhead, and in your case you have it set to 2 seconds with -l 2) and the overall average settles down after about 5 minutes or so.  That is a true all time average of hashes done / time running.

[The00Dustin]

OK, so I checked and I had installed the nvidia drivers as you described (including the cuda toolkit location).  As such, I tried this:
CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia ./configure --program-suffix=\-nvidia

For the record, I uninstalled my previous build first, the -nvidia was just in case I ended up finding it only working for nvidia and wanted to try to run an nvidia one and an ATI one side by side.  When I tried to run cgminer-nvidia, I still get this:
[2011-07-21 09:26:33] Error: Getting Device IDs (num)

I then proceeded to uninstall again, remove the jansson-devel libraries just in case, configure without the program suffix just in case, compile and install again, see the same error when running cgminer, so I edited /etc/ld.so.conf.d/local.conf to remove these two lines:
/opt/ati-stream-sdk-v2.1-lnx64/lib/x86_64/
/opt/ati-stream-sdk-v2.1-lnx64/lib/x86/

I then ran ldoconfig.  I still had to use CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia in order to have gpu mining support enabled even though /etc/ld.so.conf.d/local.conf still had these lines:
/usr/local/cuda/lib64/
/usr/local/cuda/lib/

After all that (some of it perhaps grasping at straws), I STILL get the same error.  Any other thoughts?

Turns out the issue was even simpler than I could have imagined.  I put in an ATI card and recompiled using ATI's SDK and still got the same error.  Here's the catch, I've been working from SSH this whole time.  Turns out this miner doesn't work on an SSH console or on a local console at runlevel 3.  I didn't try a local  console at runlevel 5, but I used a terminal in X and it is running fine.  I couldn't ever get it to detect the ATI and NVIDIA cards simultaneously (even with both sets of packages installed using rpm with --nodeps [after which point boot.grub must be edited]), but I never hooked the NVIDIA card up to a monitor after I made it secondary.  Considering the fact that the executable behaves on linux the same way most do on Windows (can't be run in a remote session), I'm thinking maybe it couldn't see the NVIDIA card because of that (never tried booted to the NVIDIA card at X because I didn't figure out it just wouldn't work in SSH until after I had already made the ATI card primary).

EDIT:  Also, I tried with -I 1 in Windows and cpu usage was still incredibly high.  I also still got rejects on the 9500GT, but I'm thinking that maybe they are stale shares from long-polling not working right based on a post I saw earlier in this page (or the previous).

[ah42]

I then ran ldoconfig.  I still had to use CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia in order to have gpu mining support enabled even though /etc/ld.so.conf.d/local.conf still had these lines:
/usr/local/cuda/lib64/
/usr/local/cuda/lib/

ld.so.conf (et. al.) only affects runtime linking, not compile time linking. Likewise the LD_LIBRARY_PATH environment variable only has any effect on runtime linking.

To the best of my knowledge, there exists no compile-time counterpart to ld.so.conf. However, there is an environment variable similar to LD_LIBRARY_PATH. It is LIBRARY_PATH. Anything set in this variable will be searched by gcc during the link stage. However, it would appear you still need to specify your CFLAGS, since you're asking it to include a non-standard path.

[The00Dustin]

ld.so.conf (et. al.) only affects runtime linking, not compile time linking. Likewise the LD_LIBRARY_PATH environment variable only has any effect on runtime linking.

To the best of my knowledge, there exists no compile-time counterpart to ld.so.conf. However, there is an environment variable similar to LD_LIBRARY_PATH. It is LIBRARY_PATH. Anything set in this variable will be searched by gcc during the link stage. However, it would appear you still need to specify your CFLAGS, since you're asking it to include a non-standard path.

That should be helpful many times in my life...  I have had trouble compiling a lot of programs, and whenever I search an error and OS combo, the response is always "add this to ld.so.conf (or equivalent) and run ldconfig".  Now I know why it NEVER worked for me on several different flavors.  Thanks for the info.

[-ck]

If you want it to work remotely, use
export DISPLAY=:0
after ssh'ing in.

[ancow]

If you want it to work remotely, use
export DISPLAY=:0
after ssh'ing in.

That'll only work if an X server is active and the session belongs to the right user. In the case of a headless system, or a remote system that just doesn't run an X server (like most servers), a dummy X server might help. (Xvfb comes to mind.)

[-ck]

If you want it to work remotely, use
export DISPLAY=:0
after ssh'ing in.

That'll only work if an X server is active and the session belongs to the right user. In the case of a headless system, or a remote system that just doesn't run an X server (like most servers), a dummy X server might help. (Xvfb comes to mind.)

You can't GPU mine unless you're running an X server. It relies on the driver being in use to communicate with the card. While headless systems can have no monitors attached (like my own), they still need to be running X.

[ancow]

If you want it to work remotely, use
export DISPLAY=:0
after ssh'ing in.

That'll only work if an X server is active and the session belongs to the right user. In the case of a headless system, or a remote system that just doesn't run an X server (like most servers), a dummy X server might help. (Xvfb comes to mind.)

You can't GPU mine unless you're running an X server. It relies on the driver being in use to communicate with the card. While headless systems can have no monitors attached (like my own), they still need to be running X.

That doesn't really change anything about the fact that simply assuming X is running and :0 is owned by the user won't always do. In case of doubt, you'll have to start the X server remotely, I'm not sure if Xvfb can be made to use a proper graphics driver, but I guess that would be worth a try as it wouldn't interfere with anybody working on the remote machine and it would use a minimum of resources...

[bmgjet]

Just added another card to my PC so now im running 2 in same machine.
CPU usage went from 0-1% (using 1 card) up to 90% (using both cards)
Running 1 process for each card brings it down a bit (15-20% cpu per process) but its still higher then when there was just the one card in the PC.

Had a look though a few of the posts to see if there was a fix and running it with affinity to core 0 at least limits its and brings power usage down a bit but its still using more power then it should be.

Windows 7 32bit.
SDK 2.4
Catylist 11.6 running dummy plugs.

[Tartarus]

Great work, ckolivas.

Just being unclear about the mining-speed hinders me from switching all my miners to cgminer. I'm on Windows 7 (x86) with a 6950

phoenix shows 245.5 Mh/s with these settings:

Code:

phoenix -u http://user:pass@nl.btcguild.com:8332/ -k phatk DEVICE=0 VECTORS AGGRESSION=11 BFI_INT WORKSIZE=128 FASTLOOP=false

With cgminer the avg value is like 244.0 Mh/s (the momentary value show next to GPU 0 is like 252.5 Mh/s).with:

Code:

cgminer --algo c -o http://nl.btcguild.com:8332 -u user -p pass -I 8 -l 2

Which of the values shown are comparable?

I don't really want to run long-term tests to compare the number of shares produced by each one of them.

I would add in -w 128 to make sure the worksize is matching and possibly try fiddling with -v.

[The00Dustin]

With cgminer the avg value is like 244.0 Mh/s (the momentary value show next to GPU 0 is like 252.5 Mh/s).with:

I've seen the momentary value next to the GPU show 1500MH/s on a GTX 560 Ti in WinXP, so I'd say the average value is correct.  Additionally, I think -q will get rid of the GPU value, and presumably he wouldn't hide the correct value while showing an incorrect one.

[xcooling]

lol..

-w 256 is the correct work unit for ati 5870/5970/6950/6970/6990.

tweaking the -I value.

dual cards = -I 9 (2x 5870, 5970, 2x 6950, 2x 6970, 6990)

single cards = -I 8 (5870/6950/6970)

next thing to note.. windows you'll need 1 core per a graphics card, this is due to the pthread implementation.


CPU mining is not viable with cgminer.. with a highly optimized cpu specific build.. it is still 50% slower than ufasoft's miner.

Also.. MH/s rate means nothing.. you make your "money" on shares accepted per 1 minute  eg. U: 10.77/m]

cgminer will upload more shares in a given time frame than all the other miners, do a proper test.

[dostortugas]

lol..

-w 256 is the correct work unit for ati 5870/5970/6950/6970/6990.

the correct worksize reported from the cards I have is 256 but they tune better on 128

also the correct vectors reported is 4 tuning in on 4 reduces mh/s by at least 30% for those cards

cgminer default (setting nothing) is vectors 2 and worksize 128

setting the worksize to 256 on my 5850 gets me 5 more MH/s and usually the card's thread freezes within minutes... means xserver stales means reboot (no kill -9)!

[xcooling]

are you running default queue size and I set to 8 ?

2x 6970 with -w 256 = U: 11.47/m (Mh/s = 773)

2x 6970 with -w 128 -v2 = U: 8.76/m (Mh/s = 800.4)


^^^ which would u rather have ? higher shares per minute or  higher Mh/s...

[burp]

Fantastic work for 1.4.0, I think it's again donation time for everyone

[xcooling]

Yeah , sshhhhh its not "official" ;-P

I hope he gets the json multipool config sorted

[zaytsev]

Looks like it never got the threads started. Grab a fresh tarball, uninstall sdk2.1 and install sdk2.4 perhaps. The phatk kernel in it may no longer be compatible with 2.1.

Sorry, this was stupid me, didn't export DISPLAY before I ran the miner. However, aren't you able to reproduce the segfault when you resize the terminal??? It happens to me both under screen and just like that on several machines (Ubuntu 10.04.3, RHEL5 etc.)

[-ck]

Looks like it never got the threads started. Grab a fresh tarball, uninstall sdk2.1 and install sdk2.4 perhaps. The phatk kernel in it may no longer be compatible with 2.1.

Sorry, this was stupid me, didn't export DISPLAY before I ran the miner. However, aren't you able to reproduce the segfault when you resize the terminal??? It happens to me both under screen and just like that on several machines (Ubuntu 10.04.3, RHEL5 etc.)

Nope. Cannot reproduce :\

[tenzor]

Latest git version segfaults when use -Q parameter at startup. Ubuntu 11.04, catalyst 11.6, 32bit

[-ck]

Latest git version segfaults when use -Q parameter at startup. Ubuntu 11.04, catalyst 11.6, 32bit

Thanks. Fixed in git.