Topic: CGWatcher 1.4.0, the GUI/monitor for CGMiner and BFGMiner to prevent downtime - page 7. (Read 180450 times)

Hi there Vladman,

Maybe this will solve your problem:
Just run your .bat file to start CGminer without CGwatcher running. Then in cgminer type: S then W and press Enter. A cgminer.conf file will now be saved in your CGminer directory. Now stop CGminer, and start CGwatcher. If configured correctly, CGwatcher will automatically start CGminer and start hashing now that there is a cgminer.conf file to start CGminer instead of your batch file. After that you can edit cgminer.conf to set the different settings for both your cards. Separate each cards value by a comma:

"lookup-gap" : "2",
"intensity" : "20,18",
"worksize" : "256,256",
"thread-concurrency" : "32765,24000",
"gpu-engine" : "1000,950",
"gpu-fan" : "0-95,0-100",
"gpu-memclock" : "1500,1250",
"gpu-memdiff" : "0,0",
"gpu-powertune" : "10,20",
"gpu-vddc" : "0.000,0.000",
"temp-cutoff" : "95,90",
"temp-overheat" : "85,80",
"temp-target" : "80,75",
"gpu-threads" : "1"

You can just set the threads as 1,2 in cgwatcher config file setup thingy, then the first card gets 1 thread, the second gets 2.

Im not sure how it would exaclty look in the config file, but the setup thingy fills in your config file for you!

Cheers

Hi,

I've happily been using CGWatcher (v. 1.3.5.2, and Windows 7 Enterprise SP1) for the past couple of weeks and it's been running great, thanks for creating this really cool software!

I've now added a second card into my PC and want to run two instances of CGWatcher.  I read the instructions, and created two separate folders, and pointed each instance at its own API port.

It all works, but for one issue.  I'm not using the conf files, instead I'm using bat files. So each instance is pointing to its own bat file. It works ok, except that whenever each instance is (re-)started, it applies the overclock (memory and engine) settings from its bat file to the other (running) instance as well, and vice versa!  I can then change them back manually, either through CGWatcher or cgminer, and they stay correct until either instance needs to be restarted, at which point, its values overwrite and apply to the other card/instance.  It's odd, because only those two specific parameters seems to do this, and other parameters remain confined and only applied to the corresponding card.

I'm using two instances because I'm using two different cards (an R9 270 and an R9 280X), and the 270 needs gpu threads to be set at 1, and 280X at 2. I'm probably not doing this the best way, and intend to do more research and optimize it better, but I thought I'd try this in the mean time.

I'd be very grateful if you could offer some tips.

Many thanks!

Hello,

I'm having an issue with CGWatcher.
When CGWatcher launch cgminer (3.7.2) it detects the process and monitor them correctly.

However, I start my miners using a batch file which start an app which start the miners.
In that case, CGWatcher isn't able to connect to CGMiner processes and skip them (cannot find the processes from the logs).

Is it because of a 64 bits OS and the CGMiner process shows as "CGMiner *32" instead of "CGMiner" only?
Is it a requirements that CGWatcher must launch CGMiner?

Thank you

I've been having a little problem with sgminer as well.

If I have been mining and I hit the button to stop mining to do other things for a while 95% of the time the sgminer window freezes up when I hit the start nining button.

Any ideas?

Thanks.

I've been having an issue with CGwatcher not restarting sgminer when it shuts down on itself, even though the monitor option to watch for the miner to only be closed by cgwatcher sometimes I will wake up and the computer will be on with everything running except sgminer and the cgwatcher will only say "not mining" but it won't restart sgminer, I have to click on start mining and it's getting annoying because this seems to only happens 10 minutes after I go to sleep and have a couple of miners not doing shit for 8 hours 

Hiya Guys,

I must say that I LOVE cgwatcher, though my new mining rig isn't mining stable while under windows.
It mysteriously shuts off the mobo / monitor or just hangs.

Under xubuntu or SMOS linux, it's 100% stable.

Would there be any possibility to run cgwatcher, or it's options as auto-restart when < x devices & < x khash on a SMOS linux or xubuntu OS?

Cheers,

