Topic: CGWatcher 1.4.0, a GUI/monitor for CGMiner & BFGMiner to help minimize downtime - page 34. (Read 402544 times)

Great work!

Is it possible for CGWatcher to monitor and issue commands to a remote Linux rig from a Windows platform? I'm stuck using a VNC every time I think to check if everything is alright; as you said, a waste of time.

LOL you rock! Not to give you more work ... but while you're at it, you can make CGRemote into an iOS or Android app and sell it in their respective marketplaces!  

PS> @katie ... currently I'm using LogMeIn which is free, to remotely log in and check on my miner. Not as elegant a weapon for a civilized age as CGWatcher however.

I do currently have the CGWatcher program and do find it very nice.

I would really like the CG Remote program as that would get me past the problem of several machines each of which need checking from time to time.

Doing it from a dashboard, would be very nice.

If you need a Beta tester, PM me and we can see how to facilitate that.

K

 

Yes, remote access does not work correctly. I can't speak for bfgminer because I haven't used it enough to say, but I realized early on that there are enough occasions where remote access alone would not ensure that the miner ran continuously, and that is my top priority. I've spent the past week improving problem handling and added two additional checking options, among other changes. There are problems that occur often (at least with my miners) that cause cgminer to return to read-only API privilege meaning CGWatcher can no longer issue commands other than receiving stats. This, and the fact that sometimes sending cgminer the "restart" command causes it to close unexpectedly means that having CGWatcher on the same machine as cgminer (and presumably bfgminer) is necessary because being on the same machine gives CGWatcher the ability to launch and kill miner processes. This is why CGWatcher is not showing a miner running when it is done remotely... because it has become dependent on access to the miner's process. When cgminer goes to read-only access, the only way to get full access back is to kill the process and re-open it. Likewise, when cgminer closes unexpectedly after the "restart" command, the program needs to be launched again. Scheduled mining also requires CGWatcher to be on the same machine so it can launch the miner.

But there is hope! In order to remotely monitor and control miners and ensure that they run continuously, there would need to be a listener program running on each computer as a miner. This program could then talk to CGWatcher and report process info and launch or kill the miner when needed. I considered writing one, but I think that CGWatcher would be the best listener program. It has the logic built-in to keep a miner on the same computer running, so I felt it would make more sense to use it as the listener program and create a new program (tentatively titled CGRemote) that will communicate with CGWatcher(s) remotely (or locally.) I've already developed the basic program and have communication between the two working, I just have to design a protocol for sending and receiving commands and data.

