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

I don't get the point of cgwatcher, for me it seems useless. When I was mining with cgwatcher one of my gpu's overheated and shut down. Cgwatcher noticed it and set the gpu from "dead" to "rest", but didn't make the gpu work again. Manual cgminer restart fixed the issue.
Another time one gpu went down to only 60% performance and cgwatcher did nothing to fix this. A restart solved this issue.

So in which cases exactly does cgwatcher help you? Cause in those mentioned above cgwatcher doesn't fix anything.

Milone,

FWIW, I solved my issue, though I don't know why it works with one version and then not later.  I changed my config's kernel line to: , instead of:   and it now works in your latest version.   thanks!

I downloaded CGwatcher 1.3.4.6 yesterday and my problem with the blank window hasn't occurred since.  If it does occur again, I will try your test build.

After this happens (miner flashes then disappears), if you go to Tests tab and click Create Debug Report and email it to me, I can look for a cause. It's impossible to say what is happening without more information. You can also try the latest test build (http://bit.ly/cgw134test) to see if it works any better.
[/quote]

here you go:http://pastebin.com/qVPkpr7v  i dont really care about the passwords=)

FYI, I tried installing a fresh copy of Cgwatcher, 1.3.4.7 (your test copy on your site) and pointed it at one profile, created from scratch, and using bfgminer 3.9.0 x64, same results...bfgminer just flashes on the screen, and i get a message saying it couldn't connect to the bfgminer api.

If you think it is due to CGWatcher merely running you can easily test this by launching the miner with CGWatcher closed, wait five or ten minutes for the hashrate to stabilize, then open CGWatcher and see if the hashrate drops. To date, any time someone reports a lower hashrate using CGWatcher it has been due to gpu-threads. Yeah I see it now in your post... I had scanned through it looking for gpu-threads and forgot about -g.

The only reason you'd have a different hashrate with or without CGWatcher then is a config setting. You can see the exact config settings CGWatcher used the last time it launched the miner by going to the Tests tab. In the Debug Reports & Utilities drop-down (middle of the window), select "Show last miner start configuration" and click Run. It will show the original config settings and the used config settings. It shouldn't change any, but it may add some, like enabling the API. If you find anything different that shouldn't be, please let me know.

Also, obviously make sure you're using the latest version as it may have bug fixes or improvements over older versions. The latest is 1.3.4.6, but I also have a test build you could try here: http://bit.ly/cgw134test

I already read that somewhere but my gpus (280x) run better with 2 gpu-threads, so I always specify it in the .bat or .conf file (as you can see in the settings I wrote here).
By the way, disabling monitoring on CGWatcher I get exactly the same hashrate than starting cgminer directly, so it isn't due to a gpu-thread wrong setting

If you are getting a lower hashrate with CGWatcher it is most likely due to the gpu-threads setting.

CGMiner's readme stated that the default value of gpu-threads was 2. However, if you ran CGMiner without setting this, it would actually run at 1 gpu-thread.

So to be consistent with the readme, CGWatcher sets the default value to 2. This means to get the same hashrate with CGWatcher as you do without CGWatcher, you may have to set gpu-threads to 1.

I've updated the readme to state this, which will be in the next version. This has been how it works for quite some time, so if I were to change its behavior now it would affect other users who expect it to be 2.

Hi,

I noticed when I start cgminer with CGWatcher, my hashrate is lower and HIGHLY more unstable.
Usually it grows to his peaks and then drops for about 80-120 KH/s per gpu, then it grows again and drops again, and so on every few seconds.
Apart from that the overall hashrate is lower, starting cgminer directly I get from my gpus an average of 750 Kh/s per card, starting from CGWatcher my average is about 710 KH/s per card.

After two days changing settings, miner arguments, switching between .bat or .conf files, trying different cgwatcher versions, it comes out that it is the Monitor feature to cause this issue.
Enabling monitoring every 10 seconds for example, when the graph and the stats are updated, the hashrate drops instaneously about 40-50 KH/s (per gpu) and continuing to drop for about 1-2 seconds, then the hashrate recovers until the next monitor update.
I tried to edit the delay of the refresh but this of course only postpones the problem, currently I'm using 30 minutes and although this setting allows the average hashrate to decrease almost imperceptibly, I'm worried that a GPU becomes sick or something goes bad in those 30 minutes...
Obviously disabling the monitor solves this issue but CGWatcher without monitor loses a lot