CGRemote currently will only run one instance per computer. This is by design, because it would require less resources to have one instance with all of the miners rather than two instances - each with half the miners. If you prefer to use two instances anyway I'll remove the limit in the next update. Similar to running multiple instances of CGWatcher, each CGRemote instance will need its own folder.

I'm wanting to run multiple instances of CG remote (2 to be exact, to keep farm hashrate split in two). The CG watcher info for how to run multiple instances doesn't seem to work with CG remote.

Any help?

Shenrox:  Thanks for the help answering questions.


Starscream:  When I get the time to create a "restart miner/computer if hashrate exceeds N" monitoring option as mentioned above, I'll also add a "restart miner/computer if work utility falls below N" option. It might be a couple weeks before I can get to it (I'm in the middle of moving at the moment), but they're both on the to-do list.


Degolep:  You know that you can tell CGWatcher to launch a batch file instead of pointing to the miner executable, right? In the Profile Manager window, for "Miner Path"... point it to your batch file and CGWatcher will launch that instead of *miner.exe. If you do this or are already doing it and are seeing different hashrates with/without CGWatcher, go to the Tests tab and locate the Debug Reports & Utilities section halfway down the window. There is a drop-down list on the right - select "Show last miner start configuration" and click Run. This will show your config settings and the exact settings CGWatcher used when it last launched the miner. They should be pretty much identical, but if you see anything that is changed that shouldn't be please let me know. It doesn't really change any settings aside from enabling the API if necessary and it may list a few additional settings but at their default values. Nothing that should affect hashrate.

I use two different cgminers(same version) one for the night when I pump out everything I can from my 7950 and one for the day when I use my computer.

But at night I use cgminer withour cgwatcher with settings:
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer.exe --scrypt --auto-fan -o stratum+tcp://stratum2.dogehouse.org:943 -u u.pw -p pw --thread-concurrency 21568 --lookup-gap 0 -w 256 -I 17 -g 1 --gpu-engine 880 --gpu-memclock 1250

With these settings I get around 525KH/s

But if I use cgwather and put thread concurrency 21568 and intensity at 20 I get like 60KH/s. But if I use threadconcurency 16862 intensity at 13 I get 470KH/s. So I dont get it what CGminer doesnt like . Its an awesome program but I just dont get it how can I get past 500KH/s with cgminer.

Mining DOGE

Maybe it has been asked, and in that case I'm sorry for the double question, anyway, my question:

Is there a way, similar to how the "restart 'miner/computer' if hashrate falls below 'xxxx'" to have the miner/pc restart if the work utility falls below a certain threshold? I had a case right now where my WU dropped significantly while my KH/s stayed the same. Had to restart SGminer to resolve this, but still, would be nice if CGWatcher had the option to exclusively monitor WU - it is the major factor that counts after all.

Good to hear. If you don't use the dummy plug windows 8 disables the GPU after about 1-2 hours.... Mine does
I tried the dummy plug but then still had a few issues, so now i use the crossfire x adoptor, but DON'T enable it in windows. Seems to be working for me.
When mine gets sick i don't have to reboot the pc, but after installing the dummy plug or xfire cable, i only have to restart the miner...

thanks man, I update my config for 3rd card and I resolved my first problem.

I'm running Win 8 and AMD Catalyst version 13.11. No screen plugged into any of my cards and no dummy plugs as well. Probably Win8 is handling that better way.

on other hand I can see after some time running continuously two of card reports some HW errors in cgwatcher device stat. But once I resolved proper restart I can reboot rig one device is sick

Whats your hardware setup? It almost looks like your running win 7 or earlier and only have 1 screen plugged into the main card. Have you got a "dummy" plug plugged into the second card, because windows disables one card automatically if it's not plugged into a screen...
You also only have settings set for only 2 cards and not 3, so 1 cards will default to it own settings......
Also, try running CGWatcher as an administrator..

Lol, my 2 cents, i had a similar problem a while ago.

Hi guys
I need your help

My rig
Intel MB ASROCK H77 Pro4/M, Celeron CPU, 8GB RAM, 3x SAPPHIRE R9 280X TOXIC