If that is hard to follow...
You will run CGWatcher the same computer as cgminer. If you have multiple computers mining, you'll have CGWatcher running on each of them. That way it can do its job correctly. If you want to monitor or control your miners remotely, you'll use CGRemote. It will also be small and portable, and allow you to list as many miners as you want (IP address and port). CGRemote and all of your CGWatchers will use a common passkey that you create to make sure nobody else can send commands to your CGWatchers. The passkey is stored encrypted in each program's INI file. (All this stuff is done and working already.) CGRemote will essentially give you a dashboard of your miners, only instead of communicating with cgminer, it will communicate with CGWatcher, who in turn communicates with cgminer. For example, if you tell CGRemote that you want to start mining on one computer, it will send a command to CGWatcher on that computer telling it to launch cgminer (or bfgminer). Ultimately, anything you can do with CGWatcher you'll be able to do with CGRemote. Any data you can get from CGWatcher you'll be able to get with CGRemote. It may sound more complicated than necessary, but considering the steps CGWatcher has taken to effectively keep a miner running, it makes the most sense. To make it easier to add miners to CGRemote, you'll notice in the next CGWatcher update that there is now a Remote tab that shows you your local and public IP addresses (so you'll have all the info you need to add them to CGRemote) and will allow you to set a miner name, port, and passkey for use with CGRemote. The goal is to allow you to monitor and control local and remote miners (including headless miners.)

I'm planning on releasing the next update on Monday, April 22. It has some significant improvements with how it handles miner problems, and adds two new options to detect problems with the miner. The first is to restart the miner if CGWatcher had full API access but then lost it, which is a problem I've been dealing with on one of my miners. The second is an option to restart the miner if the total shares (accepted, rejected, etc) do not increase for X minutes, as this may indicate a problem with the pool. There is also better scrypt support (automatic detection), better error handling, a 'check for updates' button, and numerous improvements and fixes. The problems I mentioned above are now handled as well. It will all be listed in the update's ReadMe. There is no ETA for CGRemote, but it is essentially working right now.

Thanks for the positive feedback, it has motivated me to put more time into this. Over 700 downloads so far, much more than I originally expected. If you had any problems, try this next update before reporting them because it has many improvements. If you use the program and want to support its future development (and motivate its developer), consider donating to an address in the ReadMe. Thank you to whoever sent a few litecoins, it honestly made me spend the entire day working on it.

Agree with above poster. I have a desktop PC for my own use (gaming, etc), and a separate dedicated headless miner. I have BFGMiner running on the miner, and I have CG Watcher running on my desktop PC.

If I manually run BFGMiner on my headless miner with --api-allow W:192.168.10.69 (the local IP of my desktop PC), and configure CG Watcher on my desktop PC with miner address of 192.168.10.51 (the local IP of my headless miner) ... nothing happens.

But, if I run a copy of BFGMiner on my desktop PC, then CG Watcher will pick up stats on the headless miner!

If I'm interpreting this right ... I do have CG Watcher and BFG correctly configured, but CG Watcher won't search for remote data, because it thinks BFG is not running on the local environment (ie my local desktop), even though BFG is running on the headless miner that I've set it to monitor.

Confusing, no?

Love this app.  The only thing that I'm a bit "eh" about, is that it doesn't seem to handle monitoring a remote system.  Is it possible to add in remote monitoring?  I'd like to run this on my PC, and let it monitor my miner, and not have to vnc into it to check on it.

Additionally, how about a capability to "alert" when your mining speed drops (i.e. via email).

Nice program, thanks for releasing to the community.

I've been using this for a two days now, it's great. Fixed the bit of instability issues I was having with cgminer on win 8.

very nice!

downloading now.

Thank you so much for this one! I was looking for some SW that can watch out for my GPUs as one of them dies after ~4hours, but the ones i found did not really work so well, this looks great.
Looking forward to improvements towards scrypt.

Thanks for sharing this application and writing it. I'm currently using a GUIminer with cgminer developed by "TacoTime" and it's folks like you and TacoTime who really assist all of us in making Crypto Currencies a reality. I encourage you to continue, thanks. I'm always looking for automation to assist in keeping the miners going as downtime is of course loss.

GuiltySpark343, you can check the log (Log tab) to see if there were any reasons the miner was restarted. The Log tab displays the log since CGWatcher was started, but you can click Open in Notepad button to view the entire log history.

nwfella, not sure when I'll publish the source. Probably when I get done adding things and feel it is more complete. I have been commenting more in preparation for this.

LaudaM, do you use a comma (,) as the decimal separator? This caused hashrates to show very high ridiculous numbers, but is fixed in the next update.

voluntaryistonly, I have no dev experience on OSX so not something that is planned.

any chance of an osx iteration?

Average hashrate 16,897 Ghash/s? O.o
Why not add settings to display in MH/s, GH/s instead of this?

Nice program, gonna use it

looks pretty good...any idea on when you may be publishing source?

-nwfella

Suggestion:

On the Status tab, add a counter listing the number of times the miner was restarted?

Thanks!

Great Program! Putting it to use right now!

Not bad. Great for those people who are always checking their mining rigs.

Damm, what an awesome program, I've just setup 4 PC to mine 24/7 just the other day and was pissed this morning to find out it stop last night, around 12 hours lost in mining. I have to always remote in and check ever hour and it a time waste

thank you!!

Thanks. I've already fixed this (someone else mentioned a similar problem), but I'm not quite finished with the next update yet. By default, it will now require that the hashrate has to be below the threshold for 3 monitor refreshes. So if you set your monitor interval at 10 seconds, the hashrate would have to be below the threshold for 30 seconds. I wanted to give the option to change this without cluttering the interface so you'll be able to change this setting in the INI file if the default of 3 isn't suitable for the monitor interval you use. I'll include instructions on changing this in the update's ReadMe.