It's related. CGMiner doesn't report a total current hashrate via API, so in CGWatcher that value is the sum of all enabled device hashrates. If for some reason CGMiner reports a total average hashrate > 0 but all devices hashrates are 0, it instead uses the total average hashrate for this value. I originally did this for non-GPU miners back before CGWatcher had support for FPGAs and ASICs, so there would be a reasonably accurate value there (at least more accurate than 0). So the problem is in figuring out why CGWatcher thinks the GPUs are inactive.

Had you used previous versions of CGWatcher and if so, did it work correctly in them? Also, if you can email me a debug report created while the miner is running (go to Tests tab, click Create Debug Report) and possibly attach your cgwatcher.log file, that would be a good start in finding out why. It's possible it is a bug, or that the GPUs need to be manually mapped inside CGWatcher.

The easiest way to update is to copy all files in the update archive (CGWatcher-*.*.*.rar) to your existing CGWatcher folder, overwriting any files. This won't affect profiles or configurations because those files are not included in the update (they are created the first time CGWatcher runs if they don't exist.)

If you ever need to revert back to a previous version for some reason (e.g. I break something), you can download all older versions on the download page (or ideally report the problem and I'll fix it and update the download files.)

There is also an auto-update option in the latest versions of CGWatcher. I'm currently trying to find a better (more reliable) hosting option for the files but in a worst case scenario if the host is down it just won't update itself until it's back up. After the updater downloads any necessary files successfully, it will close CGWatcher and re-open it using the new version to complete the process.

As soon as CGRemote is released and I get back to CGWatcher, I'll look more into cpu affinity options. I didn't expect this would have a noticeable effect on gpu/fpga/asic mining since cpu usage in cgminer is typically very low, but admittedly I hadn't put much thought or testing into it. I'm open to adding any options that may improve hashrates. In case you're not aware, you can set profiles to use a batch file instead of the executable. This would ensure that if CGWatcher ever restarts the miner, it uses the same settings as you're using now by launching a batch file outside of CGWatcher because any time it restarts a profile that uses a batch file, it closes the miner and re-launches the batch file to make sure all settings are applied. Just set the Miner Path in the Profile Manager window to the batch file. Arguments from the batch file will be loaded automatically into the Arguments textbox and if you make any changes to the arguments it will save them back into the batch file. Having the "start /REALTIME" option or other lines (e.g. setx) will not cause a problem and these aren't modified or removed when saving arguments to the batch file. (If browsing for a batch file, you may need to change the filter drop-down to "Batch and Command files" in the bottom right corner of the Browse window. I'll probably change this to show miner executables and batch files together in the future.)

If the miner doesn't start outside of CGWatcher, then there is not much I can do as far as CGWatcher goes.

I'd suggest opening the command window/command prompt and navigating to the cgminer folder. Then launch cgminer from the command prompt with the -D argument. This should give you more info on why it isn't working. When launching at the command prompt, you can still launch it using a batch file (just add the -D argument to the end of the other arguments).

The reason for launching from inside an already open command window is that the window won't disappear once cgminer closes, allowing you to see what it outputs.

Hopefully this is what atariguy is referring to. This will be fixed in the next update.

play, thanks for making this an easy bug fix. If you'd like to participate in the CGRemote beta, PM me your email address. It should start in the next day or two.

Timk225

Are you able to launch cgminer using the batch file outside of CGWatcher?

If you copied that text right from your batch file, you need to add a - for the shaders option so it says instead of This is why the miner did not start and may be why the arguments got messed up.


Edit: Also, the intensity range for scrypt is 0 to 20, where it is -10 to 14 for sha256. So intensity 9 for scrypt mining will result in a very low hashrate. You may be aware of this, but I had created a profile using your settings to test just now and was only getting ~80Kh/s each on 7950s where I get ~550Kh/s on high intensities. Just thought I'd mention that.

