sydameton: Thanks, that is a great idea and something I should have thought of. I will make sure this is added to the to-do list. Even though this, and possibly 'Restart if accepted share count stops increasing for X minutes', would be the only two options that you may want to change for each profile, I'll probably make all monitor options per-profile.

Though then the issue comes up of changing profiles without restarting the miner... the options shown in the Monitor tab wouldn't reflect the profile options the miner is still using. Maybe this is a rare occurrence, but I didn't feel I should force the user to restart when they switch profiles so it could very well happen often. There seems to be a large portion of CGWatcher users who are beginners so making things like this clear is important. I may just have to show the current monitor options in the Report tab, and make sure the user knows that the options in the Monitor tab do not reflect what the monitor will actually do until the miner is restarted and is using the active profile.

Or maybe I should just force a restart when the user changes the active profile.

jruben4: Please try version 1.1.4 and let me know if you still have problems. If you do, send me as much info as you can and all of the text from the Report tab, as well as any relevant log entries (include debug log entries by checking the checkbox at the bottom to display them). The last 10 log entries are included at the bottom of the Report tab text, and that may be enough. Either post the information here or email it to the address in the ReadMe.

Version 1.1.4 is now available. It includes mining profiles, monitor improvements, and a config file editor.

If you downloaded already and received an error on startup, download again to get the fixed files. This bug was affecting users with one monitor so I did not catch it before release, but it has been fixed.


gveltre: I do not have a 64-bit version but I will work on modifying the code that is trying to access modules of the 64-bit BFGMiner.

kislam: Thanks for the feedback. I've updated the ReadMe to try to make this clearer. I see what you mean about the confusion with the open directory button. Originally all profile information was only available in the Mining Profiles window, but I then went back and wanted to at least display it on the Settings tab. But I made them read-only to try to direct users to manage profile settings all in one place. I provided the buttons to make it quicker to do things like edit the profile's config file or bat/cmd file, not the profile itself. To do that, you have to use the 'Manage Profiles...' button which takes you to the Mining Profiles window.

Whichever profile you set to active in the Settings tab is the one that will be used. The only time it won't be used immediately is if the miner is running from the previous profile and you have chosen not to restart it when CGWatcher asked you. So the only time you have to worry about the current mining profile is if you switched profiles while the miner was running and didn't restart the miner. Otherwise, the current mining profile and the active profile will always be the same. The active profile is the one you select and is saved when you click 'Save Settings'. This profile is used when CGWatcher starts, or when it starts or restarts the miner.

The Default profile is just a name given to the first profile it creates automatically for users that do not have any profiles yet. You can change the name of it. You can then name another profile Default if you wanted to. I just had to name it something.

sydameton: Sorry about the new bug. While I was testing and fixing the PositionForm subroutine that starts CGWatcher in the same position that it was last closed, I added a line to print some debug info and forgot to disable it before compiling. It was only affecting users with one monitor, which is why I didn't catch it. I have fixed this and updated the download link.

1.1.4 is available. It should fix most bugs, and if it doesn't it will at least introduce some new ones to keep the old ones from feeling lonely. If you find it doesn't fix your problem or creates a new one, please let me know.

Thanks.

btc6000: Since I don't have any ASICs yet, I don't know exactly what type of information I will be able to get from the miner for them. In version 1.1.4, you'll see that I am getting there and on the Tests tab there are three device tests: CPU, FPGA, and ASIC. I am hoping users who use these devices to mine can click the appropriate button to run the test, which will send commands to the miner requesting information about those devices. The results will be displayed in the textbox, which can then be emailed to me so I can see what information is available. Because of the variety of FPGAs and ASICs, the more users that can submit these test results the better. The CPU test is something I could run myself (although I don't CPU mine), but I figured if I made it a test and asked users to submit the results, it would help me gauge whether it is even worth it to write in CPU support.


