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

[atariguy]

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...

Thanks! At first I had a hard time getting 2 instances of CGWatcher to run, but then I updated to the latest version and that fixed that problem. I've now got it working, but there is one problem. For some reason, CGWatcher launches 2 instances of the mining programs. This happens even when there is only one instance of CGWatcher running. This didn't happen in the older version I had been using, so it's either a new bug or I have something wrong on my end (which could well be the case). Have you had other reports of this?

[milone]

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.

[play]

On latest version, when you start cgwatcher does launch 2 cgminer. One is from the tick in "Run miner when started" other one is from the option "Ensure miner stays running unless paused or stopped in CGWatcher".

On my rigs I just left the last option and everything else seems fine.

[milone]

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.

[atariguy]

Yep, what play described is what was happening. I've now changed the settings to fix it.

[Japs2013]

I just started using CGWatcher, and I must say I'm impressed. My CGminer sometimes stalls; I hope CGWatcher will prevent the loss of BTC by automatically restarting CGminer ;-)

[naimc3243]

I really appreciate CGMiner but I have not been able to keep up updating my Miners with each new release.

-What is the best way to carry over profiles and setting from previous to new version ?  ( I currently copy over the profiles.dat from the previous version over-writing the empty profiles.dat created by the newer version)


In the features dept, I still use manual batch files to launch my cgminer with the API access enabled then I start cgwatcher. ON different PC's for example I have noticed that Semptron 145 single core will yeild better hash rates with the Process REALTIME  priority  ( ie  start /REALTIME cgminer.exe )

On a system with multiple cores I will often bind cgminer  (ie start /AFFINITY 01  cgminer.exe to a "specific" core).  This way I can use the other cores for other jobs, without seeing CPU load / latency from other process slow down the cgminer hash rates.

It would be interesting to see these feature built in cgminer.

Thank you for the excellent software.

[milone]

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.)

[Loft]

Hello milone!
I can't specify a configuration file voltage(gpu-vvdc 1.050,1.050,1.165,1.165) 4 graphics cards. When checking the config error POPs up. How to fix this?

[milone]

Hello milone!
I can't specify a configuration file voltage(gpu-vvdc 1.050,1.050,1.165,1.165) 4 graphics cards. When checking the config error POPs up. How to fix this?

... what does the error say? And pasting your config file would be helpful. Does the error occur when you start the miner or when you try to open the config file in the Config File Editor? I can't tell you how to fix it with no information.

Also, it's gpu-vddc, although that shouldn't cause an error in CGWatcher - it would just think it's a different option. Having invalid json (incorrect format) will though. The option should be in this format in the config file:

Code:

"gpu-vddc" : "1.050,1.050,1.165,1.165",

(the comma at the end may need to be removed if this is the last option listed in the config file)

[Loft]

... what does the error say? And pasting your config file would be helpful. Does the error occur when you start the miner or when you try to open the config file in the Config File Editor? I can't tell you how to fix it with no information.

Screeshot error

error occur when I try to open the config file in the Config File Editor.
As I understand CGWatcher ignores the option and does not pass it cgminer, as the voltage is not changed. I change with the help of MSI AB.
My config file:

Code:

{
"pools" : [
	{
	.....
	}
],
"api-allow" : "W:127.0.0.1",
"api-listen" : true,
"expiry" : "1",
"log" : "3",
"queue" : "0",
"scan-time" : "2",
"scrypt" : true,
"auto-fan" : true,
"auto-gpu" : true,
"gpu-threads" : "1",
"gpu-engine" : "1020-1105,940-1020,1130,1130",
"gpu-fan" : "90-100,90-100,60-90,65-90",
"gpu-memclock" : "1250,1250,1250,1250",
"gpu-memdiff" : "0,0,0,0",
"gpu-powertune" : "15,15,10,10",
"gpu-vddc" : "1.050,1.050,1.165,1.165",
"intensity" : "19",
"temp-target" : "75,77,70,70",
"temp-overheat" : "85,85,85,85",
"temp-cutoff" : "95,95,95,95",
"lookup-gap" : "2",
"thread-concurrency" : "21696,21696,14144,14144"
}

