OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 832.

ancow

full member

Activity: 373

Merit: 100

Quote from: -ck on July 21, 2011, 06:07:52 PM

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: ah42 on July 21, 2011, 05:25:51 PM

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.

ah42

newbie

Activity: 14

Merit: 0

Quote from: The00Dustin on July 21, 2011, 08:52:45 AM

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

hero member

Activity: 807

Merit: 500

Quote from: The00Dustin on July 21, 2011, 08:52:45 AM

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Ali on July 21, 2011, 04:20:59 PM

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:[email protected]: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.

Ali

member

Activity: 84

Merit: 10

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:[email protected]: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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: BOARBEAR on July 21, 2011, 01:08:23 PM

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

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

BOARBEAR

member

Activity: 77

Merit: 10

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

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: error on July 20, 2011, 06:38:47 PM

If you installed the NVIDIA drivers from RPM Fusion (including xorg-x11-drv-nvidia-devel package) and the CUDA toolkit from NVIDIA in the default /usr/local/cuda, then this should get you going:

Code:

CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia ./configure
make clean
make

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?

ancow

full member

Activity: 373

Merit: 100

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.

EskimoBob

legendary

Activity: 910

Merit: 1000

Quality Printing Services by Federal Reserve Bank

Quote from: dikidera on July 20, 2011, 03:40:39 AM

Just a heads up for a few people.

Cgminer does not appear to support target rewrites. I have checked the code and the target is derived from midstate and "data" from the getwork. Thus when the pools send you diff 1 work, cgminer ignores that and mines with full difficulty and since the gpu miner code does not check if the hash meets the difficulty, it sends a result anyway. This is why some people have reported they get less shares with cgminer.

For proof, go into findnonce.c and in the precalc function add

Code:

printf("nbits %d", blk->nbits);

somewhere, compile and run, it will print the nbits of the current target.

I'd categorize this as a serious flaw. Miners still submitted work, but far less than usual. In the long run, people earned waay less than they should have.

P.S
Conman is aware of this, however is reluctant to fix it. The excuse was "It sends shares, doesn't it?"

Is this bug confirmed, fixed or still unconfirmed?

heli0s

newbie

Activity: 6

Merit: 0

Quote from: -ck on July 20, 2011, 08:45:22 PM

Quote from: error on July 20, 2011, 08:42:31 PM

The 1.3.1 release solved my issue with blank lines between the log entries. Thanks!

You're welcome! The issue was that windows opens a standard dos shell in 80 columns and the default text was slightly wider than 80 so I made it more concise.

Unfortunately it didn't fix it for me.

Code:

[2011-07-21 07:38:46] Accepted 3e2ec113 GPU 0 thread 0 pool 0

[2011-07-21 07:39:00] New block detected on network before longpoll, waiting on
fresh work
[2011-07-21 07:39:10] Accepted 70ab214e GPU 0 thread 0 pool 0

[2011-07-21 07:39:16] Accepted 3ab13683 GPU 0 thread 1 pool 0

[2011-07-21 07:39:19] Accepted 4e2712a7 GPU 0 thread 0 pool 0

[2011-07-21 07:39:20] Accepted 57e1f7b3 GPU 0 thread 0 pool 0

[2011-07-21 07:39:23] Accepted 45e05dd0 GPU 0 thread 1 pool 0

xcooling

member

Activity: 145

Merit: 10

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.

Tasty Champa

member

Activity: 84

Merit: 10

Quote from: xcooling on July 20, 2011, 01:32:00 PM

what gpus are you using ?

these are mine:

SLI Nvidia 9800gtx+ / SLI GTS250

Code:

del /F /Q *.bin
cgminer.exe -o http://server:port -u username -p pass -w 64 -t 0 -I 4

XFire 6970 / XFIRE 6950

Code:

del /F /Q *.bin
cgminer.exe -o http://server:port -u username -p pass -I 9 -t 0

My curiosity urges me to ask why you are removing the previous bin files?
I'm using just one 5770, but I removed the 256 worksize as it made my system not as responsive.
I think I am also going to remove the -g 10 as per ckolivas's advice, thanks ckolivas!

