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

[ammi84]

Which Coin should i set, when i mine multipool.us?
i can't set a shedule action when i don't set all coins to the profiles.

does it matter or not which coin i choose?

i want to switch every 24h hours between HBN and Multipool

thanks

[1715346964]

1715346964

[1715346964]

1715346964

[milone]

A feature request I have is we can give the GPU's a custom name on the devices tab, i run different branded cards & have a bad memory & poor handwriting

I like the idea. I'll put it on the list, but no guarantee on how soon I'll be able to get to it.

Send u an email a couple days milone. Don't know if u received it.

If I don't get back to you within a few days please email me again. I don't know whose brilliant idea it was to maintain two programs at the same time... but at least I never get a chance to be bored any more.

I've noticed already twice in the past two days that CGminer.exe was killed by CGWatcher after which CGminer was restarted but only an empty DOS box appeared.
Then CGWatcher appeared to be stuck as I could only see an empty CGWatcher window.  I closed the DOS box and CGWatcher "unfroze" and Cgminer restarted again and started mining.
I'll make a screenshot next time this happens.
My miner was down for 8 hours because of this.  (This is what I was hoping CGWatcher would prevent from happening.)
I've set the option to always kill cgminer.exe instead of shutdown command.


I'm using 3 XFX R9 290's on an Asus B85-Plus mobo with 8GB and an Intel i3 cpu powered by 1200W Club3D psu.
Windows 7 x64, CGminer3.7.2, CGWatcher1.3.4

If after killing CGminer.exe a pause of like 5 seconds is implemented before CGminer.exe is restarted by CGWatcher, would that maybe solve the problem?

If the miner is just a blank window for more than 60 seconds upon starting, CGWatcher should kill it and try launching again. This number of seconds can be changed by going to the Monitor tab, then the Other sub-tab. The setting is called "Kill miner and try again if mining hasn't started within X seconds". If this didn't work or I am not understanding you correctly, please let me know. You mention you noticed it happened twice... are there other times where it works without incident?

Which Coin should i set, when i mine multipool.us?
i can't set a shedule action when i don't set all coins to the profiles.

does it matter or not which coin i choose?

i want to switch every 24h hours between HBN and Multipool

thanks

You can create scheduled actions to switch to specific profiles, as well as profiles based on profitability. So you can create a scheduled action to switch to the Multipool profile, and then another action to switch to most profitable profile. You can create them 24 hours apart and set them to run at 48 hour increments, or create a scheduled action for each day of the week, alternating the profile for each day.

[ammi84]

yes i know but when i don't specify a coin for the multipool-profile i can't make a shedule with it

when i set for example the multipool to litecoin it works
perhaps you could add multipools to the coinchoose-dropdown?!

[kimocoin]

I've noticed already twice in the past two days that CGminer.exe was killed by CGWatcher after which CGminer was restarted but only an empty DOS box appeared.
Then CGWatcher appeared to be stuck as I could only see an empty CGWatcher window.  I closed the DOS box and CGWatcher "unfroze" and Cgminer restarted again and started mining.
I'll make a screenshot next time this happens.
My miner was down for 8 hours because of this.   (This is what I was hoping CGWatcher would prevent from happening.)
I've set the option to always kill cgminer.exe instead of shutdown command.


I'm using 3 XFX R9 290's on an Asus B85-Plus mobo with 8GB and an Intel i3 cpu powered by 1200W Club3D psu.
Windows 7 x64, CGminer3.7.2, CGWatcher1.3.4

If after killing CGminer.exe a pause of like 5 seconds is implemented before CGminer.exe is restarted by CGWatcher, would that maybe solve the problem?

If the miner is just a blank window for more than 60 seconds upon starting, CGWatcher should kill it and try launching again. This number of seconds can be changed by going to the Monitor tab, then the Other sub-tab. The setting is called "Kill miner and try again if mining hasn't started within X seconds". If this didn't work or I am not understanding you correctly, please let me know. You mention you noticed it happened twice... are there other times where it works without incident?

The setting "Kill miner and try again if mining hasn't started within 60 seconds" is enabled.
I think what could be it in this case, is that the blank window isn't a cgminer.exe process at that moment. Eventhough it says cgminer.exe in the window title.
All the other times I think it works fine I guess.  

I managed to make screenshots this morning.
The CGWatcher log stated: "cgminer closed outside of cgwatcher."

