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

And I was beginning to wonder what I was missing...
I'm sure if you search up this thread (either for the 2.0.8 or the 2.0.7 announcement, IIRC), you'll find the proper info.

Without the -c param?  No I wasn't aware of that.  I assumed (I guess incorrectly) that it used the default config if you told it to read from config file w/ -c

You do realise that cgminer automatically uses ~/.cgminer/cgminer.conf if nothing else is specified?

He provided the startcg script also which is why I was wondering where the -c parameter and name of config file is:

startcg

Upstart.


I assume the "/usr/local/bin/startcg" program/script does that.


It's quite obviously a parameter to su. See "man su"

2.0.8 is about 7mh/s slower than 2.0.3 on my HD 6950 =./

Havent tried any versions between 2.0.3 and this one

Interesting setup.  A couple questions
1) What starts miner.conf on boot.
2) You say you use cgminer.conf to handle configuration but I don't see where you reference it (or the -c parameter).  What am I missing?
3) What does the "-c" do in the line "exec /usr/bin/screen -dmS Miner su -c /usr/local/bin/startcg ubuntu"?

As an example of how it may be done. Here's the upstart init script I use on Ubuntu for cgminer. It will start the miner upon booting regardless of any ssh session/login (user name here was "ubuntu" since this install came from a livecd, change to suit).

/etc/init/miner.conf

And my simple startcg script handles environment and starting cgminer.
/usr/local/bin/startcg  (remember to chmod +x)
(you'll note I rely on the cgminer.conf for all options)

When you login with ssh you can type,

sudo screen -r

to re-attach to the cgminer screen. And Ctrl-A Ctrl-D to detach again.
I make an alias so I have less to type. eg.

alias mm='sudo screen -r'

put that in my .bashrc file so it gets loaded at login.

Now just mm attaches me to the cgminer screen.

So what happens if you start one ssh session without x forwarding to run the miner, and another with X forwarding for everything else? Assuming that works, try using 'screen' to detach the miner session  and you might even be able to reattach it in the ssh -X session. Alternatively just start cgminer from a startup script on the mining rig using screen and then reattach the session whenever you want.

I could use plain ssh for mining.  I've been using -X because almost all of my access to the gonna-be-miner system is remote and during setup and configuration it's occasionally useful to open a GUI app.  Remote: home office Macbook Pro; local: homebrew mining rig in laundry room due to power and noise considerations.

More generally, the relation between X Windows and non-display use of GPUs is on my list of things to understand better.  I reason abstractly that it's basically a kludge deriving from the original and still hugely primary use of GPUs for display.

This is quite true of course. I think the above posters problem is simply using instead of just ssh.

You're not forwarding X.
You are accessing X (by having DISPLAY set correctly)
That is required for ADL.
If you don't see Temp/Fan info that means DISPLAY is not set correctly or X isn't running.

Im probably missing something here; but I just log in to my mining rigs using ssh without X forwarding and I run cgminer or any other miner just fine. If I were to forward X, it would try to use the GPU of my local (non mining) machine, which AFAICS is not what youd ever want. Why would you run cgminer executable on the machine that doesnt have the mining GPUs? Perhaps its theoretically possible, but why?

You don't forward X to use the GPU in Fedora, I wouldn't think it would be necessary in Ubuntu either, especially since I sounds like P4Man doesn't.  DISPLAY=:0 is how you access the GPU.  Proofer has mentioned that he's using X to do other things.  I don't understand why he can't make a separate SSH (or even VNC) session for those things, but if he's using screen or running cgminer in the background and keeping that SSH session open anyway, I don't think it's relevant that he's forwarding X since the same problem happens when he logs into the mining machine locally (even if he isn't running cgminer in screen or the background I don't think X forwarding is relevant, I assume he is still using DISPLAY=:0 to access the GPU).

EDIT:  BkkCoins beat me to the response regarding X, however, I've been wondering this for a while:
Proofer:  Can you remove overclocking from your GPUs just to test and see if this takes away (or delays) the lockup behavior?  It seems awfully quick to be a GPU lockup, but I don't really know what else it could be and it sounds an awful lot like a GPU lockup to me (maybe your PS is going bad or one of your GPUs is getting hot too fast for airflow/fan reasons).

EDIT2:  I don't remember if you said you were using --auto-gpu and auto-fan or not, but for the record, --auto-gpu locks up my single GPU eventually (--auto-fan may as well, I don't remember now), and I assume it's a GPU problem since so many people have success with those options.

I never forward X. I just ssh in and use Screen to view the cgminer status info. This has always worked fine for me. Screen allows me to detach and do other things on the miner while cgminer still runs, and also exit and come back later. While X needs to be running on the miner machine I don't think it needs to be forwarded. I've also noticed on the miner machine that when I logged in thru the gui the GPUs behaved differently and sometimes there was problems. Since I don't even have displays connected nowadays I never do that. Just ssh.

BTW is there some reason cgminer would have higher reject rates? I used to use phoenix and always got around 0.5-0.7% rejects but ever since using cgminer it's been between 4-8% typically. Not sure if it counts differently or what, but that's a pretty big difference. Seems to not matter which pool as I've tried ArsBitcoin, MtRed, Eclipse and get roughly the same.

Because the GPU driver through X does the mining. i.e. you must use X and the GPU driver to mine with. They are absolutely essential (at this stage).

Aaah, gotcha. But why on earth would you forward X for mining?

If he ssh's into the machine with X forwarding active, the output will be from the machine he ssh's in from. The glxinfo command may be less confusing (local: ATI on debian; remote: NVidia on Ubuntu):


As you can see the "OpenGL ..." strings come from the local machine, not the one I ssh'd into.

? If you ssh in to the machine, that output is from the ubuntu rig, not your mac.
 
Just to make sure, can you ssh in to the ubuntu machine and run


and post the output?

Nah, that's the display on my Mac from which I'm ssh'ing to the Ubuntu system.  The DISPLAY variable had that "display" in it, so that's what fglrxinfo reported on.