No other reports on two miners starting. In the code that starts the miner, there is only one line that actually launches the miner so I can't imagine how it would happen, but I won't say it's impossible... stranger things have happened. This happens when you are running two instances of CGWatcher? Does it happen when Windows starts or when you press the Start button in CGWatcher?

The best help would be to reproduce this behavior, so do whatever you did that caused two miners to be launched. Then go to the Tests tab in CGWatcher and click the Create Debug Report button. If you are running two instances of CGWatcher it is probably best to do this in both instances. Email the debug reports to my email address in the readme.

I will be updating CGWatcher soon with some changes needed for the CGRemote beta, so if I find it is a bug I'll make sure it is fixed in this next update.

timk225:

You don't use a batch file and an exe file. You use one or the other.

First, make sure all of the miner options in your batch file are on the same line as the executable. I'm not sure if you just put them on separate lines here for readability, but your batch file should be:


In the CGWatcher Profile Manager window, clear the config file path textbox and arguments textbox. Then set the miner path textbox to your batch file. (If you browse to find your batch file, you may have to change the filter in the bottom right corner of the dialog window to "Batch and Command files".

Once you have set the batch file as the miner path, you should see the arguments from the batch file automatically loaded in the Arguments textbox. If you change any arguments here, they will be changed in the batch file when you save the profile.

So your profile manager window should say:


Click the Save button and once saved make sure the profile you just saved is set as the active profile (at the top of the Settings tab). If it isn't, select it from the drop-down list and click Save Settings. Then click the Start button.



eurgbp2011:

I will not be able to work on this until CGRemote is released. I'm not sure what the Flash file you sent me is but I'm out of town and borrowing someone's computer (I forgot my laptop charger) so I won't be opening any Flash files. I'll PM you when I am able to work on the auto adjust intensity code and will consider any suggestions on making it smarter.

SpAcEDeViL:

You'll have to wait for CGRemote to do this.


eurgbp2011:

Yes, the auto intensity adjustment is not "smart". I don't believe I've ever claimed it was. All it does is check the current temperature and change intensity or disable/enable the device depending on the temperature. Assuming the GPU is below temp-cutoff, it should eventually get to where it is switching back and forth between two intensity values. This is because it tries to use the highest intensity it can. So if temp-overheat is set to 85C and the original intensity is 14, it will do the following:


So it might eventually keep going between 10 and 11 for example because 11 causes the temp to exceed temp-overheat, but 10 causes it to go below temp-overheat. Since using a combination of 10 and 11 is better for your hashrate than just using 10, it will continue to go back and forth between these two.

If this is not what is happening, then there very well may be a bug that needs fixed. What are your current temp-target, temp-overheat, and temp-cutoff settings? And emailing me a debug report (go to Tests tab and click Create Debug Report) and your cgwatcher.log file would be helpful in finding any problems.

As I mentioned a few replies up, the overheat protection in CGWatcher can be used for AMD GPUs, but was added to give some protection for Nvidia GPUs, which cgminer doesn't get the temperatures for so it cannot protect. For AMD GPUs, the auto-gpu option will let cgminer manage your GPU clock and fan speeds to maintain target temperatures, and is probably a little more intelligent. I never meant for overheat protection in CGWatcher to replace this, which is why the overheat protection only works if auto-gpu is disabled. I'm not sure which program's method results in higher hashrates while keeping temps under control... I haven't done testing. But regardless of what GPUs you have, there may be some AMD users who prefer CGWatcher's method to cgminer's, so I want it to work properly for all GPUs. So if you can provide the info I suggested to help find problems I'd really appreciate it.

If you're trying to host that page on a web server (that isn't the computer cgminer is running on), you'll need to

1.) Enable the API in cgminer and set it to allow connections from your web server's IP address.

2.) If you're mining computer is connected to a router, forward the port cgminer's API is using (default is 4028) to your mining computer. http://portforward.com has a lot of helpful information on how to do this and a free utility to check if the port is forwarded correctly.

3.) Set your mining computer's public IP address in that monitor page's PHP. I don't use that monitor but I'd imagine the IP is either hard-coded or is displayed in a textbox.