http://tardis1.tinygrab.com/grabs/d81565c15a85db686a8081564355a745789f565365.jpg
http://tardis1.tinygrab.com/grabs/d81565c15a5bc9f4439351984156e78410e103b052.jpg

[ellave]

I've found a simple workaround for the Win 8 & not starting up issue.

Just create a simple bat file "c:\cgwatcher\cgwatcher.exe"  place it in your start up folder (start - run - shell:startup )..works a treat 

[yorich]

Last 3 versions have not worked for me.  I had 1.3.4.3, and it worked great, but 1.3.4.7, 1.3.4,6, and 1.3.4.5 all don't work.  When they launch, everything looks good, but they NEVER start bfgminer.   I get a dos box momentarily that just flashes away, and then CGwatcher says it couldn't start/communicate with bfgminer.  Since 1.3.4.3 is not posted on your site, I had to go back to 1.3.3.3, which works fine.  I tried again going back to any of the above and can repeat the problem.

[milone]

The setting "Kill miner and try again if mining hasn't started within 60 seconds" is enabled.
I think what could be it in this case, is that the blank window isn't a cgminer.exe process at that moment. Eventhough it says cgminer.exe in the window title.
All the other times I think it works fine I guess.  

I managed to make screenshots this morning.
The CGWatcher log stated: "cgminer closed outside of cgwatcher."

http://tardis1.tinygrab.com/grabs/d81565c15a85db686a8081564355a745789f565365.jpg
http://tardis1.tinygrab.com/grabs/d81565c15a5bc9f4439351984156e78410e103b052.jpg

