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

great!  a really cool utility!

there is a way to know what and how coins I'd mined last day/week or so? (in cgwatcher of course)

thanks

Love it!

No, it should not have that effect. It should not ask enough of the GPU to make any noticeable difference. I did have a concern it was possibly having an effect when scrypt mining at intensity 20, but even then it wouldn't be 20% and I think that may have been related to a resolved settings issue anyway. Can you go to the Tests tab and click Create Debug Report, then email me the results? I want to make sure no settings are getting altered before the miner is started.

You can also verify this by starting the miner outside of CGWatcher, and then opening CGWatcher and watching for a drop in hashrate.

I just downloaded CGWatcher and am trying it out for the first time. It looks like a great program. The only question I have is what should the overhead be?  In other words, with my humble little GPU I normally hash around 150 Kh/s (script).   But when using CGWatcher and using similar settings (at least attempting to use similar settings) my GPU is only hashing at 120 Kh/s.  Is this normal or do I need to investigate the settings further?

Thanks

Hey I am a new user of CGWatcher I would really like a feature of pool API. I mean by using the pools API users could be able to see the stats the pool

Version 1.2.0 available, see original post for changes and new features. It has some features that have been requested a lot including more advanced scheduling options and automatic profile switching based on profitability.

Let me know if you have any issues, particularly in these two areas. I won't be home tomorrow but I should be around all day Sunday.


Edit: Updated to version 1.2.0.1, which adds "adjusted profitability" and "average (7-day) profitability" when creating scheduled actions to switch profiles to most profitable.

keep me on the loop milone, been using cgwatcher since 1.1.3 and donated ltc toward your awesome program

I'm working to have some news on CGRemote soon, but there is another project that I am still waiting for the contract to be finalized that could postpone it for a couple months. I am trying to get at least a beta out before then. It will be a limited group at first, and yes I will let those who have helped with CGWatcher or have donated know first. If you fit into this group and are interested you can send a PM or email, but there are several people who have helped with reporting bugs and testing (some in this thread) that I will PM if I don't hear from to let them know the beta is ready as well if they would want to test it, so a PM is not necessarily required.

Looks good, I will use this when I get my miner set up.

Thank you very much milone. Shall be donating when I get my stuff going. Looking forward to CGRemote.

cant wait for the cgremote, milone.
perhaps you could let donators of cgwatchers to "alpha/beta test" cgremote? since, we are able to give you some error logfile.

Jazkal: Yes, CGRemote will provide a remote dashboard for multiple miners... even those without CGWatcher. But miners that are running CGWatcher will have more control because it is able to do things like launch or kill the miner that cannot be done via API. So if a problem occurs on a miner not running CGWatcher and it cannot be fixed via the API, you will have to fix it yourself. And obviously CGWatcher will be required in order to switch profiles on the miner from CGRemote.

But yes anything you can do in CGWatcher you will ultimately be able to do in CGRemote.

Here is a (very) basic diagram demonstrating how it works:

Very nice tool, thanks ! 

Very cool. So with cgremote, we will be able to pass it commands and it will change over cgwatcher for us?

Not yet but there will be in CGRemote. I've been working on it and it's getting close to beta stage.

Is there a way to send a command to cgwatcher to switch profiles? Either on the same computer or via the network?

Just set everything up and it looks great! I used your first option of having a brand new copy of CGWatcher. Right now my two miners and two copies of CGWatcher are running without any problems. Before the new version, CGWatcher was not correctly restarting the correct miner (miner with problems/0kh/s/etc), so I'll see how that goes with testing throughout the day. From how easy everything connected (and CGWatcherB didn't detect anything when CGWatcherA was running) I expect everything should be fairly smooth from now on. I appreciate your time and effort continually maintaining and updating this program for the community, I'll send a small donation your way once I have this running for a while.

 

