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

Something really strange (and positive) about CGWatcher/cgminer:

I tried with programs like EVGA and MSI Afterburner, to overclock the GPU Core clock to a value higher than the AMD bios limitation of both my HD4650 (550 MHz) & HD7650M (500 MHZ) laptop graphic cars, with no success.

With CGWatcher I can go to higher values than those "imposed" by AMD. It passes the command 'gpuengine|0-600' to cgminer 3.2.1 and it accepts the command. I'm now using both at 600 MHz, with no temperature problems. The hash rate from the HD4650 went from 28 to 31 MHash/s and the HD7640M went from 64 to 77 MHash/s.

How is this possible?

Long story short...haven't read any of the thread. Have been mining for a year now and as many miners know...frustrations are abundant and tend to hurt various parts of your body that are haphazardly thrown at inanimate objects to seemingly ease the pain...go figure. Anywho, so I FINALLY stumbled upon your thread and, while I discovered I should have read at least SOME of the thread in order to make the initial setup process go a little smoother...I can officially say that I went out for the night and to no surprise cgminer disconnected and sat there with its thumb up its ass for hours and hou...wait...nope...10 freakin minutes baby!!!!! 10 minutes of nothing accepted and CGWatcher to the flippin rescue man!!!!! If I ever meet you...I will hug you!

So, once I actually make an extra coin or two whilst trying to pay off all this hardware that melts my brain at night from the heat...oi!...I will HAPPILY be making a donation which at the very least will force me to go back and read some of the thread in order to hunt down a donation address

Yup...just wanted to stop in and say...

THANK YOU!!!!!

Version 1.1.6.0 is available and adds support for 64-bit miners and FPGAs/ASICs. I do not have any FPGA or ASIC devices yet, so the support is based on device test results that users had sent me. Most of these were all one type of device and did not include GPUs, so if you experience issues please run the device test at the bottom of the FPGA or ASIC tab and email me the results.

I rebuilt the OpenCL.NET library so if you are copying files over a previous version, make sure the new OpenCLNET.dll gets copied. CGWatcher will now run as a 32-bit application in 32-bit Windows, and a 64-bit application in 64-bit Windows. I don't have any 32-bit systems to test on, so if you experience problems with 32-bit Windows please let me know.

See the original post or ChangeLog for other changes.


ypsylon: The new version should work with BFGMiner x64.


qiuness: I'm not sure. You can try entering a specific value in the textbox instead of using the slider. The slider calculates a max RPM based on the current RPM and current %, so it fluctuates depending on these two values and may not be accurate. It may be a value higher than the fan allows? I'd try a lower number like 2500, or 2000 and see if those work. The command it sent to the miner to change the fan speed is correct, but the value may need to be lowered.



af_newbie: Maybe... I bet it would still have more users than akbash. Maybe if you spent more time working on your program and less time posting in this thread, people would actually use it. LOL

Hi milone,

I can respect you working on another project, but please think about me and the 10-15 drives to a different location i have to make so reset or configure miners. I sure as hell would like to beta test CGRemote.

I know i would eve consider paying a small fee for it, if that would give me an "empire" overview
Please think about this when factoring in all the variables

EDIT:
i also have this issue... any ideas why the apply new FAN setting does not work?

Greetings, milone.

Many thanks for your kind answer. I understand your priorities. If, in any case, you'll need a beta-tester for your CGRemote when returning to that project, count with me.

Regarding CGWatcher, I tested several times cgminer and bfgminer (32 and 64 bits versions), they work fine, but I get more hash rate in 2 Windows 7 64 bits laptops (with AMD HD4650M and HD7650M) and 1 desktop, also with Win7 (with AMD 7870) when using DiabloMiner, that is included with the 50MINER GUI. As CGWatcher can't interface this miner, I can't use it 

Best regards.

Maybe you need cgwatchercgwatcher to watch the cgwatcher LOL

This was the plan originally, but I realized that in order for CGWatcher to work best, it needed to monitor the miner process as well as the API responses. That is why there is an option to set the IP address, but over time the miner's process became more and more important, meaning it only works with a miner on the local machine that it can match a *miner.exe process to. I left the IP address option in there because someone was using CGWatcher to monitor a remote miner by tricking it with a dummy cgminer process and I didn't want to take that ability away for no reason, but I can't say that this will still work with recent versions. Anyway, the goal of CGWatcher has become to run on the same computer as the miner because this is necessary to really guarantee it can resolve all problems (for instance, killing and restarting a non-responding miner process... or killing a miner that has lost API access). The purpose of CGWatcher is now to ensure the miner is working well enough that you don't have to monitor your miners.

That said, I want to monitor my miners remotely as much as the next guy. The other program I'm working on is called CGRemote and will do what you're looking for. You can list all of your miners by IP/Port, and it will provide a remote dashboard. If a miner is also running CGWatcher (recommended for Windows miners), you'll have complete control over CGWatcher and therefore cgminer. If CGWatcher is not running on the miner, CGRemote will communicate with cgminer directly so you have some control, but if the API drops, cgminer stops responding, etc. you'll have to resolve the problem yourself because CGWatcher won't be there to fix them. Hopefully these issues are less of a problem with non-Windows miners though.