Can you try this test build (http://bit.ly/cgw134test) and see if it improves this issue?

I've found a simple workaround for the Win 8 & not starting up issue.

Just create a simple bat file "c:\cgwatcher\cgwatcher.exe"  place it in your start up folder (start - run - shell:startup )..works a treat 

Thanks, good to know there is a solution. I may have to create a batch file then when creating autorun entries in Windows 8.

Last 3 versions have not worked for me.  I had 1.3.4.3, and it worked great, but 1.3.4.7, 1.3.4,6, and 1.3.4.5 all don't work.  When they launch, everything looks good, but they NEVER start bfgminer.   I get a dos box momentarily that just flashes away, and then CGwatcher says it couldn't start/communicate with bfgminer.  Since 1.3.4.3 is not posted on your site, I had to go back to 1.3.3.3, which works fine.  I tried again going back to any of the above and can repeat the problem.

After this happens (miner flashes then disappears), if you go to Tests tab and click Create Debug Report and email it to me, I can look for a cause. It's impossible to say what is happening without more information. You can also try the latest test build (http://bit.ly/cgw134test) to see if it works any better.

[Pompobit]

Hi,

I noticed when I start cgminer with CGWatcher, my hashrate is lower and HIGHLY more unstable.
Usually it grows to his peaks and then drops for about 80-120 KH/s per gpu, then it grows again and drops again, and so on every few seconds.
Apart from that the overall hashrate is lower, starting cgminer directly I get from my gpus an average of 750 Kh/s per card, starting from CGWatcher my average is about 710 KH/s per card.

After two days changing settings, miner arguments, switching between .bat or .conf files, trying different cgwatcher versions, it comes out that it is the Monitor feature to cause this issue.
Enabling monitoring every 10 seconds for example, when the graph and the stats are updated, the hashrate drops instaneously about 40-50 KH/s (per gpu) and continuing to drop for about 1-2 seconds, then the hashrate recovers until the next monitor update.
I tried to edit the delay of the refresh but this of course only postpones the problem, currently I'm using 30 minutes and although this setting allows the average hashrate to decrease almost imperceptibly, I'm worried that a GPU becomes sick or something goes bad in those 30 minutes...
Obviously disabling the monitor solves this issue but CGWatcher without monitor loses a lot

There are my settings if can be helpful:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
del *.bin
cgminer.exe --scrypt -w 256 -v 1 -I 13 -g 2 --lookup-gap 2 --thread-concurrency 8192 --gpu-memclock 1500,1500,1800,1800 --gpu-engine 1080,1080,1120,1120 --gpu-fan 30-70 --temp-overheat 86 --temp-cutoff 90 --auto-fan


Btw, thank you for this wonderful software

[milone]

If you are getting a lower hashrate with CGWatcher it is most likely due to the gpu-threads setting.

CGMiner's readme stated that the default value of gpu-threads was 2. However, if you ran CGMiner without setting this, it would actually run at 1 gpu-thread.

So to be consistent with the readme, CGWatcher sets the default value to 2. This means to get the same hashrate with CGWatcher as you do without CGWatcher, you may have to set gpu-threads to 1.

I've updated the readme to state this, which will be in the next version. This has been how it works for quite some time, so if I were to change its behavior now it would affect other users who expect it to be 2.

[Pompobit]

If you are getting a lower hashrate with CGWatcher it is most likely due to the gpu-threads setting.

CGMiner's readme stated that the default value of gpu-threads was 2. However, if you ran CGMiner without setting this, it would actually run at 1 gpu-thread.

So to be consistent with the readme, CGWatcher sets the default value to 2. This means to get the same hashrate with CGWatcher as you do without CGWatcher, you may have to set gpu-threads to 1.

I've updated the readme to state this, which will be in the next version. This has been how it works for quite some time, so if I were to change its behavior now it would affect other users who expect it to be 2.

I already read that somewhere but my gpus (280x) run better with 2 gpu-threads, so I always specify it in the .bat or .conf file (as you can see in the settings I wrote here).
By the way, disabling monitoring on CGWatcher I get exactly the same hashrate than starting cgminer directly, so it isn't due to a gpu-thread wrong setting

[milone]

If you think it is due to CGWatcher merely running you can easily test this by launching the miner with CGWatcher closed, wait five or ten minutes for the hashrate to stabilize, then open CGWatcher and see if the hashrate drops. To date, any time someone reports a lower hashrate using CGWatcher it has been due to gpu-threads. Yeah I see it now in your post... I had scanned through it looking for gpu-threads and forgot about -g.

The only reason you'd have a different hashrate with or without CGWatcher then is a config setting. You can see the exact config settings CGWatcher used the last time it launched the miner by going to the Tests tab. In the Debug Reports & Utilities drop-down (middle of the window), select "Show last miner start configuration" and click Run. It will show the original config settings and the used config settings. It shouldn't change any, but it may add some, like enabling the API. If you find anything different that shouldn't be, please let me know.

Also, obviously make sure you're using the latest version as it may have bug fixes or improvements over older versions. The latest is 1.3.4.6, but I also have a test build you could try here: http://bit.ly/cgw134test

[yorich]

Last 3 versions have not worked for me.  I had 1.3.4.3, and it worked great, but 1.3.4.7, 1.3.4,6, and 1.3.4.5 all don't work.  When they launch, everything looks good, but they NEVER start bfgminer.   I get a dos box momentarily that just flashes away, and then CGwatcher says it couldn't start/communicate with bfgminer.  Since 1.3.4.3 is not posted on your site, I had to go back to 1.3.3.3, which works fine.  I tried again going back to any of the above and can repeat the problem.

After this happens (miner flashes then disappears), if you go to Tests tab and click Create Debug Report and email it to me, I can look for a cause. It's impossible to say what is happening without more information. You can also try the latest test build (http://bit.ly/cgw134test) to see if it works any better.
[/quote]

here you go:http://pastebin.com/qVPkpr7v  i dont really care about the passwords=)

FYI, I tried installing a fresh copy of Cgwatcher, 1.3.4.7 (your test copy on your site) and pointed it at one profile, created from scratch, and using bfgminer 3.9.0 x64, same results...bfgminer just flashes on the screen, and i get a message saying it couldn't connect to the bfgminer api.

[kimocoin]

The setting "Kill miner and try again if mining hasn't started within 60 seconds" is enabled.
I think what could be it in this case, is that the blank window isn't a cgminer.exe process at that moment. Eventhough it says cgminer.exe in the window title.
All the other times I think it works fine I guess.  

I managed to make screenshots this morning.
The CGWatcher log stated: "cgminer closed outside of cgwatcher."

http://tardis1.tinygrab.com/grabs/d81565c15a85db686a8081564355a745789f565365.jpg
http://tardis1.tinygrab.com/grabs/d81565c15a5bc9f4439351984156e78410e103b052.jpg

Can you try this test build (http://bit.ly/cgw134test) and see if it improves this issue?

I downloaded CGwatcher 1.3.4.6 yesterday and my problem with the blank window hasn't occurred since.  If it does occur again, I will try your test build.

[yorich]

Milone,

FWIW, I solved my issue, though I don't know why it works with one version and then not later.  I changed my config's kernel line to:

Code:

"kernel-path" : "/usr/local/bin"

, instead of:

Code:

"kernel-path" : "C:\\Program Files\\BFGMiner\\/share/bfgminer"

  and it now works in your latest version.   thanks!

[Gelbstich]

I don't get the point of cgwatcher, for me it seems useless. When I was mining with cgwatcher one of my gpu's overheated and shut down. Cgwatcher noticed it and set the gpu from "dead" to "rest", but didn't make the gpu work again. Manual cgminer restart fixed the issue.
Another time one gpu went down to only 60% performance and cgwatcher did nothing to fix this. A restart solved this issue.

So in which cases exactly does cgwatcher help you? Cause in those mentioned above cgwatcher doesn't fix anything.

[fruor]

I have found several blocks the last days while connected to pools, but they don't show up on the pool.
Pool admins are not very helpful, so I wanted to ask if you could see the block number of the found blocks anywhere?

Didn't find any information in cgwatcher data_output.txt which I set to log the column found blocks as well and they did increase but not show additional info nor in my miner.log which only shows these lines:

[16.01.2014 15:15:05]  CGMiner (4852): Congratulations, you found 1 blocks!

[milone]

milone, is this caused by CGWatcher??

A service was installed in the system.

Service Name:  WinRing0_1_2_0
Service File Name:  C:\TEMP\tmpB1B9.tmp
Service Type:  kernel mode driver
Service Start Type:  demand start
Service Account: 

My EventLog is full of that stuff. I had an unpleasant experience with some malware in recent hours, and thought I had a rootkit in my system, but this seems to populate EventLog once CGWatcher starts mining.

Yes, this is CGWatcher. Specifically it is the library CGWatcher uses to get hardware information. If I remember correctly, I have to open, retrieve hardware info, then close... otherwise it interferes with the miner if I just leave it open.

[kimocoin]

My (CG)miner has been running very smoothly for the past two days with CGwatcher 1.3.4.6 monitoring it's activity. No restarts, or reboots.  
As promised: Time to make a donation!
Mining for you as i'm writing this.

Thank you for this awesome piece of code you compiled Milone!

[milone]

Gelbstich: CGWatcher is designed to ensure mining stays running... not improve mining performance. However, there are many monitoring options that allow you to set thresholds that if not met, will take the action you specify.

If you're using AMD cards, CGWatcher doesn't disable them due to overheat - it leaves this to the miner. The only part where CGWatcher steps in for AMD cards is that when the miner does disable a GPU due to overheating, it is usually unsuccessful when it tries to re-enable it. So CGWatcher will try to detect when this happens and restart the GPU. I'm not sure where "dead" and "rest" come from... when CGWatcher detects that the miner has disabled a GPU it will list it as "disabled". If it is saying "rest" this is new to me so perhaps newer versions of cgminer/bfgminer handle this differently. I cannot immediately keep up with every change cgminer and bfgminer make. For Nvidia cards, the miners do not detect things like temperature, so CGWatcher does this. CGWatcher's overheat protection for these cards is to throttle intensity until they cool, or disable if they exceed temp-cutoff.

As for your GPU's performance dropping, there are monitoring options that would detect this and restart the miner when this occurs. Perhaps the readme would be a good place to start rather than coming to this thread just to post how pointless this software is... which, by the way, is now running on 45000+ computers. Apparently some people find it useful.


fruor: Sorry, this information is not something that is currently available in CGWatcher. You could possibly try to use the time logged to a specific block, but I don't think it will be 100% accurate. It's something I'll add to the to-do list, which at this point needs to be separated into chapters... so I cannot promise how soon I'll be able to get to it.


Octopuss: Yes, there will be a one-time price for the CGRemote desktop application. It will be at or above the current minimum donation required to join the beta. In other words, it will only cost more once it is released. The idea was not to charge for early access, but to give a discount to those who donated before it was finished and am trusting that I will finish it. Anyone participating in the beta will get the released product free for up to 5 miners. There will be a small fee if additional miners or instances are needed. (Instances meaning you need to run multiple instances at the same time from the same account).

CGRemote has received very positive feedback and I feel that the ultimate price will be more than fair considering what it is/will be capable of.

kimocoin: Thanks

[GunPowder]

milone,

I've got an interesting issue

After some time of running , one of my rigs just stops (it's a quit usual event) and CGWatcher doesn't do anything to restart cgminer or reboot PC, although all checks in the "monitor" tab are on.
Also last records in the log say nothing about cgminer was stoped.

What can I do about it?

Thank you