Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 830. (Read 5806004 times)

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.

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.

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

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.

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...

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'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.)

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

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.

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.

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).

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.

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:


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:



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.

There is no windows build with the sse2 and sse4 support. Someone needs to build a 64 bit version to get those.

I thought this miner would be faster than ufasoft miner for CPU(SSE4).
However, it is much slower on windows.

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?

Since there seem to be a growing number of bugs with cgminer, how about setting up some kind of bug tracker for it? If I'm not mistaken, github has that functionality.

Anyway, to illustrate, these are the open bugs I've run across that I can remember:

1) Long polling is broken for deepbit in several ways.
a) After a while, "longpoll failed, sleeping for 30s" messages keep appearing, then the thread dies. I'm not exactly sure why that is.
b) The LP thread isn't restarted after it dies. This is a problem since deepbit turns off long polling from time to time, so the amount of LP failures will increase, resulting in a thread shutdown eventually, despite the fact that it is turned back on again.
c) With the recent versions I never get "proper" long polling messages, only "New block detected on network before longpoll, waiting on fresh work"

2) With recent modifications, cgminer doesn't compile on OSX anymore:

3) I'm not sure why, but with swepool.net I'm getting a huge amount of stales (>10%). With deepbit I'm getting ~14% stales, but I'm attributing that to the LP failures.

4) After a rejected share, cgminer should get new work just to be on the safe side. There's no real downside to this and it would probably cut the amount of rejects I get in half.


A bug tracker would not only avoid duplicate reports (or at least provide an easy way of managing them), it would allow the reporters to see any progress being made on those bugs, and thus (hopefully) create less noise.

Is this bug confirmed, fixed or still unconfirmed?

Unfortunately it didn't fix it for me.

del /F /Q *.bin

Prevents errors: binary size 0 : 0
Prevent issues on upgrading to a newer version, upgrade drivers, switch graphics card or chnage the sdk.