iPhoneDude777: I've made some changes so downloading 1.1.9.0f will hopefully correct this. I had purposely made the criteria for linking a miner more relaxed if there was only one instance of the miner running. Unfortunately, this had a bad side effect on trying to run multiple instances.

1. Make sure that the cgwatcher.exe file is updated for both instances. To make this easier to follow, I'll call them instance A and instance B. So CGWatcher A is monitoring miner A, and you want CGWatcher B to monitor miner B.

2. Start CGWatcher A as usual. If you still have the miner running it should connect to it without issue. Then there are three ways you can handle starting CGWatcher B (which is only because of problem caused by the previous version). You will only need to do one of the following after updating to 1.1.9.0f:

• Make a clean copy of the CGWatcher B folder so any settings related to Miner A are gone.
• Restart Miner A so it is no longer using the same process that CGWatcher B connected to. If you've stopped or restarted Miner A at all since last trying to use CGWatcher B, you should be fine.
• If the miner A process that CGWatcher B connected to is still running, start CGWatcher B and after it starts it should still show the miner is running but it won't have API access to it. Down in the bottom right corner next to where it says "CGMiner is running" (or something similar), a 'Reset' button will appear whenever there is no API access. Click this button to remove the link CGWatcher B had made to the Miner A process. Once you do this, it might take a second but it should change to "No miners running".

So essentially you're removing the link that CGWatcher B had made to Miner A. Once you do this, you should be able to start Miner B in CGWatcher B.

Let me know if this works or doesn't work, I'm not able to test much at the moment but from the tests I did run it worked correctly.

Hey there. I've been trying for the past couple of hours to get two instances of CGWatcher/CGMiner up and have been unsuccessful. I have two copies of CGWatcher in different folders. They both point to IP 127.0.0.1, but one points to port 4020 and the other to 4029. The is reflected in the CGMiner config files as well. When starting the miner, the CGWatcher mining log shows that the miner has started activity on the desired port, but when starting the second instance of CGWatcher, it immediately picks up on it and asks to create a profile even though the "require this API port" box is checked. Any suggestions?

To give some more information: I start one instance of CGWatcher (port 4029).


When everything is running, I open the second instance of CGWatcher (set on port 4020). It detects the first instance of CGWatcher on 4020 as seen here.



Somewhat a workaround (for anyone else running into this problem).
I created a bat file to just run the second instance of CGminer that I wanted. I already have a profile for it set up in CGWatcher. When the CGMiner instance was running from the bat file, I opened CGWatcher and it detected the profile I had already set for it. It monitors the one GPU properly while giving no stats for the second (which is good because each instance is running a separate GPU)

One thing I would like to see added to CGWatcher in the future is the ability to tune CGWatchers overheat temps, but it's thrown into the CGMiner config easily enough.

Fishbones: I just made changes to add a 10-second delay when launching the miner upon starting CGWatcher. You can change this value by opening the INI file, finding [Monitor] section, and editing the "AutoLaunchDelay" value (value is in seconds). This setting may not appear in the INI file until you run 1.1.9.0e at least once, which in that case you could manually add it in the INI file.


Zanatos666: I made some changes to the restart function yesterday in 1.1.9.0d, and just uploaded 1.1.9.0e which also has the delayed auto-launch setting. When restarting, the miner actually launches itself as a new process then closes the old one. CGWatcher should wait up to 15 seconds for the old process to close. If for some reason this doesn't happen, it ends up killing the process. It then checks to see if the miner successfully launched itself, and waits for it to initialize its API. If for some reason the miner didn't successfully launch itself, it will try to start the miner. It will not necessarily keep trying to start the miner, because most likely if it fails to start once it will continue to fail (e.g. incorrect config settings).

So between the different steps in the restart process, it can actually wait up to a minute or so for the restart to complete... but once the conditions for a step are met it moves on to the next step instead of waiting unconditionally.

As I mentioned, there may have been instances prior to 1.1.9.0d where this was not working as expected, so let me know if the update has not resolved the problem.