CGWatcher 1.4.0, the GUI/monitor for CGMiner and BFGMiner to prevent downtime

[milone]

btc6000: Since I don't have any ASICs yet, I don't know exactly what type of information I will be able to get from the miner for them. In version 1.1.4, you'll see that I am getting there and on the Tests tab there are three device tests: CPU, FPGA, and ASIC. I am hoping users who use these devices to mine can click the appropriate button to run the test, which will send commands to the miner requesting information about those devices. The results will be displayed in the textbox, which can then be emailed to me so I can see what information is available. Because of the variety of FPGAs and ASICs, the more users that can submit these test results the better. The CPU test is something I could run myself (although I don't CPU mine), but I figured if I made it a test and asked users to submit the results, it would help me gauge whether it is even worth it to write in CPU support.


AlphaColt: Your fan speed drops because CGWatcher shuts down the miner correctly when you press the Pause Mining or Stop buttons. (There is no pause in cgminer, CGWatcher just calls it Pause because it works different than the Stop button in that scheduled mining will resume if the Pause Mining/Start Mining button is used. This means if you have set the miner to manage your GPU clock speeds and fans, it is running them at higher than normal while mining. When you shutdown the miner properly ("quit", not click the X in the corner), the miner returns the clock speeds and fan to their normal values. This is why you're hearing your fan spin down... it is by design because the temperatures immediately drop when mining stops. When you press Start Mining, the miner is re-launched, causing it to again take control of the clock speeds and fan. You will hear the fan spin back up as the temperatures heat back up.

I was aware of the annoyance that was changing GPU settings, but I had other priorities so I figured an interim solution would be to increase the monitor interval so you had enough time to change settings between refreshes. This is fixed in 1.1.4, where the textbox that has focus will not be updated, and no values will be updated while the confirmation message box is displayed either. This should be enough for changing one GPU setting at a time, but if you want to change several at once there is now a "Freeze" button that will prevent updates to any of the settings that can be edited while the button is depressed (it's works similar to a checkbox, but looks like a button.) Once you have made your changes, you can click the button to "Un-freeze" the settings so they will be updated on refreshes again. While editable fields are frozen, they will change to blue text to make it clearer that they are frozen so if you're expecting them to update, you'll need to click the "Un-freeze" button. (note: even if the editable fields are frozen, the non-editable fields like activity, temperature, etc. will still update on monitor refreshes.) I may have made it sound complicated here but once you use it once you'll see how simple it is.

I've spent the whole week working on and testing 1.1.4. I think it is ready, but I have to rewrite the ReadMe for it because so much has changed and there are several new features. I plan on doing that and uploading it tomorrow (Sunday). Most of the monitoring has been re-written and I think the new features will be helpful.

The auto-configuring of the miner based on hardware gets a little complicated with the variety of hardware available, but this is something I've been working towards. I prefer config files to command-line arguments so this required an easy way to edit config files, which you'll see is starting to take shape in 1.1.4. Ultimately there would be a config "wizard" that would walk beginners through setting up their miner, but I haven't gotten there yet. The Config File Editor in 1.1.4 is a start, but still requires a little miner knowledge on the user's part.

[1713623863]

1713623863

[1713623863]

1713623863

[gveltre]

I am running BFGMiner 64bit.  Do you have a 64bit version of CGWatcher?  I am getting an error,
"a 32 bit process cannot access modules of a 64 bit process."

[milone]

Version 1.1.4 is now available. It includes mining profiles, monitor improvements, and a config file editor.

If you downloaded already and received an error on startup, download again to get the fixed files. This bug was affecting users with one monitor so I did not catch it before release, but it has been fixed.


gveltre: I do not have a 64-bit version but I will work on modifying the code that is trying to access modules of the 64-bit BFGMiner.

[grottenolm]

Version 1.1.4 is now available. It includes mining profiles, monitor improvements, and a config file editor.

If you downloaded already and received an error on startup, download again to get the fixed files. This bug was affecting users with one monitor so I did not catch it before release, but it has been fixed.

(edited after some more testing)

Thanks a lot for this update!

@ the last item in the Change Log: I hope you got a bit more rest now... I know how it is with coding projects, can forget almost everything around one ;-)

I ran into that one monitor bug, but it was already fixed before I could report it - Great!

Apart from that, some more small comments as feedback (setting up new, not over old installation, Win7 x64):

- I first set up the profiles (great feature! Love it), then went on to set up monitoring. As soon as I activated "Ensure miner stays running unless paused..." cgwatcher tried to start cgminer. While that was a bit unexpected I guess it's fine and well in line what this option says hehe

edit: actually I am afraid thats a small bug: the option says "unless paused or stopped", but the miner was stopped at that time. Duplication should be like this: 1. new cgwatcher "installation" 2. set up existing cgminer and save 3. enable this option -> It will try to start the miner, even the miner has not been started yet.

The actual issue for me was that it complained that it was supposed to keep cgminer running but could not do so because the miner path was not set up (only popup, not logged - so I can't tell the exact message, sorry). While I went to the settings page to double check if I remember correctly this message popped up once more. Then, while checking the settings and seeing that the path is indeed there, suddenly cgminer was started and everything was fine. I hope I can duplicate it better when I update some more machines.

edit: could duplicate, same way as described above

- With solo mining Terracoin I get (almost) no "accepted shares" during normal operation. While I am not sure that this is 100% correct cgminer setup and/or behavior (I do get the expected amount of mined blocks, so i didn't check further into this), at least for me that means that the option "Restart Miner if accepted shares stop increasing for..." is not applicable, while the old option checking total shares was useful. Since most people are pool mining anyway (as I should probably, my total hash rate is not huge) this should not be much of an issue to many people, if any. I just wanted to have this mentioned here, just in case anyone else might be affected and is looking at this thread.

edit: one more idea

I find myself only having the "log" page open, to see if everything is running smoothly or if there were any restarts. So it might be a good idea to display some info about the last time(s) that cgwatcher restarted cgminer on the status page.

That could be simply the last time and maybe reason cgminer was (re)started. Or it could be a counter how often cgminer was restarted, maybe even with some signal color/icon if there were any restarts necessary, plus a button for clearing that counter and status (like "yes I saw it, its fine, now start counting from 0 again). Highest end solution would be statistics about numbers, times, reasons of restarts... but I would guess that's by far not worth the effort.

If you think about making a bit of money with this app, how about creating CGRemote for iphone/android (including push notifications or at least alerting through some instant message service like in Akbash watchdog) and make the full version of that, like for more than 1 miner, pay only. There are several tools, like for example the language learning program ANKI, that are free, but have paid mobile apps to cover the costs. I guess that model works, because people are willing to spend money on convenience If you can't code for mobile devices you could use some of the donations to pay someone for example on a freelancer website...

[milone]

grottenolm: Thanks for the feedback. I just uploaded version 1.1.4.1, which should correct the problem you had with the 'Ensure miner stays running' option. It was indeed a bug, something that I overlooked when implementing profiles. I also found a bug that prevented the hashrate cutoff type (Kh/s, Mh/s, Gh/s) from being saved and reloaded, so that is corrected as well.

I've also added an option for choosing whether you want the monitor to check for accepted share count changes, or total share count changes (accepted, rejected, or stale). Let me know if this resolves your problem with solo-mining.

Someone else mentioned setting different hashrate cutoffs for different profiles, specifically when mining SHA256 vs Scrypt where you may use Mh/s for one and Kh/s for the other. That's an obvious annoyance so I may end up making some or all monitor options per-profile.


Edit: In response to your edits, I've made another change to 1.1.4.1 that will disable or prevent the "Ensure miner stays running" option if the active profile's miner path is not valid. The bug I fixed earlier caused the active profile's miner path to not be set properly before this option started the miner.

The next big update will be a UI overhaul. I have a thread in the newbie section where I discussed this earlier today... or last night... I can't remember. I will keep your ideas in mind when laying out the new interface. Right now you can see a restart counter and the last restart reason in the Report tab, along with a ton of other info.

The last idea is interesting, but my focus right now is getting the Windows version of CGRemote finished. I'd love to make enough money to devote all of my time to these projects, but I do not think that is realistic. I haven't received anywhere near enough in donations to pay for mobile dev work. Android development is something I want to learn so it's on the list, but it may be a while before I get that far down it.

[AlphaColt]

After messing with CGwatcher and MSI afterburner more, I decided to stick with MSI afterburner. Why? Well, it allows me to view my GPU temps and clock speeds, whereas with CGwatcher taking care of the GPU clocks and GPU fan speeds I cannot even view them VIA afterburner. I could be a bit anal and paranoid, but for now this seems to prevent any high temps beyond 60C on my 5770.

For the future, once CGremote get's launched I will mess with it some more. Wishing an android app would be pushed out. I am no coder but I should learn to help the process. As long as the basic's are implemented, I don't see any harm working on a beta.

All in all looking forward to the updates and release of CGminer

I will donate after a few days of mining so expect some LTC heading your way

[milone]

AlphaColt: Just to clarify, CGWatcher doesn't modify clock or fan speeds. CGMiner is what modifies them using the settings you tell it to use. CGWatcher just makes changing those settings easier. When you change a GPU setting in CGWatcher (like clock speed, fan speed, etc), all it is doing is passing a command to CGMiner telling it the changes you want to make, then displaying the results it gets back from CGMiner. Why clock or fan speeds modified by CGMiner would cause them to not show in Afterburner, I cannot say because I never had that happen. You can also try Sapphire Trixx and see if it works any better than MSI Afterburner. I find that both work better than Catalyst Control Center, which often won't display multiple cards unless they care connected to monitors, using dummy plugs, or cross-fired.

[AlphaColt]

After more research and messing around I figured it out. For now, I am sticking to using MSI afterburner app on my PC and on my android phone so, if needed, I can underclock/overclock and change fan speeds. Seems to be working good for me so far. Tried using cgminer with auto fan and ended up killing my GPU (got a lot of sick gpu resets) Can't wait until CGremote comes out and am hoping you start working on an android app so I can test it

I also noticed AVG hashrate in "Status" isn't showing but shows in the "Devices" tab. Quick fix?

[milone]

Yes, hashrate not displaying correctly has been fixed in 1.1.5 which I am trying to have ready this weekend.

[GuiltySpark343]

When CGMiner switches pools due to a failover event, does this get recorded in CGWatcher's log or any log?

I check on my miners every now and then, and would like to be able to know if there was a failover event that I missed at some point. Any way to find out?

[poohbah]

Version 1.1.4 - the "start mining on selected days...if not already running" setting seems to be ignoring the already running instance, even though it can see it.

[5/27/2013 1:07:36 PM] Scheduled mining starting at 1:07:28 PM as requested. CGMiner is already running. Attempting to restart...
[5/27/2013 1:07:36 PM] Restart command sent to CGMiner with full API access...
[5/27/2013 1:07:39 PM] CGMiner was successfully restarted.

I'm assuming this isn't intended behavior, since there is already a "restart after x hours" setting.

[milone]

GuiltySpark343: This type of information is not recorded in 1.1.4 but there have been requests for things like this so in 1.1.5 there will be a separate log just for miner events. Just keep in mind that exact times may be slightly off by up to the number of seconds you have set as the Monitor interval. (Example, if you have CGWatcher Monitor interval set to 30 seconds, event times may be up to 30 seconds off from when the actual event occurred.) I'm not sure exactly what all events will be recorded, but if you have any suggestions/requests, please let me know. The miner also has a logging option, using 2>logfile.txt where it will write its log to logfile.txt, but setting this argument in CGWatcher seems to cause an error starting the miner so you'd have to create a .bat or .cmd file that launches "cgminer.exe 2>logfile.txt", then point CGWatcher to the .bat or .cmd file for now until I figure out what is causing the problem. (I don't actually do anything to the arguments so this may be a issue with .NET Process.StartInfo.Arguments not liking the > character.) The miner has some different logging options but other things have taken priority so I haven't had a chance to really look into incorporating them into CGWatcher yet... but it is on the to-do list.


poohbah:

seems to be ignoring the already running instance, even though it can see it.

I'm not sure what you mean by that. From the log entries you posted, it restarted the running instance at the scheduled start time, correct? Or am I misunderstanding what you meant?

I guess the question is... what is the expected behavior if scheduled mining is set to start but the miner is already running? If a scheduled stop time is set, should it still honor it? Right now what happens, or should happen, is that the miner will be restarted at the scheduled start time (just to be safe the miner is mining properly) and the miner will be flagged as being on scheduled mining time so that if a schedule stop time is set, the miner will be stopped after that many hours.

There are also differences in how the start/stop/restart/pause buttons behave, and although I'm pretty sure I put it in the ReadMe, I may need to make it clearer. The buttons in the Settings tab (Stop, Restart) will cancel scheduled mining time (thus voiding a scheduled stop time), while the Pause/Start on the Status tab will not. As an example...

I want the miner to run while I'm at work so I set the schedule to start mining on Monday at 9am and set it to stop after 8 hours (5pm). Monday 9am comes and the miner is started (or restarted if it was already running) turning on the scheduled mining flag. If I use the Pause/Start button on the Status tab, it will stay on the schedule and still stop at 5pm (if it is running at 5pm and I have not closed CGWatcher in between.)

If I use the Stop/Restart/Start buttons on the Settings tab, it cancels the scheduled mining meaning if I start it again and 5pm comes around, it will not be stopped. Scheduled mining will resume as normal the next day it is set to start.

So all of this only affects the scheduled stop time... which is different from the "Restart after X hours" which restarts the miner instead of stopping it.

If the miner is on scheduled mining time with a stop time specified and you click the Start/Stop/Restart button in the Settings tab (which will void that scheduled mining), I will add a prompt to ask the user if they want to continue (canceling the stop time), or simply "pause" the miner so that when they restart it it will still stop at the appropriate time.

All that said, scheduled mining hasn't really been touched since I implemented it aside from maybe a bug fix or two. In the next update (1.1.5), it will get its own tab and will ultimately get more options including not only starting the miner at specific times, but also increasing or decreasing intensity at specific times or when the computer is idle. But I'm not sure how soon I'll get to that. 1.1.5 has some major changes and improvements "under the hood", so I want to get it released soon (within the next couple days). But because it will now get GPU info on its own (including for Nvidia cards), I am trying to do a lot of testing with the limited Nvidia systems I have access to. 1.1.5 also has improved support for multiple miner instances running at the same time, though each miner will need its own CGWatcher instance and unique api-port set in its arguments/config file. I still have some things to work out (such as making sure they don't overwrite each other's settings in the .ini file.)

Because of these significant changes, I will probably post a download link to the new version as well as a link to the previous version just in case anyone has problems with the new version... although I am working on allowing the user to correct any GPU-matching problems on their own. If anyone happens to be mining with Nvidia cards (or even Intel HD graphics if that even works) and would be willing to test the new version, please let me know here or email me at the address in the ReadMe. I know AMD+Nvidia systems are unusual and temperamental at best, but I am also looking to test more of these - for example on one PC I have there is an integrated Nvidia GeForce 6150SE and an AMD Radeon card I installed. Although these configurations are rare in the mining world, I still want to be able to handle them... if not automatically, at least let the user tell it which GPU is which since trying to match them across the different libraries is a mess.

[poohbah]

poohbah:

seems to be ignoring the already running instance, even though it can see it.

I'm not sure what you mean by that. From the log entries you posted, it restarted the running instance at the scheduled start time, correct? Or am I misunderstanding what you meant?

I guess the question is... what is the expected behavior if scheduled mining is set to start but the miner is already running?

Based on the name of the setting ("Start mining on selected days at this time: if not already mining"), I would expect it to do nothing if the miner is already running.

It's not a big deal, since all it does is lose the statistics that cgminer has accumulated over the last X hours. If you leave it as is, maybe the option should be renamed to "Start mining on selected days at this time: restart if already mining."

Either way, love the monitor and I'm really interested in the remote.

[digitalindustry]

Mate i just want to say I love your program ! donation are coming your way think and fast asap i get the currency you are currently taking - later i will be able to pay you in a better one ! : D

this is a truly nice piece of work and i hope all you miners out there using this donate !

[Lucko]

I have put this on my miners yesterday and I have a problem. I run cgminer with .bat file. The problem is that CGWatcher can't start cgminer. I think this is because I don't have .conf files since I do see dos window appear and disappear in a flush... Is there a way to make CGWatcher work with .bat files?

I have setup .bat file in a profile instead of cgminer.exe. I also running option 2>log.txt if this might be a issue. Do I need to do something else?

Thanks

[milone]

poohbah: I will edit the setting's text to make this clearer. My thinking was that should there be a problem that was undetected by other checks, a restart at the schedule start time would hopefully resolve it and ensure that the scheduled mining ran properly. Ultimately I'd like to preserve a history of statistics, but there are other things to do first.


digitalindustry: Thanks


Lucko: I did find a problem with .bat or .cmd files that used the 2>log.txt or similar argument. It has been fixed in 1.1.5 and should be available tomorrow. (I said that about last weekend but I got sick so it was delayed.)

You'll still need to use a .bat or .cmd file when using the 2> argument because the .NET process class has a problem with it that I haven't tracked down yet.

It doesn't matter if you don't use a config file if you're using arguments. Arguments inside a .bat or .cmd file will be shown in the CGWatcher Profile Manager window (in the Arguments textbox) so you can easily edit them, and upon saving it will update the .bat or .cmd file with any changes you made. So whether you point to a .exe, .bat, or .cmd file for your miner, you can manage the arguments for it in the Profile Manager window.

[Lucko]

Lucko: I did find a problem with .bat or .cmd files that used the 2>log.txt or similar argument. It has been fixed in 1.1.5 and should be available tomorrow. (I said that about last weekend but I got sick so it was delayed.)

You'll still need to use a .bat or .cmd file when using the 2> argument because the .NET process class has a problem with it that I haven't tracked down yet.

It doesn't matter if you don't use a config file if you're using arguments. Arguments inside a .bat or .cmd file will be shown in the CGWatcher Profile Manager window (in the Arguments textbox) so you can easily edit them, and upon saving it will update the .bat or .cmd file with any changes you made. So whether you point to a .exe, .bat, or .cmd file for your miner, you can manage the arguments for it in the Profile Manager window.

Oooo. It was a misunderstanding about previews post. I thought .bat is a workaround. OK good to know...

[Kiplingscat]

Hi Milone,

What an unbelievable tool you have given us.

I have an issue I am running into and I am curious as to your thoughts.  I have three GPUs running and when using CGwatch, the 1st gpu will run fine for approx. a minute and then will throttle back into the kh/s range.

Any thoughts on what is causing and how to correct?

[Kiplingscat]

mAn you are amazing Milone.  

within cgwatcher, settings, you have the config file editor and within that I had a drop down to turn gpu-auto to false and that of course fixed it.

I had zipped cgminer and cgwatcher together on my google drive to populate all machines and I thought I had said config that way before saving the files, but apparently not.

that, in app, editor is awesome.

Thanks again!

[milone]

Kiplingscat: There was a bug in the Config File Editor that caused auto-gpu and auto-fan to default to True. If you set them to False and then saved the config file, it would save correctly. But the next time you opened the config file in Config File Editor, they would default back to True. This may explain the problem you had.

It has been fixed and the download file updated so please download again if you have not already done so.