AlphaColt: Your fan speed drops because CGWatcher shuts down the miner correctly when you press the Pause Mining or Stop buttons. (There is no pause in cgminer, CGWatcher just calls it Pause because it works different than the Stop button in that scheduled mining will resume if the Pause Mining/Start Mining button is used. This means if you have set the miner to manage your GPU clock speeds and fans, it is running them at higher than normal while mining. When you shutdown the miner properly ("quit", not click the X in the corner), the miner returns the clock speeds and fan to their normal values. This is why you're hearing your fan spin down... it is by design because the temperatures immediately drop when mining stops. When you press Start Mining, the miner is re-launched, causing it to again take control of the clock speeds and fan. You will hear the fan spin back up as the temperatures heat back up.

I was aware of the annoyance that was changing GPU settings, but I had other priorities so I figured an interim solution would be to increase the monitor interval so you had enough time to change settings between refreshes. This is fixed in 1.1.4, where the textbox that has focus will not be updated, and no values will be updated while the confirmation message box is displayed either. This should be enough for changing one GPU setting at a time, but if you want to change several at once there is now a "Freeze" button that will prevent updates to any of the settings that can be edited while the button is depressed (it's works similar to a checkbox, but looks like a button.) Once you have made your changes, you can click the button to "Un-freeze" the settings so they will be updated on refreshes again. While editable fields are frozen, they will change to blue text to make it clearer that they are frozen so if you're expecting them to update, you'll need to click the "Un-freeze" button. (note: even if the editable fields are frozen, the non-editable fields like activity, temperature, etc. will still update on monitor refreshes.) I may have made it sound complicated here but once you use it once you'll see how simple it is.

I've spent the whole week working on and testing 1.1.4. I think it is ready, but I have to rewrite the ReadMe for it because so much has changed and there are several new features. I plan on doing that and uploading it tomorrow (Sunday). Most of the monitoring has been re-written and I think the new features will be helpful.

The auto-configuring of the miner based on hardware gets a little complicated with the variety of hardware available, but this is something I've been working towards. I prefer config files to command-line arguments so this required an easy way to edit config files, which you'll see is starting to take shape in 1.1.4. Ultimately there would be a config "wizard" that would walk beginners through setting up their miner, but I haven't gotten there yet. The Config File Editor in 1.1.4 is a start, but still requires a little miner knowledge on the user's part.

My guess is that you don't have full API access, or if it doesn't display hashrates... no API access. Make sure that either this is in the miner arguments:


or that these two lines are in the config file:


(you may need to put a comma at the end of the second line depending on where in the config file you place it.)

I didn't intend for it to notify the user and log this continuously, just an oversight on my part because I got used to always having full API access enabled. If someone chooses to give read-only access (for some reason?) then it should provide info without nagging them, it will just be limited on making changes to the miner (GPU, Pool, etc), although even with read-only access it will still be able to start, stop, and restart the miner. This is fixed in 1.1.4, which should be available this weekend.

Thanks for the feedback. A few things that have been changed in 1.1.4 that are related to each of your issues:

- Instead of watching for total share counts to stop increasing, it now only watches accepted share counts. Those are the only shares that matter so if those stop increasing, a restart is probably a good idea. Users will need to modify this setting as necessary (increase the number of minutes), because accepted share counts may not increase as often as all share counts combined were increasing. The Utility value on the Status tab (as well as the Report tab) shows accepted shares/min so this should help you determine a good estimate for how often accepted share count increases.

- Someone else has reported that the miner sometimes fails to close completely, or hangs. I had never seen this but am learning more about the quirks of the miners every day. I've corrected this to watch the miner after sending the quit command, and if necessary killing the process. When killing the process, it will attempt to kill it every second for up to 10 seconds before giving up. Hopefully this is enough to remedy this situation.

- If you can provide more information on the HW errors, I will see if there is anything I can do to fix this. Right now there is not much to reporting this, it is a number that comes straight from the miner and is shown in CGWatcher without modification.

The idea you mentioned would definitely indicate a problem, but I believe when temperatures drop suddenly and significantly, the miner will soon report the GPUs as sick or dead. This usually takes 5 - 10 seconds or so. If you see this happen and the GPUs do not become sick or dead (causing a restart by CGWatcher), please let me know. Also, the accepted share count not increasing check should catch this as well, as this number should stop increasing if the miner is not working correctly.

I've re-written most of the monitoring code and have made a lot of improvements and fixes, with a lot of testing. 1.1.4 will also introduce profiles and some other new features. It has a new option to ensure the miner stays running, meaning if CGWatcher is open with this turned on... it will start the miner if it is not running. I had to make this an option because it is impossible to determine if the miner was closed outside of CGWatcher by the user, or if the miner closed because of a problem. If the user happened to close the miner by clicking the X for example, I didn't want CGWatcher immediately re-launching it when the user didn't want it to. Trying to anticipate what the user is going to do and why is the challenging part of this project, because there is a very wide range of experience levels and I think that software should adapt to the how the user works instead of the user adapting to how the software works... as much as possible anyway.

I am hoping to have 1.1.4 ready by this weekend.

hodgson: Thanks, I really appreciate it. I hope you will like the 1.1.4 update even more. It will be available this week.

kislam: Profiles are something I had already been working on because I've started mining different coins and I want to do as little work as possible to switch between them. That is what I love about writing software - the more time you put into developing it, the lazier you can be when using it.

As far as most profitable mining, this switches so often that you are probably better with picking one and sticking with it for a week. But I have noted this on my to-do list so when CGRemote and some of the other features get finished I will look more into it.

For now, http://dustcoin.com/mining is a great way to tell what the most profitable coin to mine is at the moment.

DrGoose: Thanks, very much appreciated. I have spent a lot of time over the past week working on it and the next update is a big one. GitHub is a top priority and I've been rewriting a lot of code so it is easier to follow and edit. Classes... everywhere.

Everyone else, thanks... the positive feedback is motivating. A few new surprises and a lot of improvements in version 1.1.4, hoping to have it finished by the weekend.

Three solutions:

1. I've just updated CGWatcher to allow you to select a .bat or .cmd file instead of the miner's .exe file. You can download using the same download link to get the updated files.

2. If you were to select the miner's .exe file in CGWatcher, you don't need a config file but you would need to copy the arguments from your .bat file to the Arguments textbox in CGWatcher so it to launch the miner with your settings.

Note: Some users have reported that the '2>logfile.txt' argument (or similar) will cause the miner to not work when launched from CGWatcher. I'm not sure why this is yet, but I think the method I am using to launch the miner may have a problem with the > symbol. I will look into it but for now the workaround is to use a .bat or .cmd file to specify arguments.

3. If you do use a config file, you can set the miner to scrypt mining by adding this line:
   

joshki: I will definitely be in touch and will be putting the source on GitHub soon. I may message you beforehand to work out any potential changes that may be needed, and would ultimately like to put the OSX source on GitHub as well.

gateway: CGRemote will provide monitoring remote miners. It will allow you to monitor miners regardless of whether or not CGWatcher is running on them.

The two applications have different purposes. You can think of CGWatcher as a babysitter for the miner. It runs on the same computer as the miner and watches for problems. If it detects problems, it attempts to resolve the problem to avoid downtime. CGRemote, on the other hand, will be more of a dashboard for all of your miners.

If CGWatcher is running on the mining computer (which is preferable and will give you far more control), CGRemote will communicate with CGWatcher (which in turn communicates with the miner.) If CGWatcher is not running on the mining computer (non-Windows miners), CGRemote will communicate with the miner directly. Both will allow you to change the miner if CGRemote has full API access, but on miners without CGWatcher these changes will not be saved because CGMiner/BFGMiner does not save changes sent to it via the API.

News/updates on CGRemote's progress will be posted on the CGWatcher page until it is released.

Cryptocables: Both applications will be open-source and on GitHub to allow others to contribute and so users with .NET experience can customize the software to their needs. I am new to GitHub so am learning how it works, otherwise I may have started out there. I've already created the repositories and they will be located at:

CGWatcher on GitHub: https://github.com/justinmilone/CGWatcher
CGRemote on GitHub: https://github.com/justinmilone/CGRemote

I have been rewriting/optimizing/fixing a lot of code now that I've had more time in preparation of this. For now, you can continue to download CGWatcher's newest versions at http://manotechnology.blogspot.com/p/cgwatcher.html. I don't update version numbers for small fixes (although this may change in the future) to allow for quick changes for users who are having a specific problem, without nagging all of the other users that an update is available. An optional auto-update feature is on the to-do list so you will always have the latest files without having to worry about checking and downloading manually.

ColonelPooteh: Thanks

If running as a service isn't a requirement and you just want it minimized to the system tray, you can use CGWatcher to launch the miner in a hidden process, and then minimize CGWatcher to the system tray (set this in the Settings tab.) GUIMiner does this as well. Both applications provide a GUI to CGMiner and launch it as a hidden process. Then you can minimize these GUI applications to the system tray.

CGWatcher: http://manotechnology.blogspot.com/p/cgwatcher.html
GUIMiner: http://guiminer.org/

Wow, you clearly haven't put any time into this if you can just reduce the cost of your asic by $15,000/50% 20 minutes after someone points out how ridiculous the price is. I thought you had already designed the machines and cases?


That would imply you've done some sort of cost analysis or at least opened Calculator. That one brain cell I had telling me maybe I'm wrong about this just killed itself out of embarrassment.


If you want to build asics, build asics. You'll have no problem selling them. But when you start selling shares and giving specs and saying how you can build them "better, cheaper, and faster than the other asics"... it reads scam. Build something, at least a prototype, and then come here and see what the demand is for it. If we have learned anything it is that building asics from scratch might be just a little bit harder than many realize.

By the way, what is "reduced risk which are greatly reduced over other ASIC's"? What risks are you referring to?

If these things have not actually been made yet, why 100nm, 45nm, and 28nm processes? Wouldn't you pick one during the design process? You're supposedly designing asics using all three according to your website, so you're designing the first gen at the same time as the second gen and third gen? Or you're designing three separate chips because you have more money and engineers than you know what to do with? A sort of competition between engineering teams to help motivate them, is that it?

Also, under Services, nothing happens when you click on Proven Designs In Our Fash-Hash Series, which I think is appropriate. Nothing happens when you click on any of your services, which may be the most honest thing about this whole scheme. Your domain was first registered in March 2013, but your website claims


A little long to get a website up for a software company.

All in all I'd say everything looks on the up-and-up and I cannot wait to hand over all my money to you as soon as I get it from the Nigerian prince! I wouldn't be critical since you're not taking pre-orders on your website for these imaginary miners yet, but you are currently attempting to sell 25 million shares on bitfunder for a service that doesn't exist without anything whatsoever backing it up and information that really doesn't make sense, which steamboat has pointed out. You're either running a scam or incredibly incompetent.

For anyone seriously thinking this is legitimate, read the "AMC Press Releases" on bitfunder: https://bitfunder.com/asset/AMC. If I am proven wrong I will gladly retract all of my comments.

If I may offer a personal opinion, I think the website needs more stock images of people in offices that have absolutely nothing to do with mining.

Also, Can2It.com, the other company you're "CEO" of, is down. You may want to look into that.

Edit:
From another thread: https://bitcointalk.org/index.php?topic=158806.msg1979111#msg1979111


So you're buying Avalon chips? Why not mention that here? I thought Avalon was 110nm, so now we're on our fourth different process. Then you're designing your own 45nm chips? What about the 28nm chips you have on your website? If you have designed the machines, where are the pictures? Where are pictures of the rack-mountable cases you already designed? Why is your website filled with photos of people in offices and not pictures of those? If you just put the website together I would think you would have put some effort into it before gauging the market for your $30,000 products. Every detail is going to be scrutinized when you're trying to sell something that costs that much money.

grottenolm: Thanks, it is greatly appreciated. Even small donations can provide a boost to motivation. This is my first experience with writing free software - and soon to be my first open-source project - and the number of requests vs. donations can be discouraging. My goal wasn't to make money from it, but it is impossible to keep it a priority and add the features that everyone is asking for when I still have to take projects to make a living. This experience has definitely caused me to give even more to developers of free software I use.

The information on the Status tab is what I check most often, particularly hashrate, temperatures, and accepted/rejected/etc. share totals. I want to display that info as least intrusively as possible so may end up creating a small window or overlay you can switch to that sits in the corner or stays on top of other windows. I'll also work on increasing the chart height in the Status tab to display more GPU temps without making the text too small.

I'm making good progress on CGRemote, and it will allow remote monitoring of miners with or without CGWatcher. Having CGWatcher on the mining computer is preferable and will still focus on keeping the miner working properly, but won't be necessary. If the mining computer doesn't have CGWatcher running, CGRemote will communicate with the miner directly. However, in these cases if CGRemote loses API access or unexpectedly closes after you send it a restart command, you would have to relaunch the miner yourself because CGWatcher won't be there to do it.


af_newbie: I'd say congrats to you, but your comment seems to already do that. I hadn't heard of it. If I had, I may not have went through the trouble of creating one. The now ~100 downloads/day I am getting indicates that at least a small group of miners haven't heard of it either, or that there is enough room for both. I don't think the fact that you created something similar means it should be the only one, and with over a year of development (vs. a month for me) I'm sure it does things mine doesn't - including some things on my to-do list. I'm in the process of open-sourcing as well so others can contribute or customize it to their needs. When I no longer mine or have users, then I'll stop development.  

As to "been there, done that", I never claimed I had invented the wheel or created something never done before. It was something I wrote for myself and decided to share with others.

Yes, discarded and stale are two different things.

From the CGMiner 2.9 ReadMe...

SS is stale shares discarded (detected and not submitted so don't count as rejects)

DW is discarded work items (work from block no longer valid to work on)

DW is no longer displayed in newer versions of CGMiner and therefore is not mentioned in the latest ReadMe.

I've seen an increased discarded rate on my miners and believe it is either a result of using the stratum protocol or using a pool that does merged mining. I haven't been able to find much information on it, but I want to say that I read somewhere stratum may result in more discarded work but reduces rejected or stale shares so ultimately it is better. Hopefully someone more knowledgeable can correct me if I'm wrong or provide more information. My discarded rate is usually around 20% with BitMinter, but rejected and stale are always 0 or at worst < 1%.

I will put the codes used in CGMiner into the info boxes (tooltips) that appear when you put your mouse over a value in CGWatcher, though as I mentioned some may no longer be displayed in new versions of CGMiner.

Admittedly I have quite a bit to learn about how mining software works so there may be a better monitoring option than checking to see if accepted, rejected, stale, or discarded don't increase over x minutes (all four have to not increase to trigger the restart.) My thinking was a problem with the pool would cause these numbers to not change, and I've remoted into my own miners and have seen them stuck because the pool went down/had issues and CGMiner did not switch to the backup pool correctly. So as I find problems with my own miners, I try to add options to catch them. As I learn of better ways to check for problems, these options may change in future versions.

If you're still looking for answers, I may be able to provide a little help. I'm not an expert yet so hopefully someone will correct me if I am wrong on anything here.

Because of the inefficiency of mining with Nvidia GPUs, they do not get the same level of attention from miner developers as AMD GPUs do. The reason that the miner is not displaying Nvidia GPU temps is most likely because it wasn't worth the extra development time to add such a feature since the vast majority of miners use AMD.

CGMiner has three temperatures you can set. Obviously, these settings only apply if CGMiner is able to get the GPU temperature, which currently only seems available to AMD cards. For these settings to work, you have to set auto-fan and auto-gpu to true.

• temp-target: This is the temperature CGMiner will try to maintain by increasing or decreasing fan speed. According to the ReadMe, it may also change clock speeds but I am not sure of that. To specify at what temp you want the miner to down-clock, use the next setting as I am sure it down-clocks the GPU when/if it is reached.
• temp-overheat: When temperatures reach this value, CGMiner will down-clock the GPU in an attempt to return to the temp-target value. I am guessing it will later return to normal/specified clock speeds once the temperature is back to the temp-target.
• temp-cutoff: If a GPU temperature reaches this value, CGMiner will disable it. I am not sure if it automatically re-enables it once it cools down.

Temp-hysteresis, according to the ReadMe, is how much the temperature can fluctuate outside of the limits you've set when CGMiner is managing GPU speeds/temps. The default value is 3 degrees.

I've written an interface/monitor for CGMiner/BFGMiner and am currently looking into finding the GPU temps for Nvidia and Intel. It would be ideal to have these values in the miner itself, but my goal is to get them on my own (and send commands to the miner to increase/decrease fan and clock speeds) until that happens, if it happens. That is how I came across your post.

The program I've written is called CGWatcher (http://manotechnology.blogspot.com/p/cgwatcher.html). It provides a friendlier interface as well as options for monitoring (and restarting) the miner to ensure it is working properly. Right now it only gets GPU temps from the miner, so it will also not display temps for Nvidia (or Intel I believe) GPUs, but I am hoping to add that functionality so it is not dependent on the miner for this info.

Until then, I would suggest you keep running a program that is capable of getting the GPU temps for all cards any time you mine with Nvidia or Intel GPUs. I recommend AIDA64 Extreme Edition, which has an OSD feature that overlays information like this (you can customize what it displays) on the screen so it is always visible.

1@17.5

You'd have to be running CGMiner with no pools or with no GPUs to get this error. Up until now I assumed at least one of each for anyone who used the program. It does not yet support FPGA or ASIC. I have fixed this error so it will at least expect you don't have any GPU or pool, although you may not see hashrates or other data. You can download the update using the same download link, I did not change version numbers.

The update also includes GPU temps on the Status tab and displays them in the same graph as the hashrate, since that is something I had already added. Anyone who wants this feature now can re-download using the same link as well.

joshki, thanks I will keep that in mind. I do plan on releasing the source and have been rewriting a lot of it now that I've had more time to work on it. The first version was written very quickly and don't want to subject anyone to that. 

Also, I've created a post in the Mining forum and would prefer any future comments to go there: https://bitcointalk.org/index.php?topic=185553.0. I will check here occasionally in case anyone in Newbie prison has a question/comment.