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

[RedLine888]

The cooling is not the source of this problem. Clocks are the same as they were when everything was perfect. Temps are perfect as well! It is something with OpenCL but I can not figure out what it is

[1715233662]

1715233662

[1715233662]

1715233662

[DutchBrat]

Try downgrading the AMD drivers.... that helps sometimes

[Schwede65]

I use Aoclbf 1.81 + Phoenix 1.7.0 whith modofied kernel + Cat 12.1 + Windows 7 x64 SP1

i tried cat11.12 installed on cat11.11 / 2 x 6990-rig

multi-gpu-cpu-bug solved BUT hashrate down ~ 5 %

cat12.1 seems to have the performance of 11.12

maybe you have to go back to cat11.11

[RedLine888]

Ok, I will try but the thing is when a VGA works ALONE the hashrate is high as it is used to be. The hashrate drops when I activate the 2nd VGA and drops even more if I activate the 3rd one.

[ancow]

Ok, I will try but the thing is when a VGA works ALONE the hashrate is high as it is used to be. The hashrate drops when I activate the 2nd VGA and drops even more if I activate the 3rd one.

Just out of curiosity, what kind of hardware problems have you eliminated so far?
One reason I can think of why a second card might cause another to slow is that the power supply's output isn't high enough, but I'd expect a much higher impact on hashrate in that case.
What I'd expect to be much more likely is that those graphics cards all use the same bus to communicate with the CPU/whatever, which would result in the behaviour you describe.

