Topic: CGWatcher 1.4.0, the GUI/monitor for CGMiner and BFGMiner to prevent downtime - page 20. (Read 180386 times)

milone have you considered making something that's Avalon friendly like custom built and applied within firmware of it ?

I definitely do

Version 1.2.6 has a ton of improvements and bug fixes, and anyone using CGRemote should update to this version with the new CGRemote update (1.0.3). See original post or readme for most of the changes (I stopped writing them down after a while.)

If an ASIC is being shown as an FPGA it is because the miner is reporting it that way. BFGMiner seems to treat all ASICs as FPGAs as far as the API goes, while CGMiner does differentiate the two unless an ASIC is using FPGA drivers (or something along those lines). This is why I added an option to customize a device so you can change it to at least appear correctly in CGWatcher. In the bottom left corner of the device detail display there is a link labaled "Edit device". Clicking this will allow you to change what the device is and even customize its name (although behind the scenes it is still treated as an FPGA when communicating with the miner). I don't have FPGAs or ASICs yet so testing of this was limited, so if you experience any problems let me know.

The miner also treats unplugged-then-plugged-back-in devices as new devices, so CGWatcher is being told there is another device. I'll add an option to hide devices to handle this. Does the hashrate of the old device go to zero? Or is there any changes to the device's data that I could look for to hide it automatically?

If you do provide more information, the "Create Debug Report" button in the Tests tab will dump a bunch of info that may be helpful. Also in the Tests tab there are buttons labeled "Show FPGA" and "Show ASIC". When you have these ghost devices, if you click "Show FPGA" and send me the results I may be able to find something to determine if a device needs hidden or not. Preferably send this info to my email (in the readme) as it's a lot of data to dump into this thread.

When there are BitErupters being used they are shown on the FPGA tab.

Whenever a device is unplugged and plugged into another port a ghost device is left behind.

Could it be possible to hide these so they don't fill up the status page in Devices > FPGA?

Thanks! To avoid such glitches i using now a multiple pools in bfgminer config.   CGwatcher the best and forever!

Yeah I need to have it switch to the next most profitable in this case if all pools in 1st most profitable are down. It also needs to do this if it switches to a profile that has incorrect configuration that causes the miner to not start, which in that case it should just go back to the profile it was previously on. I ran into this myself the other day but have been busy with CGRemote so I'll work on it as soon as I can.

I have some problems when enabled scheduled mode "switch to the 1st most profitable" and in this time sometimes some pools are having status "DEAD", and cgminer/bfgminer glitch.. can't be started normally..  Please fix this at the next update or add a new scheduled mode to avoid these glitches..

P.s. sorry for my english I'm from afar

Alright the next time I see it happen I'll get the debug file.


1) It is indeed 10 seconds interval set in Settings, but it lasts for long enough that "Restart miner/computer if below x hash rate" with the 3 minute grace period kicks in and restarts the miner repeatedly every 3 minutes

2) Yea, no idea why this happens though.


3) It's probably still warming up, cos this was taken a few seconds into starting the miner, GPU1 normally catches up in the next few seconds if you leave it alone

Also, I do have another program that has API access.  It's a bare minimum monitoring software, but doesn't require exclusive API access.  It works flawlessly as it pushes it's stats to a website and it works for days without restarting the miner, but once in awhile CGMiner restarts the miner.  Couldn't manage to see what the Notification said in time though ):

Thanks a bunch

When this happens, please go to the Tests tab and click the 'Create Debug Report' button and email me the results (address in readme).

CGMiner doesn't return a value for total (current) hashrate, so it is the sum of hashrates for all mining devices. Because of this there may be a delay in updating the total current hashrate because devices are updated on their own thread and although they refresh at the same interval the monitor interval, they don't necessarily occur at the same time. So if your monitor refresh interval is 10 seconds, it may refresh and then take up to ~10 seconds for the devices (and total current hashrate) to update. Ideally in this example they would run 5 seconds apart, but that doesn't always happen. That may not be the issue here but is worth mentioning I guess.

CGWatcher uses the temperatures reported by CGMiner if available. Otherwise it retrieves the temperature on its own. So for the temperatures to be that different, something is happening that is causing CGWatcher to not get this info from CGMiner... and then for some reason the temperature it gets is wrong, or off.

And lastly, did something happen to GPU1 in the example you've shown? It has a higher hashrate but lower accepted shares (and a lower temperature but that may be coincidental). Was it possibly disable and then re-enabled at some point? Do you know what CGWatcher reported as the status for GPU1?

Anyway, it's difficult to say without the debug info. Including cgwatcher.log in the email (as an attachment) may be helpful as well as it goes back further than the debug report.

I've got a bug that has been happening quite often lately.  Started about 2 versions ago I believe (currently on 1.2.5.1)  The reported "Current Total Hashrate" sometimes doesn't match up with what CGMiner says, and as a result, it falls below my restart-miner threshold.  This ONLY happens after CGWatcher restarts my miner for some reason (not driver crash or anything).  This can only be solved by closing CGWatcher completely and restarting it again.  Also, temperature reading has been very different as well.  It doesn't seem to read from CGMiner anymore, as you can see the reported temps are all different than what CGMiner reports (actually, this instance GPU 0 was right, but it has been up to 10c wrong in the readings often too).

This was resolved earlier by email but for anyone else with similar problems, there is a bug that occurs when a profile's config file has " -" (space dash) in the filename. Because CGWatcher then adds the config filename to the arguments, and it uses " -" to separate arguments, it garbles the arguments. I thought I handled this but I'm obviously off somewhere. I'll fix this in the next update, but a temporary workaround is to delete all arguments for the profile, set its config file to the renamed file without " -" in the filename, then you can add back any arguments you originally had in the Miner Arguments textbox and save the profile.


Edit: this bug actually affected profiles that had config file filenames with spaces, even without a following dash. It has been fixed and 1.2.5.1 is available. It's also worth checking that profile arguments aren't scrambled, though that should only be the case if you saved the profile recently.

I just sent you the email with the debug conents

I haven't changed anything related to cgminer's API or monitoring (at least not that I can think of, but there is always the chance that changing something can affect something else I didn't think of). Most of the recent changes have been related to CGRemote, which is its own separate component.

I'm not sure exactly where you're having the problem... is it that CGWatcher does not connect and monitor cgminer after it starts it? If you use CGWatcher to start cgminer, it should take care of enabling the API automatically if it's not already enabled. If you can reproduce the problem, or specifically: start CGWatcher and click Start Mining so it launches cgminer. If it does not connect to cgminer (it will say something about not being able to connect to cgminer's API), go to the Tests tab and click Create Debug Report and email it to me (address in Readme). This gives a dump of info that should be helpful in figuring out what has gone wrong.

There are also permission issues that are occasionally reported, but you should be able to rule this out if you run CGWatcher as Administrator and the problem still occurs.

This is the 3rd or 4 version and they have been flawless for me, but I just tried the latest update on two of my machines and it failed on both. It seems to be related to the API, which I see the previous couple of posts are about, but not in reference to it failing. If it matters, both of my machines are on window7-64bit with the latest version of cgminer. I tried several different things, such as doing it from a fresh start, with both a new copy of cg miner and not importing any of the watcher config (except for the config file for cgminer) I tried some other things too, but I'm a little lost when it comes to configuring API setting. Just before sending this here, I ran the debug and giot the message "no connection could be made because the target machine actively refused it 127.0.0.1"

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.

From my experience, no.


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.

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

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

ok thanks 
i'll give it a try