Post
Topic
Board Mining software (miners)
Re: CGWatcher 1.3.5, the GUI/monitor for CGMiner and BFGMiner to prevent downtime
by
milone
on 19/02/2014, 05:25:03 UTC
I wasn't aware of any bandwidth limit exceeded problems with the new support forum (http://www.minerremote.com/support) but I will look into this and encourage everyone to post issues there. Because it is divided up into sections, it makes it easier to find help and even for you to help others with issues that you've been able to solve.

I've been driving much of this past week but I've finally made it to Los Angeles... so I'll be catching up on support and getting back to updates as soon as I find a house or apartment. Even if it takes me a few days to respond, I can assure everyone that both CGWatcher and CGRemote projects are still very much alive, in fact more so now than ever. Big things underway. Wink

I'll try to answer everyone's questions without taking up too much space:


Timmieman:  An Ubuntu solution may be coming soon.


ymer:  I'll look into this. Every time the miner is started by CGWatcher, it resets the flag saying whether or not CGWatcher closed the miner. Then the only time the flag is turned on is when the stop button, pause button, or scheduled actions that stop mining occur. It's possible the flag is not being set when it should, which I'll have to see if I can find.



Ntrain2k:  I haven't had a chance to look at sgminer yet. If it works sometimes and sometimes not, then it's probably an sgminer issue. If it freezes every time CGWatcher tries to start sgminer, then it may be a config setting that sgminer doesn't like (perhaps a setting that was removed).



Megistal:  When using batch files, CGWatcher first watches for the batch process to launch, then watches for the miner process to launch. I believe it waits up to 15 or 30 seconds for this to happen, so if it takes longer than that it assumes there is a problem. If I understand you correctly, you have a step in between - the batch file launches an app that launches cgminer? Being a 64-bit OS using a 32-bit miner should not make a difference.


vladman:  From what I remember, this is an issue with cgminer/bfgminer. Setting clock speeds in one instance's config settings can affect an already running instance. You can try setting the clock speeds for both instances in both config settings, but I'm not sure if that will work. I guess it's possible for CGWatcher to check after launching the miner (e.g. 30 seconds after launch) and make sure the config settings match the current GPU settings. It's something that will take some time though... a lot on my plate at the moment.


ammi84:  If there's nothing in CGWatcher's log then it's difficult to say why the miner closed unexpectedly. It's not something I've run into. I would suggest enabling the monitoring option "Ensure miner stays running unless stopped by CGWatcher" and see if this helps prevent downtime.


jazzah:  Unfortunately I don't think this is a CGWatcher problem. When using batch files, CGWatcher launches the batch file and what happens next is out of its hands. Once it launches the batch file, it waits to get a response from the miner's API, which is why it gives up after 60 seconds or so of getting no response and tries launching the batch file again. It's been said that you can set the GPU_MAX_ALLOCATION and similar settings so you do not need to set them every time you launch the miner... perhaps being able to remove those from the batch file would resolve this issue.


techman05:  I've added your suggestion to the to-do list, but it's a pretty long list at the moment. You can create your own profitability field, which can then be used in place of the regular profitability fields. When creating your own field, you can create conditional expressions... so you can create something like if(REWARD > 10, PROFITABILITY, 0). This means that for each coin, if the reward is higher than 10 its custom field value would be equal to its profitability value. If the coin's reward is 10 or less, its custom field value would be 0, meaning it wouldn't be selected to mine. Note: That isn't the exact way you would write it... there are letters used to represent the different values instead of typing out the whole word. You can see a list of available values in the Custom Field tab in the Coin Manager window. To open the Coin Manager window, go to Settings, click "Other Tools..." button at the bottom, and select "Manage Coins".

As for profitability switching, if the coin you're currently mining is equal to the highest profitability (or whichever value you're basing your profitability mining on), it will not restart the miner. So if you're mining most profitable, which lets say is DOGE, and the next time it checks and sees that DOGE's profitability is equal to the most profitable, it will do nothing. If I'm understanding you correctly, you're saying that it restarts the miner using the same profile? Are you sure it's not a different monitoring option restarting the miner? (e.g. restart miner every X hours)


dency45:  I'm not sure why your cgminer is closing unexpectedly. CGWatcher is detecting it and attempting to restart it, but it has no information as to why it happened. I would suggest trying a different version of cgminer. If you're mining with ASICs, perhaps try the latest version. If you're mining with GPUs, maybe try an older version. I personally use 3.5.0. It could possibly be related to a driver crash... but usually cgminer remains open when this happens.


Giggety:  I think this is more of an sgminer issue than a CGWatcher issue. CGWatcher does the same thing every time, which is really a pretty simple thing - it launches the miner process. What happens after that is up to the miner. If CGWatcher never starts sgminer successfully, then it may be a CGWatcher issue and is something I could look at when I get a minute to check out sgminer more.