[milone]

Thanks, this was a bug related to culture settings. It should be fixed if you download again, if not let me know.

Also, you can un-check the Validate before saving checkbox to skip validation checks before the config file is saved. This will allow you to save config files even if CGWatcher thinks the values are incorrect. But that is a workaround and I'd prefer to fix any bugs causing validation to fail.

Thanks for reporting.

[Loft]

Thanks, this was a bug related to culture settings. It should be fixed if you download again, if not let me know.

Also, you can un-check the Validate before saving checkbox to skip validation checks before the config file is saved. This will allow you to save config files even if CGWatcher thinks the values are incorrect. But that is a workaround and I'd prefer to fix any bugs causing validation to fail.

Thanks for reporting.

milone, I first found this bug from 1.1.4.1 ...and in other versions, there he is in 1.2.4
OK, I try un-check the Validate before saving.

[Isamaru]

Its just me or TROJAN!?!?

http://imageshack.us/a/img42/8721/urc6.jpg
http://imageshack.us/a/img543/4598/5wbw.jpg

or false positive?

[milone]

It's a heuristic false positive that only happens with kaspersky (heuristic meaning it didn't find malicious code, it is just making a poorly-educated guess based on some characteristics.) I've sent false positive reports and they admit it's a false positive and correct it for that version, but then if I make any changes at all (like a bug i fixed today) it becomes another false positive. I've asked them how to resolve this, but they haven't answered other than to say a specific version's false positive was corrected. I update too often to go through this every time, so they need to be a little more helpful than whitelisting an md5 or sha hash.

I've posted more info at http://manotechnology.blogspot.com/p/false-positives.html

Upload the files to virustotal.com to see the results from 45+ antivirus scans.

[Isamaru]

ok thanks 
i'll give it a try 

[xIIImaL]

Hi everybody from Ukraine! And all developers!! Very. very good job! Finally, i'm happy miner without lags and loosing profits

[add1ct3dd]

Does CGWatcher demand exclusive API access? Can't connect other things to the CG/BFGminer api when CGWatcher is enabled - anyway to fix this?

[play]

Does CGWatcher demand exclusive API access?

From my experience, no.

Can't connect other things to the CG/BFGminer api when CGWatcher is enabled - anyway to fix this?

If you add something like this " --api-listen --api-allow W:127.0.0.1,W:192.168.1.0/24 " the api will be available to any computer in you network using 192.168.1.x ip.

[milone]

Does CGWatcher demand exclusive API access?

From my experience, no.

Can't connect other things to the CG/BFGminer api when CGWatcher is enabled - anyway to fix this?

If you add something like this " --api-listen --api-allow W:127.0.0.1,W:192.168.1.0/24 " the api will be available to any computer in you network using 192.168.1.x ip.

Right, CGWatcher does not demand exclusive API access, it connects only long enough to send and receive. It does automatically add the api-allow option if it is not present when it starts the miner, and makes sure that 127.0.0.1 is included in the write privilege group (W:). It should leave anything else in the W: group, or any other group, alone... it just inserts 127.0.0.1 if necessary.

If you use api-network, this may be ignored when CGWatcher adds api-allow (api-network is ignored if api-allow is used). So I'd suggest not using api-network and using api-allow and setting which IPs you want to allow access. Api-network opens it up to everything, which I wouldn't recommend.

Just last night I tested CGRemote overnight without any problems, so it was continually talking to cgminer via API while CGWatcher was also talking to cgminer via API (and CGRemote and CGWatcher were talking to each other as well, but that's unrelated). API responses are very quick so there should not be any collisions in terms of two trying to access the port at the exact same time... and even if it happened the programs should handle it and move on.