Mt.Gox is a lot of things, but bankrupt is not likely one of them. They make a ton of money and they obviously don't invest all of it back into hardware and software. I'd put my money on incompetence rather than bankrupt, but I don't know that that makes it any better.

You can also use CGWatcher to run cgminer hidden, then minimize CGWatcher to the system tray. This way you can bring up the window whenever you want to see stats and temps. On top of that, it fixes problems cgminer runs into to make sure it stays mining. There are also options for running on Windows startup. While I can understand reluctance to download and run executables, and encourage due diligence before doing so, 2,000+ users and growing should help attest it is not malicious.

More info and download:

http://manotechnology.blogspot.com/p/cgwatcher.html


Official thread:

https://bitcointalk.org/index.php?topic=185553.0


Newbie thread:

https://bitcointalk.org/index.php?topic=159267

I just uploaded 1.1.9. I am hoping it will resolve any reported issues with batch files, among other improvements.

There is also a donation mining option in the Schedule tab. Please consider donating a small portion of your mining time to support this project and CGRemote.

There were still some issues with batch files in the last version, so I am hoping they are fixed in 1.1.9. I rewrote quite a bit of the code responsible for starting and communicating with the miner, but if you have issues I'll try to get them fixed quickly.

There is also a donation mining option in the Schedule tab, so please consider donating some mining time to this project if you're not one of the dozen users who sent donations.


Humax: It should... it should not have any effect on how the miner works with proxies.

I'm working on it right now... well, that and trying to add full support for "include" in config files. Someone else said batch files were not working correctly, but I need more info because the batch files I've created for testing all work.

I've tried to make getting this info as easy as possible. After starting the miner in 1.1.8.0c, go to Tests tab and click Create Debug Report, then preferably email me the results because it is a lot of text. This debug report should show the contents of your batch file near the bottom. If it doesn't, could you send me that as well? If it is not included in the report it may be related to the same issue causing it to fail to monitor the miner correctly.

No... it is currently Windows-only. CGRemote will work with it, but it's not finished yet.

If you're using CGWatcher with .bat or .cmd files to launch the miner, please make sure you're using 1.1.8.0c as it has some important fixes for handling these files correctly.

Any bugs or problems can be posted here, on the download page, or sent to the email in the Readme.

Good to hear. That's interesting, and yet another thing to add to the list of unexpected behaviors. I'm not sure which setting(s) are causing this, but most likely I'll change it to not leave out any options, even if they are set to default values. As I mentioned, my concern in doing this would be that it would introduce a new unexpected behavior, so I want to think about this more before I just make the change and I'm heading to bed at the moment.

If you get a chance and don't mind, make sure you have the latest version (1.1.8.0b) and remove those two lines (api-listen and api-allow), save the config, and start the miner again. I'm just curious as to whether your particular issue has been fixed in the update. If you get a chance to do that and can let me know if the hashrate is affected, I'd really appreciate it.

I've also made additional changes in 1.1.8.0b that limit the need for CGWatcher to modify a config file when starting the miner even more. If I can ultimately have it avoid doing this at all, that is my goal. But if you're using arguments and a config file, it is currently necessary in order to have the argument settings override the config file settings... as well as the other couple scenarios I mentioned like API enabling (although this has been limited more in 1.1.8.0b). Anyway, I'll make sure this is resolved in 1.1.9. Thanks again for the help.

Unfortunately I didn't see anything that stood out that would explain this. I did make a few proactive changes so I'd recommend you download again to get the updated files. Then as a test to make sure this is not a config file issue, can you add the options to your config file to enable the API? Add the two lines (api-listen and api-allow) to your config file as shown below and save. (I added them after api-port, but you can put them anywhere. Just make sure to include any necessary commas in between options):


