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

You will need to enable the server mode yourself.

Go here: https://en.bitcoin.it/wiki/Running_bitcoind

Note that bitcoin-qt will run as a server when you have bitocin.conf in the right place, and then bitcoind will connect to it for other commands.  IOW, you can still have your GUI if you use it, although running bitcoind as the server instead of bitcoin-qt might be more stable / safer.

Yep, works fine.

im wondering does the windows version work with bfl singles

i just bought a bfl single in feb and need to know since i am running windows

thankyou

If you start cgminer as follows:
(where .... .... .... are of course whatever options you normally use like:
-Q 2 --api-listen --gpu-engine 700-825 700-825 700-830 700-815 700-820 700-830 --gpu-memclock 240 --auto-gpu --auto-fan --temp-target 75 -I 8 -o http://gpumax.com:8332 -u x-p x -o http://x:80 -u x -p x)
then you can use more/less on the log file it creates in the current directory

or save in a directory somewhere else like:

N.B. you can call the log file anything you like e.g. file.log
but I add that other stuff to ensure the filename is unique and easy to sort and see when it was started

Edit: But that won't show the G key output when you press the G key.
It simply logs all output that cgminer normally outputs in the scrolling window - not when you press keys and see other extra output.
the -D and --verbose options will add more output to the scroll area that will also go in the log file but that will be a lot more data.
However, in your case, that would be advisable to be able to see what's going wrong.

Is there anyway to | more or | less the gpu management output?  on my ssh session, I only see the last 2 threads... even if i make the screen as big as I can, I only get the last 3 gpu's... I could always bump my resolution, but wondered if there was another way to do it.

Go into the GPU menu while it's running, it shows the last initialised time. If it's not about the same time that you started cgminer (listed at the top) then you know it's been re-initialised.

The GPU's are showing Temp/RPM as you can see - so yep that means ADL is working.
That's all I was thinking there that maybe ADL wasn't able to get the Temp/RPM for some reason (even if the DISPLAY was set) so the cards were failing all the time.

There's no device failure statistics in cgminer other than HW which is 0 in your case.
Send ckolivas some BTC and ask him to implement it (or if he's not expecting to be able to do that soon - send it to me )
Then I could add a device status command in the API to return those numbers.

Edit: hmm the thread does have the timestamp it was last sick though ...

Yea, I have the export Display=:0 as part of my start script.  I also have export GPU_USE_SYNC_OBJECTS=1... would that cause any issues since there are no 7970's?

Its been running for 6 hours now, but is up to 522 Meg of RAM... however it seems to be able to run longer since I lowered my intensity like ckolivas suggested. 

When I did cgminer on my 7970's, it was real easy to tell a clock issue, as they would get sick and/or die... however, I have not seen any problems like that on here, normally when I log on to check, everything appears normal except RAM usage is going up..... But again, ckolivas explained why this could be since he said the 59x0 series can recover easily.

How do identify issues in cgminer if they don't get labeled sick or dead?  Do I just need to filter the output something like -m idle to see only idle messages?  I trust ckolivas post above that clocks are the issue, but is there away to find which GPU(s) being restarted?

I guess related to that (I mean ckolivas comment above)
Are the GPU's showing Temp & RPM?
If ADL isn't working (e.g. missing "export DISPLAY=:0" or the display isn't available for other reasons) then I guess the cards could just keep failing over and over.

58x0 are amazing hashing beasts for so many reasons, and this is one of them - they're one of the few GPUs that actually recovers after dying a "soft" death and cgminer restarts their threads a short while later. Nonetheless, you should try and find clocks that don't make the GPUs ever crash as I'm pretty certain this is your problem.

Sorry for the confusion, I have 2 rigs with 3 5970's each that have the this issue (so 6 GPU's max in one of my rigs), the 2 rigs with 3 7970's each that work fine.
I haven't noticed a lot of pool swapping... occasionally one core will swap back and forth.

OK, yep I'm just using bad nomenclature.
I simply meant if the device itself was not processing there could only be 2 reasons I can think of
Not getting work or being a problem with it.

Going idle can only be for ONE reason and that is the GPU not responding. Waiting on work from a server or network lag/outage does NOT register a mining thread as being idle. It makes no sense restarting a thread that is just waiting on work.