That page on your web server is what is connecting to cgminer, so you have to make sure it can connect to your mining computer and to cgminer. If your mining computer's public IP address changes, you'll need to update the PHP with the new IP address.

Sorry unpack, I'm not sure what you mean. The download link is via Dropbox. As mentioned in the post and readme, the source has not yet been released so that is why it is not yet on GitHub.

Assuming you're trying to access the miner from the same computer and want full API privileges, the command line arguments would be:


If using a config file, add these two lines:


You may need to add a comma at the end depending on where in your config file you place it.

If you're trying to access the miner from a different computer, give more info and I'll try to help.

Lucko:

There is not a whole lot I can do about this at the moment. I chose coinchoose because they supply data in json format. If there is a better alternative, I'm open to switching or offering a choice on where the data comes from. But only for sites that provide either json or xml or plain text, etc. If I have to get into page scraping that will further down the road. And I have no plans or time to try to capture and maintain this data myself. I'd rather use a site like coinchoose where that is the developer's  primary focus and I would imagine he does what he can to keep the data as correct and current as possible.

I know cgminer and bfgminer provide the current difficulty via API but I'm not sure how accurate it is for altcoins. Assuming it is accurate, CGWatcher could switch to the profile based on coinchoose data -> start the miner -> get the difficulty from the miner -> update its coin data -> reassess the coins using the updated difficulty. But this wouldn't be until after CGRemote is released.



RandomQ:

Without more information it is difficult to say what the problem is. The best way to resolve this is to email me a debug report right after it was supposed to restart the miner but didn't. So if you've set it to restart if accepted shares don't increase for 10 minutes and it has been 11 minutes, go to Tests tab and click Create Debug Report and email me the report.

If you go to the Report tab and scroll down to the [Debug information] section, it lists when and how long ago the last share count change occurred for accepted, rejected, stale, and total. So if you have it set to restart the miner if accepted shares don't change for 10 minutes, and it says the accepted share count last changed 11 minutes ago and it didn't restart the miner, there is a bug... but I'd still likely need the debug report to pinpoint where. I just woke up so I'll go over the code again shortly and if I find anything that needs corrected, I'll release a fix and post back here later.

Correct. Right now you can only link coins to profiles. In order for it to switch pools based on profitability, you would have to assign a coin to each pool... something I haven't gotten to yet.


If you enable auto-gpu, CGWatcher does not adjust intensity because cgminer/bfgminer will protect against overheat by adjusting clock and fan speeds, and if necessary disabling the device if temps exceed temp-cutoff.

If you don't enable auto-gpu, CGWatcher will automatically adjust intensity as long as the 'Overheat protection' option in the Monitor tab is enabled. When adjusting intensity, the following is performed during each monitor check (default every 10 seconds):

For each GPU that is mining...

    If the GPU's temperature has been above temp-cutoff for at least 10 seconds, disable it and mark it as disabled.

    Otherwise if the GPU's temperature has been above temp-overheat for at least 10 seconds, lower intensity by 1.

    Otherwise if the GPU's temperature has been less than temp-overheat for at least 10 seconds...

        If CGWatcher had disabled the device, re-enable it.

        Otherwise if CGWatcher had lowered intensity, raise it by 1 (unless it is already back to the original intensity)

        Otherwise do nothing.

If you haven't set temp-overheat and temp-cutoff, the default values are 85C and 95C respectively.

So all of this only occurs if auto-gpu is not enabled. I did not add this feature to replace cgminer's gpu management... I added it because CGWatcher is able to get Nvidia temperatures where cgminer isn't... so this was to give Nvidia miners at least some sort of protection, though it can be used for AMD GPUs as well. I have not tested to see which method gives better hashrates.