One more thing for you to try, though (in case it is a software problem): if you manually set the intensity of the first card (start, say, with 3 and use cgminer's menu to go from there), does that help at all? What effects does that have (on the second and third cards, the effect on the first should be obvious)?

(Just because I'm a little anal about these things: this is what "VGA" means: http://en.wikipedia.org/wiki/VGA)

[bronan]

Redline888 i am sorry to say but you have to accept that multi gpu mining is never gonna be the same as single gpu mining
No matter what driver you try it fairly simple your cpu is dividing control over those 2 or 3 and that costs a bit of time resulting in a minor less hashing speed which i think will allways be present in systems with more then 1 gpu.
Even under the old ati stream you see a small drop in performance but not so much as with opencl i think this has todo with the fact that its an platform independant design to run on nvidia and amd videocards.

When i start a single 5870 on 920 Mhz i get easy 410 Mh average when i put in the second card it drops to  395 Mh i tried every driver which can run cgminer and all with same  result. A single gpu card setup will allways outperform a multi gpu

At least on windows based platform since i not run any linux i cant tell if that has the same performance hit as well.

Second peak performance is a not so good choice for comparing the results i use only average hash speeds for compare a more real performance indication

[nebiki]

the win binaries can't be downloaded here, it keeps saying "c:\temp\blabla.zip.part could not be saved, because the source file could not be read" [firefox, ie says "This download was interrupted"]. it only happens with the win-binaries, though.

anyone else experiencing this problem?

[Proofer]

Summary: cgminer doesn't see GPUs when accessed remotely via VNC.

Ubuntu 10.04, 3x5970, cgminer 2.0.8

When I am logged in on the mining system:

proofer@minerr:~$ cgminer -n
1 GPU devices detected
proofer@miner:~$ export DISPLAY=:0
proofer@miner:~$ cgminer -n
6 GPU devices detected

The VNC server is started on the mining system prior to user login by:
su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1"

Then from the remote:
proofer@miner:~$ export DISPLAY=:1
proofer@miner:~$ cgminer -n
[2011-12-16 06:18:24] Error: Getting Device IDs (num)
[2011-12-16 06:18:24] clDevicesNum returned error, none usable
0 GPU devices detected

Note: "xhost +" (disable access control) doesn't appear to make any difference
Edit: The AMD Catalyst Control Center won't open from the remote, but it does from the local.

[ancow]

The VNC server is started on the mining system prior to user login by:
su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1"

[...]

Edit: The AMD Catalyst Control Center won't open from the remote, but it does from the local.

That last bit should be a hint: the fglrx driver is obviously not loaded by vncserver, so neither CCC nor cgminer can access it.

[The00Dustin]

proofer@minerr:~$ cgminer -n
1 GPU devices detected
proofer@miner:~$ export DISPLAY=:0
proofer@miner:~$ cgminer -n
6 GPU devices detected

The VNC server is started on the mining system prior to user login by:
su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1"

Then from the remote:
proofer@miner:~$ export DISPLAY=:1
proofer@miner:~$ cgminer -n
[2011-12-16 06:18:24] Error: Getting Device IDs (num)
[2011-12-16 06:18:24] clDevicesNum returned error, none usable
0 GPU devices detected

Just guessing here, but isn't Display :1 a VNC display that doesn't have a GPU attached?  If you were connected via SSH you would still use DISPLAY=:0.  Did you try using that from VNC?  Note this might not work if no one is logged into display 0 or if someone else is (perhaps doing the same as root would allow you to access display 0 regardless, but I haven't tried that) based on my experience running cgmine through ssh on Fedora 15.

[Proofer]

The VNC server is started on the mining system prior to user login by:
su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1"

[...]

Edit: The AMD Catalyst Control Center won't open from the remote, but it does from the local.

That last bit should be a hint: the fglrx driver is obviously not loaded by vncserver, so neither CCC nor cgminer can access it.

Makes sense so far.  (Bear with me please; as yet I'm a toddler.)  Now, what do I have to do to load the driver at about the same time as vncserver is started?  (I put the latter, quoted above, in /etc/rc.local .)  In other words, the driver installation process created or modified some system file that causes the driver to be loaded; where would I look for that to see what I have to do?

[Proofer]

Just guessing here, but isn't Display :1 a VNC display that doesn't have a GPU attached?

Yes.

If you were connected via SSH you would still use DISPLAY=:0.  Did you try using that from VNC?  Note this might not work if no one is logged into display 0 or if someone else is (perhaps doing the same as root would allow you to access display 0 regardless, but I haven't tried that) based on my experience running cgmine through ssh on Fedora 15.

I am not currently connected via SSH and would prefer to avoid any extra overhead -- remote display speed reduction -- it might impose. Security is not an issue as both the rig and the remote are on the same LAN behind a firewall/NAT.  No one is logged into display 0, the physical display attached to the rig; it's sitting at Gnome's login screen.  The aim is a headless miner that requires no local presence.

[ancow]

The VNC server is started on the mining system prior to user login by:
su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1"

[...]

Edit: The AMD Catalyst Control Center won't open from the remote, but it does from the local.

That last bit should be a hint: the fglrx driver is obviously not loaded by vncserver, so neither CCC nor cgminer can access it.

Makes sense so far.  (Bear with me please; as yet I'm a toddler.)  Now, what do I have to do to load the driver at about the same time as vncserver is started?  (I put the latter, quoted above, in /etc/rc.local .)  In other words, the driver installation process created or modified some system file that causes the driver to be loaded; where would I look for that to see what I have to do?

I don't really know vncserver, so I don't know how to configure whatever X server it uses.
The file where the fglrx driver is loaded is usually /etc/X11/xorg.conf. It should contain something like the following:

Code:

Section "Device"
        Identifier  "aticonfig-Device[0]-0"
        Driver      "fglrx"
        BusID       "PCI:1:0:0"
EndSection

(The important part being Driver "fglrx")

It is probably easier to simply start a normal X server with your normal user and simply set the DISPLAY variable accordingly, like The00Dustin suggested.

[Proofer]

It is probably easier to simply start a normal X server with your normal user and simply set the DISPLAY variable accordingly, like The00Dustin suggested.

OK, I will do some research on how I might do that.

[Proofer]

It is probably easier to simply start a normal X server with your normal user and simply set the DISPLAY variable accordingly, like The00Dustin suggested.

OK, I will do some research on how I might do that.

A dollop of research:  if I log in on the miner, then connect the VNC client and from it issue...
DISPLAY=:0
cgminer -n
...the report is 6 GPUs.

Without logging in on the miner, or after logging out there, that doesn't work (no fglrx driver).

Another dollop:  Linux Headless Ubuntu with VNC looks like it has some useful ideas.

[ancow]

It is probably easier to simply start a normal X server with your normal user and simply set the DISPLAY variable accordingly, like The00Dustin suggested.

OK, I will do some research on how I might do that.

A dollop of research:  if I log in on the miner, then connect the VNC client and from it issue...
DISPLAY=:0
cgminer -n
...the report is 6 GPUs.

That's why I said to start a new X with your user... ;-) The one on :0 is owned by root and you can't access it.

Try these lines in /etc/rc.local:

Code:

su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1" &
su proofer -c "X :2" &

After a reboot you should (hopefully) have a new X server started on :2 and be able to use DISPLAY=:2 within your vnc session to access it.

[Proofer]

That's why I said to start a new X with your user... ;-) The one on :0 is owned by root and you can't access it.

Try these lines in /etc/rc.local:

Code:

su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1" &
su proofer -c "X :2" &

After a reboot you should (hopefully) have a new X server started on :2 and be able to use DISPLAY=:2 within your vnc session to access it.

I perhaps don't understand what you mean by "access it" but doing only those two things -- the rc.local addition and "export DISPLAY=:2" -- does not enable cgminer to see the GPUs.

[ancow]

That's why I said to start a new X with your user... ;-) The one on :0 is owned by root and you can't access it.

Try these lines in /etc/rc.local:

Code:

su proofer -c "cd ~proofer && vncserver -geometry 1600x1000 :1" &
su proofer -c "X :2" &

After a reboot you should (hopefully) have a new X server started on :2 and be able to use DISPLAY=:2 within your vnc session to access it.

I perhaps don't understand what you mean by "access it" but doing only those two things -- the rc.local addition and "export DISPLAY=:2" -- does not enable cgminer to see the GPUs.

Shame, that was the idea. Can you try something like run xterm after the "export DISPLAY=:2" to see whether that X server started at all?
If not, you need to find out where Fedora stores the boot log/output of rc.local to see whether there are any fixable errors after the "su proofer -c "X :2" &" call. if that doesn't work, replace that line by "su proofer -c "X :2" > /path/to/log 2>&1 &" to find out what goes wrong. You may also check /var/log/Xorg.2.log if the X server starts, then quits.

If all this doesn't get any results, I'm fresh out of ideas. ;-)

[Proofer]

... Can you try something like run xterm after the "export DISPLAY=:2" to see whether that X server started at all?
If not, you need to find out where Fedora stores the boot log/output of rc.local to see whether there are any fixable errors after the "su proofer -c "X :2" &" call. if that doesn't work, replace that line by "su proofer -c "X :2" > /path/to/log 2>&1 &" to find out what goes wrong. You may also check /var/log/Xorg.2.log if the X server starts, then quits.

If all this doesn't get any results, I'm fresh out of ideas. ;-)

Here is the sad story:

proofer@miner:~$ export DISPLAY=:2
proofer@miner:~$ xterm
xterm Xt error: Can't open display: :2

su proofer -c "X :2" > /home/proofer/Desktop/log.txt 2>&1 &

X: user not authorized to run the X server, aborting.

[Proofer]

Wow way to turn something relatively simple into a convoluted  mess. I go back few post and read ubuntu 10.04 for the OS now your talking Fedora how did that get included here?

Yes, the wrong distro was mentioned but I didn't think it was important enough to correct.

Somehow you have the mistaken belief that ssh takes more resources than this VNC mess your trying to do. Here is an idea for you boot your linux box so it is sitting at the desktop login then ssh into the box and use DISPLAY=:0 cgminer to start it up and mine. And you may have wanted to install then use the screen program before that cgminer start up command to be able to detach the session to reuse the terminal/close it entirely while still having the mining running.

I removed the vncserver invocation from /etc/local.rc, rebooted the Ubuntu system, and then on the Mac:

Code:

~ $ ssh proofer@192.168.168.101
proofer@192.168.168.101's password: 
Linux miner 2.6.32-36-generic #79-Ubuntu SMP Tue Nov 8 22:29:53 UTC 2011 x86_64 GNU/Linux
Ubuntu 10.04.3 LTS

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/

Last login: Fri Dec 16 15:53:53 2011 from sbmbp-2.local
proofer@miner:~$ export DISPLAY=:0
proofer@miner:~$ cgminer -n
No protocol specified    # <---- Haven't seen this before
[2011-12-16 15:56:02] Error: Getting Device IDs (num)
[2011-12-16 15:56:02] clDevicesNum returned error, none usable
0 GPU devices detected