Hmm OK, so it's effectively 12 devices.
That's a lot of GPU devices

The RSS number is (obviously) what shows if you are using up more RAM and running out of it.
I guess what's needed now is to find out what is happening when that changes ... and does it jump up in steps, or is a gradual rise?

Edit: oh I just noticed another thing ... you have 2 pools and the main is GPUMax - does it swap pools a lot?

They are all 5970's (dual gpu) so those temps are okay. I was actually using Phoenix until I just recently started with cgminer and had those clocks stable on phoenix for several weeks.  Not sure how often BAMT requests via API.  I have BAMT running on 2 rigs with 3 7970's each with same version of cgminer and do not see the issue on there.  I'll try running stock for awhile and see what happens.

OK 53 isn't a big number so it's not what I was considering may be the cause.

The other two numbers there are not big yet either
SZ=185303 RSS=388892
if you have a sizeable number of devices on your rig (your options suggest 6 GPU devices? Are any of them dual?)

My rig has only 4 devices and it reads:
SZ=151618 RSS=127032
(and yes I use the code also from my GIT except I don't enable Bitforce being compiled in, I only add Icarus at the moment)

However, in my case it doesn't run rampant later on.

Definitely getting nowhere with this so far looking at the system process info.

How often does BAMT request status info from the API? And what API requests does it use? (I don't know exactly)
I guess if there was some accidental fast loop missing a delay accessing the API over and over again that might cause issues?
My monitoring in my current setup is a set of 3 API requests every 10 seconds, but in my previous configuration (same code and hardware a week ago) I also added on top of that another 1 API request every second - but that didn't cause extra RAM usage.

I guess I'll defer to the expert (ckolivas)
Going idle can be for two reasons, as you suggested if GPUMax isn't providing you with any work, but of course the normal reason is as ckolivas said, if your setting are too high.

Are those temp settings and clock settings in any way high for your GPU's?
(The numbers themselves don't seem high for many cards - but I guess that depends on what the cards are - and if they are old and no longer stable if OC'd)
Do you ever get any status change on any of the GPU's? (i.e. not Alive)

Oddly enough I am working on a notification Java app that uses the API that might help monitor this problem (that comment above about 3 API every 10 seconds - summary,devs,pools) if it is temp/clock related
(The code already done would be enough)
But I've been expending a lot of effort on threading the data handling part of it (and probably making it too complex) to ensure that blocking code is in threads unrelated to time sensitive code (and then there's the issue of RAM usage in Java that I need to resolve next ...)
So I seem to be talking way longer than I expected to get even a beta out

Here's the information you requested:

root@oconner:/opt/miners/cgminer# ./cgminer --help
cgminer 2.3.1f
Built with GPU bitforce icarus mining support.

root@oconner:/opt/miners/cgminer# ps -eL | grep cgminer | grep -v grep | wc
     53     265    2014

root@oconner:/opt/miners/cgminer# ps -eLF | grep cgminer | grep -v grep | tail -1
root     27782 27781 27188  0   53 185303 388892 0 18:25 pts/1    00:00:00 /opt/miners/cgminer cgminer -Q 2 --api-listen --gpu-engine 700-825 700-825 700-830 700-815 700-820 700-830 --gpu-memclock 240 --auto-gpu --auto-fan --temp-target 75 -I 8 -o http://gpumax.com:8332 -u x-p x -o http://x:80 -u x -p x

Hey Con. Will you release a version with kanos work that supports mining with Icarus and BFL (windows7, 2.3.1f) ? There is a 7.5 BTC bounty for that. Would be nice

Some questions regarding this
1) When you run "./cgminer --help" what does the 2nd line "Built with ..." say?

2) run "ps -eL | grep cgminer | grep -v grep | wc" and it will say how many threads there are

3) run "ps -eLF | grep cgminer | grep -v grep | tail -1" will show you the command running cgminer so you can be sure it matches exactly what you said

Then you're onto something. It is dangerous to try and delete the ram used by the old threads because that just leads to a crash, so I specifically made the threads' ram not get cleaned up - so it is expected that ram usage will go up. However, you're doing something horribly wrong if your GPUs are going idle all the time. That's supposed to ONLY happen if your GPUs wedge because you're overclocking them too much and the GPU stops responding. I highly recommend reviewing your temperatures and clock speeds.