Why I suggest trying this is because enabling the API will mean CGWatcher does not have to modify your config file before it launches the miner. You can see from the info you posted that it did modify your config file to enable the API right before it started the miner (debug_config.txt), and then restored the original after the miner started. You can see when comparing your config file with debug_config.txt that no settings were changed aside from API being enabled, but settings that were set to default values were left out because they're default values and those values should be used anyway. The reason for this initially was to reduce the options listed in config files because CGWatcher has a lot of users new to mining and there is often confusion about setting up config files. I figured the less options there were, the easier it would be to follow.

I was also leaving out scrypt options like lookup-gap, shaders, and thread-concurrency if the scrypt option was not enabled, but I just changed that as well to make sure it is not a misunderstanding on my part how those work. I've also reduced the number of options that it may leave out if set to default values. Now only numeric options (e.g. vectors, worksize, etc.) set to the default value explicitly listed in cgminer's Readme are left out. Before it was also doing this to non-numeric options like kernel path, etc., (which also have default values explicitly listed in the Readme.)

You may ask why not just use arguments to enable the API. That is because cgminer gives priority to the config file, not to arguments. (I wanted CGWatcher to do the opposite, allowing you to, for example, use a base config file for multiple profiles and just tweak some options using arguments. This is what I'd guess users would expect to happen.) This means if I want to make sure an option is set, I have to do it in the config file. If I set --api-allow W:127.0.0.1 in arguments and in the config file api-allow was set to "api-allow" : "W:123.45.67.89", cgminer would use the 123.45.67.89. I have and will continue to try to reduce the situations where CGWatcher has to modify a config file at all... but for now if you don't have API enabled, have forced API port enabled, or are using arguments and a config file together, CGWatcher will modify the config file right before starting the miner and then restore it afterwards. This is the purpose of debug_config.txt... so if the thought of CGWatcher modifying your settings worries you, you can see exactly what the config file said when the miner was started.

Aside from those options being left out of the config file having an effect (even though they were set to default values), I don't see a reason for a drop in hashrate cause by CGWatcher. Are you reading the hashrate from cgminer both times? I have CGWatcher and cgminer running on multiple machines and have not seen any decrease. Even running multiple instances of CGWatcher and cgminer on the same computer did not cause a decrease in hashrate.

Can you provide a little more info? Are you looking at the hashrate in cgminer both times? I ask that to make sure it is not just a problem with CGWatcher displaying hashrates incorrectly. CGWatcher doesn't change any settings other than enabling the API, and specifying the API port if necessary.

Can you provide your config file and/or arguments? Also, if you use a config file there should be a file called debug_config.txt in the CGWatcher directory. If you can include that as well to make sure nothing is getting incorrectly changed before the miner is started. Also the text in the Report tab may be helpful.

It's a lot of info, but it will help me find a problem quickly if one exists. You can either post the contents of the files here or email them to me (email address in ReadMe).

Thanks, I appreciate the feedback.

It is possible that at the highest intensity, the extra work needed to display CGWatcher slightly affects performance... especially for scrypt and intensity 20. Although this is not something that has been reported previously, and I haven't experienced this with my (two) 7950s. I'm not doubting your post, just hoping this is not the cause because there is not a whole lot I can do about it in this case. It's no secret that displaying a GUI requires more work, but in my opinion its advantages justify it. This is likely a top reason cgminer doesn't have a GUI. Perhaps I could ultimately move to a very basic window showing hashrate, temps, etc. and only show the main window when necessary (or requested) since it is filled with controls.

I don't think the API calls would cause this because neither program uses much CPU, but increasing the monitor interval in CGWatcher would help if this is an issue as API calls would occur less often. I've been reducing API calls whenever possible over the past few versions anyway, but there may still be some room for improvement.

If you experience a decrease in performance at max intensity (especially for scrypt), I guess you just have to decide if the benefits CGWatcher provides outweigh the decrease. I'd like to think it does... if cgminer unexpectedly stops working for an hour, the slight decrease suddenly becomes acceptable. But I guess that depends on how often your miner has issues or whether or not you prefer a GUI.

Either way, thanks for the info and I'll definitely keep this in mind and look to reduce the footprint whenever possible in future updates.

Thanks. See my reply here: https://bitcointalk.org/index.php?topic=159267.msg2511587#msg2511587 regarding the .bat problem you were having. I just fixed this, download 1.1.7.0a to get the fixed version.

Damnsammit: Sorry, this was a bug. The bug was saving the .bat filename in the .bat file instead of the .exe filename. This should be fixed now in 1.1.7.0a.

It may still save the entire file path of the .exe file. The same with config files... it may save the entire config file filename inside the .bat file as well. This won't cause any problems and was not causing the problem before, but I'll work on having it not do this if you prefer. I can't promise how soon, but I'll put it on the list.

Version 1.1.7 is up. See original post for changes, and as always please let me know if you experience any issues. Also, please consider donating if you find it helpful. Additional donation options have been added in the About tab.

Among many fixes and improvements,  new scheduling option has been added allowing you to set CGWatcher to increase intensity when your computer is idle. When you come back to the computer it will return intensities to their original values.

pluMmet: Hopefully. I'm not able to open-source it yet because parts of the code are being used in another project, but when I do hopefully someone can port it. I have no Linux experience.

Fallon: Thanks, this was a bug and is fixed in 1.1.7 which is now available.


WuLabsWuTecH: Yes, make sure you're using the latest version because previous versions didn't support this. Right now you would have to run each CGWatcher instance from a separate folder because I haven't handled multiple instances writing to the same INI file yet. So, for example, you'd have to create C:\Miners\CGWatcherA and C:\Miners\CGWatcherB. Also, each instance and miner need to use their own API port, so

CGWatcher A  <->  Miner A    (port 4028)

CGWatcher B  <->  Miner B    (port 4029)

In CGWatcher A, go to the Settings tab and make sure Miner API Address is set to 127.0.0.1:4028, and check Force this API port. Click Save Settings.

In CGWatcher B, go to the Settings tab and set Miner API Address to 127.0.0.1:4029, and check Force this API port. Click Save Settings.

This will ensure that when you start a miner from each CGWatcher, it will make sure the miner is using that port regardless of what its config file or arguments say. Both CGWatcher instances can point to the same miner, and even point them to the same config file... but you'll need to use each CGWatcher's arguments to set which devices you want each instance to use.

To make things easier, you could setup CGWatcher A and then copy all its files to CGWatcher B. That way it will copy profiles and settings and all you'll need to change is the port setting mentioned above and set which devices each instance will use. As as example, CGWatcher A would use a profile with arguments -d 0 (to use device 0) and CGWatcher B would use a profile with arguments -d 1 (to use device 1).

I'm not sure what you mean by "shut down one device", but if you just want to stop a GPU or FPGA from mining you can disable it using the Disable button in the GPU or FPGA tab. I don't think there is currently a similar option for ASICs, but I can't think of a reason you'd want to disable an ASIC if you have one anyway.

16 Credits ($400 savings) for 2 BTC (~$200) or best reasonable offer.

The best answer would be to just create a profile for the miner. If you have and it still prompts you, please send me more info. The Report tab text, your profiles.dat file contents (you can open in Notepad), and any relevant log entries would be helpful.

Any time CGWatcher detects a miner process running that it did not start and didn't previously monitor, it tries to match it to a profile. The reason for this is because if it knows which profile/config file/arguments the miner is using, it can provide better information and control for things like overheat protection (where it needs to know your config temp-target, temp-overheat, temp-cutoff, etc.) and isn't reliant on the API alone. It also makes it more easier for new users to setup profiles for different miners.

How it works specifically is that CGWatcher tries to match a miner process to a profile based on miner path and API port (from the profile's config file or arguments). In other words, it looks to see which API port the profile is using and if it can establish communication on that port... and the process's filename match the profile's miner path (executable path if a .bat or .cmd file is used)... it assumes that is the correct profile. It also checks profiles in a specific order to try to best determine the profile in the case that multiple profiles match. If it finds that the miner does not match a profile, it will ask if you want to create one. It should only ask you this once per process, so it won't ask again unless you close and re-launch, or restart the miner (because restarting creates a new process). I suppose it could get a little annoying if you restart the miner and it prompts you again, so I'll try to fix this.

I think if I ever create version 2.0 it will just ignore any miners it did not start. That would make things much simpler.

gektek: You're welcome, I'm glad you find it helpful.


ct1aic: cgminer deserves the credit for that. It allows you to set clock speeds above what the AMD (or similar) software allows. I don't know how the AMD software determines what the max clock speeds are, but I'd guess that cgminer either doesn't check this or ignores it. The same is probably true of voltages, although if you raise voltages past what AMD recommends you risk damaging components.


PatMan: CGWatcher is currently Windows only, though that may change in the future. I'm also working on a program called CGRemote, which will allow you to monitor multiple miners regardless of OS (however if it is a Windows miner I recommend running CGWatcher on the miner as well because this will give you better control - see diagram in reply above). There is another project I'm going to be working on for the next 6-8 weeks but hasn't been finalized yet so aside from any bugs popping up in CGWatcher, I will be trying to get as much done on CGRemote until I begin the other project.


RandyMagnum: Correct, if cgminer is managing temperatures for a GPU, CGWatcher will not interfere. The only exception to this is if cgminer disables a GPU for exceeding temp-cutoff (default 95c). It is supposed to re-enable the GPU once it cools down, and will even show in its UI that it attempts to... but in testing I've never seen it succeed in successfully re-enabling the GPU. So when this occurs, CGWatcher will restart the GPU to make sure it gets going again. This only happens if CGWatcher's overheat protection is enabled (in the Monitor tab).

You can verify which program is providing the overheat protection for a GPU in the GPU tab. If you scroll down the large textbox at the bottom, you'll see "Overheat protection........" It will say either "CGMiner auto-gpu mode" if cgminer is doing it, "CGWatcher" if CGWatcher is doing it, or "None" if neither program is doing it. It also displays a green shield or yellow warning symbol next to the temperature, which if you put your mouse over will provide you with details of what overheat protection is enabled for that GPU.

If you don't want CGWatcher to interfere at all when it comes to overheat protection, you can disable it in the Monitor tab. There was a bug with the checkbox not being checked correctly when the program starts up (even if overheat protection was enabled) that I fixed yesterday, so make sure you've downloaded 1.1.6.0a to ensure it will correctly show you whether it is enabled or not.

Set the temp-target, temp-overheat, and temp-cutoff settings to values you prefer. The default values (given by the miner, not CGWatcher) are 75°C, 85°C, and 95°C respectively. You can set these settings in the config file or in the arguments.

Alternatively, you could disable overheat protection in CGWatcher's Monitor tab (make sure you're using 1.1.6.0a, otherwise you have to disable it in the INI file.)

Overheat protection is enabled by default and will do this to GPUs that the miner is not providing overheat protection for. The reason the miner would not be providing protection for a GPU is
a) the miner is unable to get a temperature for the card (specifically, Nvidia GPUs), or
b) the auto-gpu option is disabled which has to be enabled for the miner to really care about temperatures (although auto-fan may make it adjust fan speeds to keep in target range, its clock speeds will not be adjusted and it will not be disabled if it gets too hot.)

So your GPU meets one of these criteria. The temperature is exceeding the temp-overheat of 85°C (as it says it is 90°C), so it is attempting to reduce intensity to get the temperature back into the temp-target range.


Edit: Also, the reason you initially had API problems was because you used --api-allow without setting a value for it (e.g. W:127.0.0.1). This was unexpected on my part, so the next update will handle this.


Edit #2: I had found a bug that caused the overheat protection checkbox to not be checked on startup if overheat protection was enabled. So even if it was unchecked, it still may have been enabled unless you checked and unchecked the box yourself. Downloading again (1.1.6.0a) will give you the fixed version.

The newer versions should take care of enabling the API for you, but maybe there is still an issue I need to work out.

Try changing


to



And let me know if that helps. I'll go over the API enabling code when I wake up.