Departure

sr. member

Activity: 1204

Merit: 288

Quote from: -ck on July 20, 2011, 07:45:16 PM

Darn. You do have the 2.4 SDK installed don't you?

I have just the drivers installed which comes with all the needed SDK stuff, never needed to actually install the whole SDK package with any other miner. But yeah I can try and install the SDK also and see what happends..

//Edit

Installed and tested with SDK 2.4 still the same error.

Windows 7 x64 (Themes Disabled)
SDK 2.4
Drivers 11.7
3 x 6990 gfx cards.

kripz

full member

Activity: 182

Merit: 100

I hope it's ok to mine namecoin, all rejected at such low difficulty> Sad

Code:

Started at [2011-07-19 15:08:35]
Runtime: 45 hrs : 34 mins : 53 secs
Average hashrate: 11.1 Megahash/s
Queued work requests: 833
Share submissions: 404
Accepted shares: 0
Rejected shares: 404
Reject ratio: 100.0
Hardware errors: 0
Efficiency (accepted / queued): 0%
Utility (accepted shares / min): 0.00/min

Discarded work due to new blocks: 3
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 3
Work items generated locally: 3
Submitting work remotely delay occasions: 0
New blocks detected on network: 109

Summary of per device statistics:

 GPU 0: [11.1 Mh/s] [Q:831  A:0  R:404  HW:0  E:0%  U:0.00/m]

Code:

Started at [2011-07-19 10:21:04]
Runtime: 50 hrs : 24 mins : 18 secs
Average hashrate: 966.7 Megahash/s
Queued work requests: 44267
Share submissions: 40934
Accepted shares: 39912
Rejected shares: 1022
Reject ratio: 2.5
Hardware errors: 0
Efficiency (accepted / queued): 90%
Utility (accepted shares / min): 13.20/min

Discarded work due to new blocks: 229
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 78
Work items generated locally: 702
Submitting work remotely delay occasions: 5
New blocks detected on network: 691

Summary of per device statistics:

 GPU 0: [322.2 Mh/s] [Q:15014  A:13152  R:355  HW:0  E:88%  U:4.35/m]
 GPU 1: [322.2 Mh/s] [Q:14998  A:13410  R:304  HW:0  E:89%  U:4.43/m]
 GPU 2: [322.3 Mh/s] [Q:15030  A:13350  R:363  HW:0  E:89%  U:4.41/m]

Started at [2011-07-19 10:19:08]
Runtime: 50 hrs : 24 mins : 40 secs
Average hashrate: 179.9 Megahash/s
Queued work requests: 8527
Share submissions: 7514
Accepted shares: 7218
Rejected shares: 296
Reject ratio: 3.9
Hardware errors: 0
Efficiency (accepted / queued): 85%
Utility (accepted shares / min): 2.39/min

Discarded work due to new blocks: 12
Stale submissions discarded due to new blocks: 0
Unable to get work from server occasions: 34
Work items generated locally: 94
Submitting work remotely delay occasions: 1
New blocks detected on network: 543

Summary of per device statistics:

 GPU 0: [179.9 Mh/s] [Q:8912  A:7218  R:296  HW:0  E:81%  U:2.39/m]

Time to upgrade!

Still have to compile with -O1 or no optimizations otherwise i get seg faults on exit.

error

hero member

Activity: 588

Merit: 500

Quote from: -ck on July 20, 2011, 08:55:33 PM

So your shell was also 80 columns Tongue

I use Konsole. Tongue

OK, I'll quit now

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

So your shell was also 80 columns Tongue

error

hero member

Activity: 588

Merit: 500

Quote from: -ck on July 20, 2011, 08:45:22 PM

Quote from: error on July 20, 2011, 08:42:31 PM

The 1.3.1 release solved my issue with blank lines between the log entries. Thanks!

You're welcome! The issue was that windows opens a standard dos shell in 80 columns and the default text was slightly wider than 80 so I made it more concise.

I use Linux. Tongue

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