There are my settings if can be helpful:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
del *.bin
cgminer.exe --scrypt -w 256 -v 1 -I 13 -g 2 --lookup-gap 2 --thread-concurrency 8192 --gpu-memclock 1500,1500,1800,1800 --gpu-engine 1080,1080,1120,1120 --gpu-fan 30-70 --temp-overheat 86 --temp-cutoff 90 --auto-fan


Btw, thank you for this wonderful software

Can you try this test build (http://bit.ly/cgw134test) and see if it improves this issue?



Thanks, good to know there is a solution. I may have to create a batch file then when creating autorun entries in Windows 8.



After this happens (miner flashes then disappears), if you go to Tests tab and click Create Debug Report and email it to me, I can look for a cause. It's impossible to say what is happening without more information. You can also try the latest test build (http://bit.ly/cgw134test) to see if it works any better.

Last 3 versions have not worked for me.  I had 1.3.4.3, and it worked great, but 1.3.4.7, 1.3.4,6, and 1.3.4.5 all don't work.  When they launch, everything looks good, but they NEVER start bfgminer.   I get a dos box momentarily that just flashes away, and then CGwatcher says it couldn't start/communicate with bfgminer.  Since 1.3.4.3 is not posted on your site, I had to go back to 1.3.3.3, which works fine.  I tried again going back to any of the above and can repeat the problem.

I've found a simple workaround for the Win 8 & not starting up issue.

Just create a simple bat file "c:\cgwatcher\cgwatcher.exe"  place it in your start up folder (start - run - shell:startup )..works a treat 

The setting "Kill miner and try again if mining hasn't started within 60 seconds" is enabled.
I think what could be it in this case, is that the blank window isn't a cgminer.exe process at that moment. Eventhough it says cgminer.exe in the window title.
All the other times I think it works fine I guess.  

I managed to make screenshots this morning.
The CGWatcher log stated: "cgminer closed outside of cgwatcher."

http://tardis1.tinygrab.com/grabs/d81565c15a85db686a8081564355a745789f565365.jpg
http://tardis1.tinygrab.com/grabs/d81565c15a5bc9f4439351984156e78410e103b052.jpg

yes i know but when i don't specify a coin for the multipool-profile i can't make a shedule with it

when i set for example the multipool to litecoin it works
perhaps you could add multipools to the coinchoose-dropdown?!

I like the idea. I'll put it on the list, but no guarantee on how soon I'll be able to get to it.



If I don't get back to you within a few days please email me again. I don't know whose brilliant idea it was to maintain two programs at the same time... but at least I never get a chance to be bored any more.



If the miner is just a blank window for more than 60 seconds upon starting, CGWatcher should kill it and try launching again. This number of seconds can be changed by going to the Monitor tab, then the Other sub-tab. The setting is called "Kill miner and try again if mining hasn't started within X seconds". If this didn't work or I am not understanding you correctly, please let me know. You mention you noticed it happened twice... are there other times where it works without incident?




You can create scheduled actions to switch to specific profiles, as well as profiles based on profitability. So you can create a scheduled action to switch to the Multipool profile, and then another action to switch to most profitable profile. You can create them 24 hours apart and set them to run at 48 hour increments, or create a scheduled action for each day of the week, alternating the profile for each day.

Which Coin should i set, when i mine multipool.us?
i can't set a shedule action when i don't set all coins to the profiles.

does it matter or not which coin i choose?

i want to switch every 24h hours between HBN and Multipool

thanks

I've noticed already twice in the past two days that CGminer.exe was killed by CGWatcher after which CGminer was restarted but only an empty DOS box appeared.
Then CGWatcher appeared to be stuck as I could only see an empty CGWatcher window.  I closed the DOS box and CGWatcher "unfroze" and Cgminer restarted again and started mining.
I'll make a screenshot next time this happens.
My miner was down for 8 hours because of this.   (This is what I was hoping CGWatcher would prevent from happening.)
I've set the option to always kill cgminer.exe instead of shutdown command.


I'm using 3 XFX R9 290's on an Asus B85-Plus mobo with 8GB and an Intel i3 cpu powered by 1200W Club3D psu.
Windows 7 x64, CGminer3.7.2, CGWatcher1.3.4

If after killing CGminer.exe a pause of like 5 seconds is implemented before CGminer.exe is restarted by CGWatcher, would that maybe solve the problem?

thanks for your answer
well i don't know why but on my main rig i get full-hashrate with cgwatcher / cgminer

i think it has to be something with my test-rig ... but now it works again 

Send u an email a couple days milone. Don't know if u received it.

A feature request I have is we can give the GPU's a custom name on the devices tab, i run different branded cards & have a bad memory & poor handwriting

I will add this option soon, it's been on the to-do list.



I have one more idea for trying to fix the startup problem in Windows 8. I don't know why it has problems with the current method because it does create the entries properly, Windows just doesn't launch it. So I'll have one more option in the next update that will hopefully work around this.



If you're setting the intensity to change in the Schedule tab (below the scheduled actions list) then you're correct, I need to fix it so it looks here after restarting the miner. If you create scheduled actions to lower and raise intensity at certain times, then you would check the box that says "persist action through restarts" when creating the scheduled action, which would make sure the action is re-applied any time the miner is restarted.



CGWatcher's memory usage will grow a little after it has been running a while, but it will level off. On my desktop right now CGWatcher has been running for 11+ days and its memory usage is at 68MB. This is on par with the average of 70MB I've seen throughout testing. CGWatcher is a .NET application using .NET's garbage collection, which makes it very difficult to have a memory leak because the framework is managing resources. Nevertheless, I do take steps to release resources anyway and don't rely entirely on the garbage collector.

I would suggest checking for other applications on your system if it is slowing down over the course of several days.



When using CGWatcher it will always set the miner to use a config file in its own folder (temp.conf) but this config file is created using the settings in your config file. The reason it uses this temporary config file is that some users share config files between miners, and then use variables to tweak individual machine settings. So a temporary config file has to be written so multiple instances of CGWatcher do not interfere with each other. You can see the exact config settings used to launch the miner by going to the Tests tab, locate the utilities drop-down list in the middle of the window, and select "Show last miner start configuration" and click "Run".

If you are experiencing a different in hashrate with and without CGWatcher, it is probably due to the gpu-threads value. The cgminer readme states that the default value for gpu-threads is 2, when in reality it uses 1 as default. So when CGWatcher launches the miner, it uses 2 as the default to match what the cgminer readme says and what the user should expect. This means when you start the miner outside of CGWatcher, you are using 1 gpu-thread, and when you start the miner with CGWatcher you are using 2, unless you explicitly set it to 1.

In other words, make sure the gpu-threads is set to 1 in your config file or arguments.

If you believe running your batch file also improves performance, you can set CGWatcher to launch the batch file instead of the miner's executable in Profile Manager.



If the scheduler is not working correctly, please email me two things: a debug report, which can be created by going to the Tests tab and clicking the 'Create Debug Report' button. And also, the file called cgwatcher.log in your CGWatcher folder. Keep in mind that if you create a scheduled action to switch profiles based on profitability, if it finds that the profile it should switch to is the profile already in use it will ignore the action.

When you change a GPU setting in CGWatcher, it is simply sending a command to cgminer telling it to change that setting. CGWatcher does not attempt to change clock speeds, fan speeds, or voltages itself because this can interfere with the miner doing it, as they both use the same method of getting device info. Some GPUs have locked voltages and you need to flash them with modified BIOS in order to change... but flashing a BIOS incorrectly can brick your card so it is not something I advise you doing unless you know exactly what you're doing.

You can use CGRemote to manage all three of your miners from one program. The next update of CGRemote will be able to get API data from CoinWarz or CoinChoose and send it to all miners it is connected to that are running CGWatcher in order to reduce API calls.

The "Switch to profile without restarting miner" setting will try to set any settings in the new profile. So if it switches to a profile where the fan settings are "50-100", it will send a command to cgminer telling it to change fan speed to "50-100". Any changes should be temporary if auto-fan is enabled, but I can't say for certain that the expected behavior occurs and need to do more testing, which is why this setting is considered experimental/beta.