My config
--scrypt  -o stratum+tcp://vtc.poolz.net:3333 -u XXX -p XXX -v 1 -w 256 -I 13 -g 2 --lookup-gap 2 --gpu-powertune -20,-20  --temp-overheat 89,89 --temp-cutoff 90,90 --gpu-memclock 1500,1500 --gpu-engine 1000,1000 --thread-concurrency 8193

I'm mining vertcoin where is necessary modified CGMINER (see http://vertcoin.org/)


I've got two problems with my rig I cannot get on
1. After first start, automatic or manual restart of CGWATHER one card has different gpu-memclock and gpu-engine values like other two,  like it's defined by config, it gets gpu 1150 mem 1600 and therefore  it runs lower Hashrate. After I correct it in CGWATHER GUI the card start working fine. After restart it happens again.

2. Time to time I found my rig not mining and when I start it one card cannot start. It shows 0 hash rate and after another restart it marked the card sick. This can be easily solved by automatic rig restart, but after that it runs lower hash rate due to issue #1.

btw my log https://gofile.me/24UHK/Nsar3pWa

Guys, any advice appreciated!

  Thanks, will send something ur way when i exchange next time.
This driver issue is really killing my hahsrate, by as much as 50% 

Shenrox:  I put this option on the to-do list. I'll try to get it in one of the next few updates.


Ntrain2k:  Yeah this seems more like a cgminer issue than a cgwatcher issue. If the miner runs fine when started at 19 but crashes when started at a lower intensity and then changed to 19 (all cgwatcher is doing is sending the 'intensity' command with the new value), it would be a problem with cgminer changing intensity while mining. I haven't experienced this myself... maybe try an older version of cgminer? I use 3.5.0 myself. I don't know of any GPU-related improvements between 3.5 and 3.7.2 that you'd be missing out on. As someone who write software, I'd almost always recommend using the latest versions of software. But cgminer has been focused on ASICs for quite some time... so if you find an older version that works, you might as well stick with it (unless you move to a project with active GPU development like sgminer).


tthieu24:  Were there any other windows open? Did it look like Windows was trying to shut down (e.g. it closed other open programs)? I've made a change to CGWatcher to kill itself after it initiates the shutdown, rather than waiting for Windows to close it. This may help if CGWatcher was causing the hold up... but if this was the case I think it would have been reported before. This change will be in the next update.


kimocoin:  I just wanted to let you know I'm still hunting this down. I'm moving to LA in a few days (driving from Ohio so will be on the road a few days), so it may be a week or two before I can really spend time on it. But I will get it fixed, even if it kills me.

I have 2 rigs, one with 3x XFX R9 290's, and one with 1 Asus R9 290.
Note: All 3 cards are elevated from the mobo by riser cables pcieX1 to pcieX16.
The rig with 3 cards is the one that is giving me these frozen miner windows. One day everything is fine, mining the whole day into the next. Then another day it freezes up to a couple of times. I just can't seem to figure out what could be causing this. Perhaps a new cgminer process is starting too soon after killing the previous cgminer.exe  I'm just guessing here.
The single card rig hasn't had any problems at all mining under cgwatcher supervision.

Just now another failed cgminer restart, this is from cgwatcher.log:

[8-2-2014 15:24:33]          Accepted shares have not changed for 5,033333 minutes, longer than the threshold of 5 minutes. Attempting to restart...
[8-2-2014 15:24:33]      [d] Miner.Restart begin.
[8-2-2014 15:24:33]          Restart CGMiner was requested, preparing to stop then start the miner to make sure its configuration settings are reloaded...
[8-2-2014 15:24:33]      [d] Miner.PerformStopStartRestart called. (Profile=Digger;Miner=C:\cgminer-3.7.2-windows\cgminer.exe;HasFullAPIAccess=True;Initiator=Monitor;Reason=#NAME# was successfully restarted.)
[8-2-2014 15:24:33]      [d] Miner.StopMining called: Miner=C:\cgminer-3.7.2-windows\cgminer.exe;ProcessID=4728 (True);BatchProcessID=0 (False);Config=C:\cgminer-3.7.2-windows\cgminer.conf;Arguments=--config C:\cgminer-3.7.2-windows\cgminer.conf;HasFullAPIAccess=True;KillOnReadOnlyAccess=True;IsBatCmdFile=False;ProcessID=4728;.
[8-2-2014 15:24:34]          CGMiner process closed outside of CGWatcher!
[8-2-2014 15:24:34]      [d] Miner.StartMining (for restart) called. [Profile=Digger;MinerFile=C:\cgminer-3.7.2-windows\cgminer.exe;MinerFileUsed=C:\cgminer-3.7.2-windows\cgminer.exe;MinerExecutable=C:\cgminer-3.7.2-windows\cgminer.exe;Config=C:\CGWatcher-1.3.5\temp.conf (C:\cgminer-3.7.2-windows\cgminer.conf);Arguments=--config C:\CGWatcher-1.3.5\temp.conf;Anticipated Port=4028;Used Port=4028;HasFullAPIAccess=False;IsBatCmd=False;BatCmdPath=C:\cgminer-3.7.2-windows\cgminer.exe (C:\cgminer-3.7.2-windows\cgminer.exe);LastKnownInstanceCount=0/0]
[8-2-2014 15:24:35]      [d] Miner.IsProcessAlive(4792) returns True. [First try, process is alive.] (CPID4792/CMPID=4792/CBPID=0)
[8-2-2014 15:24:35]      [d] Waiting for CGMiner to initialize API. Process 4792 alive=True, minerid=4792.
[8-2-2014 15:24:36]      [d] Watch for miner, expected process is 4792 (alive).
[8-2-2014 15:24:36]      [d] CGMiner process is running using ProcessID 4792, expecting port 4028.
[8-2-2014 15:26:15]          CGMiner process closed outside of CGWatcher!
[8-2-2014 15:26:15]      [d] Finish wait for miner to start, process is 0 (not alive).
[8-2-2014 15:26:15]      [d] CGMiner process 0 not alive at Miner.StartMining exit.
[8-2-2014 15:26:15]          Start miner failed on 1st attempt. Killing any remaining processes and trying again.
[8-2-2014 15:26:15]      [d] Miner.IsProcessAlive(4792) returns False. [First try, test process is nothing.  ex: Process with an Id of 4792 is not running.] (CPID0/CMPID=0/CBPID=0)
[8-2-2014 15:26:15]      [d] Miner.StartMining (for restart) called. [Profile=Digger;MinerFile=C:\cgminer-3.7.2-windows\cgminer.exe;MinerFileUsed=C:\cgminer-3.7.2-windows\cgminer.exe;MinerExecutable=C:\cgminer-3.7.2-windows\cgminer.exe;Config=C:\CGWatcher-1.3.5\temp.conf (C:\cgminer-3.7.2-windows\cgminer.conf);Arguments=--config C:\CGWatcher-1.3.5\temp.conf;Anticipated Port=4028;Used Port=4028;HasFullAPIAccess=False;IsBatCmd=False;BatCmdPath=C:\cgminer-3.7.2-windows\cgminer.exe (C:\cgminer-3.7.2-windows\cgminer.exe);LastKnownInstanceCount=0/0]
[8-2-2014 15:26:16]      [d] Miner.IsProcessAlive(4340) returns True. [First try, process is alive.] (CPID4340/CMPID=4340/CBPID=0)
[8-2-2014 15:26:16]      [d] Waiting for CGMiner to initialize API. Process 4340 alive=True, minerid=4340.
[8-2-2014 15:26:17]      [d] Watch for miner, expected process is 4340 (alive).
[8-2-2014 15:26:17]      [d] CGMiner process is running using ProcessID 4340, expecting port 4028.
[8-2-2014 15:26:22]      [d] CGMiner running and API initialized on port 4028, process matched to profile Digger.
[8-2-2014 15:26:22]      [d] Finish wait for miner to start, process is 4340 (alive).
[8-2-2014 15:26:22]          CGMiner was successfully restarted.

FYI for all, give SGminer a shot. I was able to clock my card quite a bit higher with it than with cgminer. Seems to be more stable than CGminer.