I have the core of CGRemote working, but I've been finishing up some things with CGWatcher (ASIC/FPGA support) and will likely be working on another project for the next two months so I don't have an ETA for release.

Greetings.

Perhaps a little off-topic, but why can't CGWatcher access cgminer running at another "computer" (same VLan) via API port?

I have a Raspberry Pi running Arch Linux and cgminer 3.2.1, mining with 2 x USB ASIC miners and it would be nice to have your great program monitoring the mining work at my Windows laptop, in another room (ok, without start/restart/stop features)? I hate to have to use putty, to have a console opened to that RPI.

ypsylon: Currently CGWatcher does not work with the 64-bit version of BFGMiner because of that limitation. When it refers to "access the module of a 64 bit process", all CGWatcher is attempting to do is get the filename of the process so it can try to match it up with a profile (in case the miner was started outside of CGWatcher.) This is due to trying to continue allowing CGWatcher to work with miners that were started outside of it, but in the future it may just end up ignoring miners that it did not start. This will resolve the 64-bit issue and save a lot of other headaches... but it will take a bit of work to change. For now, whether or not the benefits of a 64-bit miner outweigh the benefits of CGWatcher is up to the user. You may find that the 32-bit miner performs just as well. Out of curiosity, is there a specific reason for using the 64-bit miner? Have you seen any performance gains or other differences?


qiuness: Yes, CGWatcher will work on both 32-bit and 64-bit Windows, but ypsylon was referring to using it with 64-bit BFGMiner as opposed to 32-bit BFGMiner or (32-bit) CGMiner.


Boxman90: Hopefully. Someone has offered to port to OSX, so maybe someone will do the same for Linux. Although I haven't released the source yet (there is a reason for this), I do plan on putting it on GitHub as soon as possible.

Will there be linux support in the future?

i've got 64bit and it works fine

Is CGWatcher 32b only? I can't save any configuration profile with 64b version of BFG, but it works with 32b CGMiner. Always get Net Framework "alarms" that 32b process can't write 64b one. Tested on various machines with totally different setups but same Win7 64b OS.

http://s11.postimg.org/ev56r6fs3/CGWatcher_Monitoring_2013_06_10_22_38_09.png

great little tool... just what you need in a modern mining farm...
I'd be willing to donate a few ltc for the CGRemote (to be able to centrally watch over my farm and configure it)

I really hope you get the code out soon

My new 7950 started to get sick with summer coming on. I need to rebuild the way my rig disperses heat. In the meantime, I'm glad I remembered seeing this program. It will be very helpful.

First of all, my compliments on this great tool. I really love it.

Is there a possibility to set the location where the logfile is written to?
I would like to write it to my Google Drive so I can always check if there are any errors.

If not, can you implement it in future releases ?

Keep up the good work

Kiplingscat: There was a bug in the Config File Editor that caused auto-gpu and auto-fan to default to True. If you set them to False and then saved the config file, it would save correctly. But the next time you opened the config file in Config File Editor, they would default back to True. This may explain the problem you had.

It has been fixed and the download file updated so please download again if you have not already done so.

mAn you are amazing Milone.  

within cgwatcher, settings, you have the config file editor and within that I had a drop down to turn gpu-auto to false and that of course fixed it.

I had zipped cgminer and cgwatcher together on my google drive to populate all machines and I thought I had said config that way before saving the files, but apparently not.

that, in app, editor is awesome.

Thanks again!

Hi Milone,

What an unbelievable tool you have given us.

I have an issue I am running into and I am curious as to your thoughts.  I have three GPUs running and when using CGwatch, the 1st gpu will run fine for approx. a minute and then will throttle back into the kh/s range.

Any thoughts on what is causing and how to correct?

Oooo. It was a misunderstanding about previews post. I thought .bat is a workaround. OK good to know...

poohbah: I will edit the setting's text to make this clearer. My thinking was that should there be a problem that was undetected by other checks, a restart at the schedule start time would hopefully resolve it and ensure that the scheduled mining ran properly. Ultimately I'd like to preserve a history of statistics, but there are other things to do first.


digitalindustry: Thanks


Lucko: I did find a problem with .bat or .cmd files that used the 2>log.txt or similar argument. It has been fixed in 1.1.5 and should be available tomorrow. (I said that about last weekend but I got sick so it was delayed.)

You'll still need to use a .bat or .cmd file when using the 2> argument because the .NET process class has a problem with it that I haven't tracked down yet.

It doesn't matter if you don't use a config file if you're using arguments. Arguments inside a .bat or .cmd file will be shown in the CGWatcher Profile Manager window (in the Arguments textbox) so you can easily edit them, and upon saving it will update the .bat or .cmd file with any changes you made. So whether you point to a .exe, .bat, or .cmd file for your miner, you can manage the arguments for it in the Profile Manager window.