So if you don't have auto-gpu enabled and CGWatcher is not adjusting intensity as expected, let me know and I'll look into it... but I'll need more info. The best info would be right after CGWatcher fails to adjust intensity, going to the Tests tab and click 'Create Debug Report'. Then email me the report. This would help me see what exactly is happening, but since the report only includes the last 25 log entries, the sooner you can do it after the problem occurs, the better. You can also go to the Log tab and check the 'Show debug entries' checkbox and see if any info is given there indicating a problem.

I'm hoping to start the CGRemote beta within a week... (*hoping*, I'd say two weeks at the most but am really shooting for the middle of next week. I'm happy with the framework and the rest of the work now is relatively easy stuff. Until it is ready, updates are being posted to http://manotechnology.blogspot.com/p/cgremote.html

Yes, but this requires one instance of CGWatcher per miner. And currently you need to run each instance from a separate folder, otherwise they will overwrite each other's settings in the INI file. I will fix this in the future, but CGRemote is my current priority. Getting this to work is pretty simple, but I'll try to give as much detail as I can so it may seem complicated until you read through the steps. The basic idea is setting up two CGWatchers, each using a unique API port so they don't communicate with the wrong miner.

So assuming you want to run two miners, cgminer using GPUs and bfgminer using ASICs...

1. Setup your desired profiles and settings in CGWatcher. Make sure you have one profile for cgminer using GPUs and another profile for bfgminer using the ASICs.

2. Copy the CGWatcher folder to another location, so if the original is C:\Mining\CGWatcher, you could name the second copy C:\Mining\CGWatcherB. Or you could put one CGWatcher folder inside of the other one. The important thing is that each has its own folder and therefore its own cgwatcher.exe.ini file.

3. With all miners closed, open CGWatcher A (the one you want to use with ccgminer) and go to the Settings tab. Make sure the 'Miner IP Address' setting is set to 127.0.0.1:4028 and check the 'Use only this API port' checkbox. Click Save Settings to save the changes.

4. Start the other CGWatcher (B, the one you want to use with bfgminer) and do the same, but this time change the 'Miner IP Address' to 127.0.0.1:4029. Click Save Settings.

So you should now have both CGWatchers running and each is using a different port. You can set the port number to any port number not in use, but 4028 and 4029 should work for most people.

5. In each CGWatcher instance, set the profile you want that instance to use. So CGWatcher A would use a cgminer profile setup to use GPUs, and CGWatcher B would use a bfgminer profile setup to use ASICs.

6. Start the miner in CGWatcher A, then start the miner in CGWatcher B.

The other option is trying to get GPUs and ASICs working all in one miner, but I understand that is not always preferable as different versions might work better with certain devices. If you have any questions or problems, let me know.

The new version of CGWatcher (1.2.3) should do this. Create a scheduled action that either disables the GPU(s) or turns the intensity down on them when a certain program starts, then create scheduled actions to return the settings to normal when the program stops. I tested it with Calculator quite a bit and it worked without incident, but there seem to be some systems where CGWatcher has permission issues when trying to get information on other processes (including the miner). In that case, running CGWatcher as Administrator usually resolves this.

Note: the disable device action will only disable a GPU in terms of mining so you can use the GPU for other things.

Let me know if you have any questions or problems setting this up if you choose to try it.

Version 1.2.3 is available. I updated the original post but if you're already here, the most prominent changes in this update are:

• Restart computer if accepted or total share count doesn't change for N minutes.
• Config files can now be set to URLs in Profile Manager.
• New scheduled action: change intensity for specified GPU.
• Switch to most profitable, most profitable (adjusted), most profitable (average), lowest difficulty, highest reward, lowest network hashrate, lowest network hashrate (average), or next profile.
• For each of the conditional profile changes, you can set 1st, 2nd, 3rd, etc. to get 1st most profitable, 2nd most profitable, 3rd most profitable, etc. of the coins you mine (have linked to a profile)
• New scheduled action frequencies: Run on specific date at specific time, run when computer becomes idle, run when computer becomes no longer idle, run when specified program starts, run when specified program stops. These can trigger any scheduled action.
• Allow customization of FPGA and ASIC devices to correct the miner reporting them incorrectly (e.g. BFGMiner reporting all ASICs as FPGAs. You can even create custom codes and names for devices.
• Performance improvements, including CGWatcher startup.
• Auto-update option with included utility to automatically update to new versions.

Version 1.2.3 is available and should have most of the features that had been requested, most notably:

• Restart computer if accepted or total share count doesn't change for N minutes.
• Config files can now be set to URLs in Profile Manager.
• New scheduled action: change intensity for specified GPU.
• Switch to most profitable, most profitable (adjusted), most profitable (average), lowest difficulty, highest reward, lowest network hashrate, lowest network hashrate (average), or next profile.
• For each of the conditional profile changes, you can set 1st, 2nd, 3rd, etc. to get 1st most profitable, 2nd most profitable, 3rd most profitable, etc. of the coins you mine (have linked to a profile)
• New scheduled action frequencies: Run on specific date at specific time, run when computer becomes idle, run when computer becomes no longer idle, run when specified program starts, run when specified program stops. These can trigger any scheduled action.
• Allow customization of FPGA and ASIC devices to correct the miner reporting them incorrectly (e.g. BFGMiner reporting all ASICs as FPGAs. You can even create custom codes and names for devices.
• Performance improvements, including CGWatcher startup.
• Auto-update option with included utility to automatically update to new versions.

Assuming I didn't break anything too bad, the CGRemote beta will be next.

I checked and found I didn't have any logging for computer restarts, so I've added some in 1.2.3 so you can check the logs to see if a restart was attempted. By default I set it to not use the force close flag, though I've also changed this in 1.2.3 so it always will. It gives a 30-second countdown before restarting, as well as a Cancel button, so I don't think the force close flag is too intrusive.

CGWatcher also disables the WER UI on starting which prevents the "Not responding" prompt from appearing, which could also cause a halt. CGWatcher restores the original value on close. While it has done this for many previous versions, in 1.2.3 it saves the original value to the INI file in case it is not restored before the computer is restarted, allowing it to be restored to the correct original value the next time CGWatcher closes.

Aside from you losing the remote display, how have you verified that it stops mining? By checking the pool? If this is the case, an option to restart the computer if accepted shares stop increasing for X minutes or something similar may work. I plan on adding several triggers like this to the schedule, so you could create a scheduled action to restart the computer if accepted shares don't increase for 10 minutes, for example. My goal is to provide enough scheduling options that no matter what condition or action you want, you can schedule it. The difficult part is figuring out how to keep the process of creating these actions as simple as possible. Along with creating actions to run at a certain day or time, there will be actions that are triggered by events or circumstances.

And the CGRemote beta will be starting soon, which assuming the computer is not frozen, would allow remote access to CGWatcher. It can also access the miner directly for non-Windows systems, but that method is somewhat limited to control because if the miner stops responding or its API stops working, you have no control. Future plans involve creating a small Linux and OSX "listener" app that is lightweight compared to CGWatcher but is able to kill and launch the miner using commands sent to it from CGRemote. I'm not sure how soon I'll be able to get to that though. So for Windows-based miners running CGWatcher, as long as CGWatcher is running and responding, you can initiate a computer restart (or many other actions) using CGRemote.

Have you tried the 'Restart computer when sick or dead GPUs are detected' monitor option? In my experience, display drivers crashing always cause a GPU to become sick. So if this is always the case, this monitor option would work. But... this might not always be the case so if you have seen a driver crash that hasn't resulted in a sick GPU (it doesn't happen right away, it may take a minute or two), let me know. If that is the case I would have to figure out a different way of detecting driver crashes... which I wouldn't say is impossible, but isn't something I've looked into.

I've spent most of today adding additional schedule options and changing the way they are triggered to make sure none are ever skipped, so I'll try to get the additional profitability options worked in. I may have to redesign the scheduled action form because it is growing more and more complex, at least from my point of view. For the user it should still be comparable to building a sentence.

And thank you for the donation.