Not that I'm aware of. For cgminer, you use Zadig to install WinUSB drivers. Once you use Zadig to install the WinUSB driver for one Block Erupter, it should automatically install it for any other Block Erupters. That's how it worked for me. Same with BFL Singles... I installed WinUSB for one and it automatically installed it for the other.

For bfgminer, you install the USB to UART Bridge.

Each miner has its own way of handling USB communication. If you switch miners, make sure to uninstall whichever method you used for the other miner.

I'm not sure what you mean by CGWatcher giving errors when trying to download the miners... it doesn't download miners. You just tell it where the miner is located when you create a mining profile.

As far as config files, cgminer will automatically use any config file named cgminer.conf if it's in the same directory as cgminer.exe (and cgminer-nogpu.exe). You can also use --config <filename> to specify a config file in another location. If the filename has a space in it, remember to put quotes around it.

Example:


Among other things, CGWatcher makes it easier to setup the miner - you can create as many profiles as you need, for each profile you set the miner executable (or batch file), config file (optional), command arguments (optional), and a few additional options. You can also set which coin the profile is mining so you can then later schedule it to mine certain coins at certain times, or mine based on profitability.

I ended up using two instances of cgminer: one for a Jalapeno and a few USB Block Erupters, and one for two Singles. I used the first --usb option (in cgminer readme) to specify which devices I wanted in which instance.

Open a command window pointing to your cgminer folder, and type in


(you can also use cgminer-nogpu.exe -n if you aren't using any GPUs)

This will list all devices it found, along with some other information including each device's bus number and device address. You then set the --usb option in the arguments or config file, entering the bus number:device address of the devices you want it to use (comma-delimited).

So the first cgminer instance uses a config file, in it is the line:


The second instance uses a config file, in it is the line:


Note: the device address may not necessarily be sequential. I haven't checked yet, but the advantage to this method is I think/hope it should persist through computer restarts, although I haven't tested this yet. I didn't want to use COM ports to specify devices for this reason.

You would need to run a separate instance of cgminer/bfgminer for each pool. For each instance, you'd specify which devices you want to use.

You can also run multiple instances of CGWatcher - one for each miner instance. You just have to create separate folders for each CGWatcher instance (e.g. CGWatcherA, CGWatcherB, etc) because each instance needs its own folder to store settings in. If you ran multiple instances from the same folder, they would overwrite each other's settings.

For cgminer you can use --usb to only enable certain devices. From the readme:


I'm not sure if the same option is available in bfgminer. You can find info on how to enable devices by specifying the COM port (but these can change after the computer restarts) here: https://bitcointalk.org/index.php?topic=268626.0

If you need any help getting CGWatcher setup let me know. I have cgminer and bfgminer running on my desktop, each with its own CGWatcher. I just created shortcuts to each CGWatcher on the desktop - one called "CGWatcher GPU" and the other "CGWatcher ASIC". They both use the same file for profiles, so if I want to add/edit/delete a profile I only have to do it once.

I also have a laptop running more ASICs, and today I'm going to be moving them all to the basement to run on the same computer. I'm going to split them up into two groups so I can mine two different pools, so I'll let you know what solution I come up with.

As mentioned above, you could also have all the ASICs mine the same pool then just switch pools at scheduled times, which should produce similar results. Newer versions of the miners have options for this, or you can create scheduled actions in CGWatcher to do it at set intervals or times.

Awesome, thanks for posting that. I'll have to find somewhere on CGWatcher's download page to post it. 

What mining program are you using?

cgminer now shows accepted shares as diff1 share equivalent, so if you mined 1 share with diff 64, cgminer will report A: 64. The pool will only report 1 share.

bfgminer still shows the actual pool share count (at least as of 3.2.1) so it would report A: 1 matching the pool.

This also applies to rejected and stale shares I believe, but hardware errors are always equivalent to a diff1 share.

If you use CGWatcher there is a setting in the Settings tab called "Share count totals" to select which way you want share counts displayed.

I don't see any indication that CGWatcher had stopped the miner. It also appears that it never received any information from the miner saying the device was sick or dead. Is this something you saw in the miner's window? Instead, my guess would be that the miner process crashed and closed because any time CGWatcher attempts to start/stop/restart the miner it creates several log entries.

By default, CGWatcher does not restart the miner if it is closed outside of CGWatcher because it doesn't know whether the miner crashed or whether you closed it (using Q or clicking the X to close the miner window). I didn't want CGWatcher to be relaunching processes that the user wanted to remain closed, so I made this an option (disabled by default). The option can be enabled in the Monitor tab: "Ensure miner stays running unless paused or stopped in CGWatcher". Enabling this means CGWatcher will always relaunch a closed miner unless CGWatcher closes it (user clicks the Pause Mining or Stop button, or a scheduled stop).

I can't say with 100% certainty this is what is happening, but if CGWatcher had received a response indicating the device was sick or dead... or if CGWatcher had stopped or attempted to restart the miner... there would be several log entries reporting this. If you have any more information that indicates otherwise, let me know. I did add some additional logging so if this happens in future versions it will be clearer to see... including an entry created if the miner closes outside of CGWatcher. Early on there are times during testing where I would accidentally close the miner by clicking X to close its window instead of stopping it in CGWatcher... so CGWatcher has never treated this as something critical. But if you enable the "Ensure miner stays running..." option it should.

I did find a bug that would cause scheduled actions triggered by a sick or dead device to not fire, but that isn't what is happening here... the "Restart miner when sick or dead devices are detected" monitor option was unaffected. I'll be releasing a minor update later today or tomorrow that fixes this and has the additional logging, along with a few remote-related changes and improvements.

Let me know if you have any additional information or questions, or if the problem continues even after enabling the "Ensure miner stays running..." option.

Thanks,
Justin

When this happens, can you go to the Tests tab in CGWatcher and click "Create Debug Report"... then email me the results? (email is in readme.txt) The debug log is particularly what I'm interested in seeing to see if it explains what is happening, and the debug report includes the last 25 or so log entries. If you can attach cgwatcher.log to the email that will be even more helpful since it will have all log entries.

Thanks,
Justin

I'm still awaiting more info from KNC owners as they get their machines to get information regarding the best way to manage them with CGWatcher. CGRemote will work with anything running cgminer or bfgminer (I believe KNC uses cgminer). CGWatcher, as it is written now, is very dependent on the miner process to be running on the same computer as this gives it the most control over monitoring and resolving problems. While bfgminer may be able to act as a proxy for self-contained mining devices allowing CGWatcher to work, CGWatcher would be monitoring that bfgminer process and not the mining process running on the miner, which is not ideal. CGRemote will ultimately provide almost all of the functionality of CGWatcher, but can do it for multiple miners on any OS and in any location, all in one program.

If you're interested in trying CGWatcher with a KNC miner, you would setup bfgminer and CGWatcher on the same computer similar to that of a Block Erupter Blade (assuming they work in the same manner). See bfgminer's README.ASIC.txt (more info online, including this thread). You're basically pointing the mining device at the computer bfgminer (and CGWatcher) is running on. Set bfgminer's http-port to the same port the mining device is set to. The linked thread mentions it is only available for Win32 and Linux, so I would try it with the 32-bit version of bfgminer, not the 64-bit. Please report any problems/results so I can get them fixed. Once running, CGWatcher would then be watching the bfgminer process which would be displaying the device and stats it gets via http. I'm curious as to how API commands work when sent to bfgminer in this case, particularly privileged commands. Make sure to start bfgminer with the mining device's IP address in the api-allow W: group.

I'll also be making changes to CGWatcher and CGRemote that will allow changing profiles without restarting the miner. This feature has been requested even before ASICs as some people prefer to restart the miner as least often as possible. It will work any time the profile is switched to another profile using the same algorithm (sha256->sha256 or scrypt->scrypt). If any problems occur during the switch, it will restart the miner as a failsafe (what it currently does when switching profiles). Aside from changing pools, it will change any other config settings that can be set via API. If too many config settings are changed that cannot be set via API, then the miner can be restarted instead.

Right now I'm back to working on CGRemote's next update, so if anything is needed to add support or functionality in these miners I'll be adding it as quickly as possible. Any information or feedback regarding KNC miners is appreciated.

You're probably looking for Intensity (-I) which is a value of -10 to 14 (or 0 to 20 for scrypt) that sets the aggression level for mining. You can also set the intensity to D which will set aggression dynamically to ensure you can still use the computer while mining (without lag). The lower the intensity, the lower the hashrate and temps (and therefore fan speed). (I would not suggest using -I D for scrypt mining, your hashrate will drop down to very very low numbers).

If you're using Windows, you can also use CGWatcher to lower or raise intensity at certain times, intervals,  when the computer is idle, etc.

crazyearner:

Did you get this working? If not, are you using cgminer or bfgminer, and which version? Each has its own method for detecting and using them.


Makitaki:

I'm hoping that always including gpu-threads in config files doesn't cause any unexpected behavior for anyone who had been mining with one gpu thread and didn't realize it. But the readme says the default is 2, so I think ensuring it uses 2 is the correct way to handle it, and if anyone wants to go back to 1 they just need to change the setting to 1.

If you set CGWatcher to launch the miner when it starts, you can change the delay by changing the AutoLaunchDelay setting in CGWatcher.exe.ini. The value is the number of seconds to delay on auto-launch, and the default is 10. If this auto-launch setting is enabled (it's in the Settings tab), it overrides the 'Ensure miner stays running' option at startup.

So when CGWatcher starts, it first looks to see if it is set to auto-launch the miner (Settings tab option). If it is, it will use the AutoLaunchDelay seconds and temporarily disable the 'Ensure miner stays running' option until after the miner is auto-launched. Once this initial miner launch occurs, then the 'Ensure miner stays running' option is re-enabled. If the auto-launch option is disabled, the 'Ensure miner stays running' option currently kicks in immediately after starting, as you're pointing out.

That said, I'll also put on the to-do list to add a similar delay setting to the 'Ensure miner stays running' option, but using the above should provide what you're looking for also. I'll also find somewhere in the UI for the auto-delay setting so you don't have to edit the INI file.

As for the number formats, that is odd regardless of culture settings. I don't have the code in front of me right now and I don't remember exactly the method I used to format these values, but when I get back home I'll look into this and get it corrected.

Thanks again for the feedback.

Thanks, looking into this now. If you can start the miner with CGWatcher (to reproduce the problem) then go to the Tests tab in CGWatcher and click the 'Miner Start' button, it will display info about the config/arguments used to launch the miner. If you can email this to me (address at top of readme) it should make it much quicker to find the problem.


Edit: This is fixed, and version 1.3.2.2 is available. The problem was CGWatcher leaving this option out since it was set to its default value (2) which means the miner should have used 2... but I also saw that if left out it only used 1. Changes I had made to config file/arguments used at miner launch in version 1.3.2 is why this wasn't a problem before. Because of this unexpected behavior, it will always save the gpu-threads value to the config file, even if it's the default value. And if you're using arguments, it should be corrected now also. Thanks for making me aware of this, and let me know if you still experience any problems with it.

Let's say this happens. Bigger than the SR story would be the story that "a few million dollars has been stolen from the government."

Do you think that would help or hurt Bitcoin?

Do you think the average person is going to feel safe buying Bitcoins when not even the FBI could keep their Bitcoins safe?

Agreed.



Edit: To the people whining below that it can't be done and therefore anyone answering whether it should be done is an idiot... the question is whether it should be done. Nowhere in the OP does it ask if it can be done, or how difficult or unlikely it would be.

New in version 1.3.2

• Desktop folder added to protected directories list to notify user that CGWatcher, miner, and config files should not be stored there.
• Advanced Profile options to set CPU affinity and priority for miner process. Additional options to come in future versions.
• Profile matching relaxed during miner launch to reduce risk of miner being ignored (rare).
• Fixed ads only reloading after restarting CGWatcher.
• Button added to Tests tab to list all installed .NET updates for troubleshooting purposes.
• Option to restart computer if CGWatcher is unable to close or kill miner processes. Although rare, this indicates a more serious problem (Task Manager is also unable to kill the processes) and usually leads to a BSOD (crash). The only way to resolve this is to restart the computer.
• Pools truncated from miner's API response (~Pool 35+) will get info from config to avoid chinese-looking characters being shown for url/username/password. No stats are available for these pools though because the data is cutoff from the miner's response, which has a fixed maximum length.
• Fixed pools set in arguments being added twice to temp config file before miner starts.
• Added scheduled action to send specified API command(s) to miner.
• Settings tab added to Coin Manager, 'Remove coins no longer on CoinChoose' option moved to Settings tab of Coin Manager.
• Coin profitability data refresh interval setting now in Settings tab of Coin Manager.
• Setting created to base coin profitability on bitcoin or litecoin, located in Settings tab of Coin Manager.
• New coin notification option moved to Settings tab of Coin Manager.
• Scheduled action frequency added - 'When event occurs...' allowing you to select from a list of events that will trigger the action being run. Events currently consist of miner events, profile events, and coin profitability events. More events will be added in future updates.
• Create your own profitability formula in a custom coin field that can be used when creating scheduled actions that switch profile based on profitability. Instead of using an existing field (profitability, difficulty, etc) you can create your own mathematical expression using all existing fields and mathematical functions.
• Fixed CGWatcher not trying to start the miner indefinitely when the 'Keep trying indefinitely' failure option was selected. (It will try up to 2147843647 times.)
• Miner process not added to checked process list until it has been running for 60+ seconds to prevent incorrectly ignoring it.
• Added 'Send email' scheduled action. You can specify an email address for each action, the last used will be filled in automatically. Emails are currently limited to 25 per computer per day, but this may increase or decrease over time depending on usage. Counter is reset at midnight EST/EDT (U.S. Eastern). Emails will be coming from @cgwatcher.com, and you will need to ensure you can access http://minerremote.com for email to work correctly.
• More scheduled action events will be added, with additional options like 'when hashrate drops below/%', 'when miner restart fails X consecutive times, etc. I figured I'd add them in groups instead of trying to do it all at once.
• If CGWatcher is set to try starting the miner indefinitely (and it keeps failing), it will wait one second per 10 attempts in between attempts over 10, up to 60 seconds. So after 600 attempts it will wait one minute between each attempt.
• CGWatcher restarting GPUs that cgminer has disabled due to overheat no longer requires CGWatcher's overheat protection to be enabled. It will do this for all GPUs since the miner usually fails at re-enabling them.
• Before restarting computer, CGWatcher will temporarily set itself to start with Windows and launch miner at startup if these options are not enabled. It will reset the options back to their original settings the next time CGWatcher is started.
• Restart computer prompt changed to always use CGWatcher's prompt only, which provides a cancel option, rather than the Windows notification that the computer is restarting. This was already how scheduled computer restarts were handled, but is now done for all computer restarts.
• Profitability-based scheduled actions (switch profile based on profitability) will update coin data before selecting a profile unless it had been updated within the past minute instead of within the past 5 minutes.
• Added average time per share to Monitor tab to help in setting appropriate number of minutes without share increase for this monitoring option.
• Added "% of Avg" to Hashrate Cutoff monitoring option, which will restart the miner if the current hashrate drops below the specified percentage of the current average hashrate. This is in addition to being able to set actual hashrate values.
• Elapsed mining time added to Stats tab.
• In Pools tab, pool drop-down will default to current pool and revert to current pool if user has not selected a different pool to view within the last 5 minutes.
• Added support for pool quota option in CGMiner 3.4.3+
• Added config file and argument options up through CGMiner 3.5.0 and BFGMiner 3.2.1.
• Select a different value to display on the Status tab in place of Efficiency, or create your own value using existing values and mathematical functions to create a custom expression.

New in version 1.3.2

• Desktop folder added to protected directories list to notify user that CGWatcher, miner, and config files should not be stored there.
• Advanced Profile options to set CPU affinity and priority for miner process. Additional options to come in future versions.
• Profile matching relaxed during miner launch to reduce risk of miner being ignored (rare).
• Fixed ads only reloading after restarting CGWatcher.
• Button added to Tests tab to list all installed .NET updates for troubleshooting purposes.
• Option to restart computer if CGWatcher is unable to close or kill miner processes. Although rare, this indicates a more serious problem (Task Manager is also unable to kill the processes) and usually leads to a BSOD (crash). The only way to resolve this is to restart the computer.
• Pools truncated from miner's API response (~Pool 35+) will get info from config to avoid chinese-looking characters being shown for url/username/password. No stats are available for these pools though because the data is cutoff from the miner's response, which has a fixed maximum length.
• Fixed pools set in arguments being added twice to temp config file before miner starts.
• Added scheduled action to send specified API command(s) to miner.
• Settings tab added to Coin Manager, 'Remove coins no longer on CoinChoose' option moved to Settings tab of Coin Manager.
• Coin profitability data refresh interval setting now in Settings tab of Coin Manager.
• Setting created to base coin profitability on bitcoin or litecoin, located in Settings tab of Coin Manager.
• New coin notification option moved to Settings tab of Coin Manager.
• Scheduled action frequency added - 'When event occurs...' allowing you to select from a list of events that will trigger the action being run. Events currently consist of miner events, profile events, and coin profitability events. More events will be added in future updates.
• Create your own profitability formula in a custom coin field that can be used when creating scheduled actions that switch profile based on profitability. Instead of using an existing field (profitability, difficulty, etc) you can create your own mathematical expression using all existing fields and mathematical functions.
• Fixed CGWatcher not trying to start the miner indefinitely when the 'Keep trying indefinitely' failure option was selected. (It will try up to 2147843647 times.)
• Miner process not added to checked process list until it has been running for 60+ seconds to prevent incorrectly ignoring it.
• Added 'Send email' scheduled action. You can specify an email address for each action, the last used will be filled in automatically. Emails are currently limited to 25 per computer per day, but this may increase or decrease over time depending on usage. Counter is reset at midnight EST/EDT (U.S. Eastern). Emails will be coming from @cgwatcher.com, and you will need to ensure you can access http://minerremote.com for email to work correctly.
• More scheduled action events will be added, with additional options like 'when hashrate drops below/%', 'when miner restart fails X consecutive times, etc. I figured I'd add them in groups instead of trying to do it all at once.
• If CGWatcher is set to try starting the miner indefinitely (and it keeps failing), it will wait one second per 10 attempts in between attempts over 10, up to 60 seconds. So after 600 attempts it will wait one minute between each attempt.
• CGWatcher restarting GPUs that cgminer has disabled due to overheat no longer requires CGWatcher's overheat protection to be enabled. It will do this for all GPUs since the miner usually fails at re-enabling them.
• Before restarting computer, CGWatcher will temporarily set itself to start with Windows and launch miner at startup if these options are not enabled. It will reset the options back to their original settings the next time CGWatcher is started.
• Restart computer prompt changed to always use CGWatcher's prompt only, which provides a cancel option, rather than the Windows notification that the computer is restarting. This was already how scheduled computer restarts were handled, but is now done for all computer restarts.
• Profitability-based scheduled actions (switch profile based on profitability) will update coin data before selecting a profile unless it had been updated within the past minute instead of within the past 5 minutes.
• Added average time per share to Monitor tab to help in setting appropriate number of minutes without share increase for this monitoring option.
• Added "% of Avg" to Hashrate Cutoff monitoring option, which will restart the miner if the current hashrate drops below the specified percentage of the current average hashrate. This is in addition to being able to set actual hashrate values.
• Elapsed mining time added to Stats tab.
• In Pools tab, pool drop-down will default to current pool and revert to current pool if user has not selected a different pool to view within the last 5 minutes.
• Added support for pool quota option in CGMiner 3.4.3+
• Added config file and argument options up through CGMiner 3.5.0 and BFGMiner 3.2.1.
• Select a different value to display on the Status tab in place of Efficiency, or create your own value using existing values and mathematical functions to create a custom expression.

So much for the good customer service angle... 3 pages into your official thread and you're already getting bitchy. If you've been involved in the bitcoin community long enough to be developing asics, you should already know this comes with the territory. If you want to prove everyone wrong, do it with your machines and not in pissy posts to anyone questioning you. If you're legitimate and competent, you should have come here prepared with more information than you'd even need... instead it's a lot of nothing.

The one guy defending you, claiming you're "on the level", has 4 posts and I get the feeling you and boaz33 are the same person. I came across another newbie who only posts recommending your company, even when nobody is asking... are you also Samadamsdrinker?



and one of your last posts (keep in mind, you only registered on the forum on September 29th)...



Also, "Refunds will be given if we don't meet shipment dates within a reasonable time." What if our definitions of reasonable time are different? There seems to be a lot of gray area in this whole scheme.

Thanks in advance for answering my concerns.

I suggest that you hold off on ordering anything from advancedminers.com until it has been confirmed as legitimate by someone other than a forum newbie with three posts all recommending AMT miners. This company, its spokesman, and related thread are throwing up some red flags. I'm not certain it's a scam, but make sure to do your due diligence before giving them any money.

Fredeq: I would suggest setting at least one backup pool (aside from another multipool server) so that if you're unable to connect to multipool, you're at least mining something. If you have cgminer set to failover, it should switch to the backup pool and then check the first pool occasionally to see if it is alive. If it is alive, it will switch back to it. This should also resolve the problem of cgminer taking so long when starting, because it will find a working pool and continue instead of trying to use a dead pool indefinitely.

If you find that cgminer does not switch back to multipool (or any pool with lower priority number) when it comes back alive, let me know and I'll try to add options in CGWatcher to ensure this happens. I think cgminer has always done this correctly in my personal experience.

It depends. If everyone was mining the same alt-coins and going with most profitable, then yes, that coin's difficulty would increase and so would the likelihood that there will not be enough buyers if the coin's trading volume is low (as is the case with many alt-coins). This already happens with scrypt-based coins, and pools like middlecoin and hashco.ws only exacerbate this by having everyone in the pool do the exact same thing at the exact same time. With CGWatcher, you can select which coins to mine, so if you don't mine all alt-coins you reduce the risk of being on the same coin as the herd. You can also choose to mine your 1st, 2nd, 3rd, etc. most profitable just to avoid situations like this. Although a coin is 2nd most profitable, by not going with 1st most profitable you're hopefully avoiding the herd and you can mine that coin longer without difficulty spikes. You can also set how often it checks & switches coins by interval or date/time (or other options) to further separate yourself from everyone else.

There are also a number of attributes you can set CGWatcher to use when deciding which coin to mine:

Profitability
Profitability (adjusted for stales)
Profitability (24-hour average)
Highest Reward
Lowest Difficulty
Lowest Network Hashrate
Lowest Network Hashrate (7-day average)

Right now I'm working on allowing the user to create their own formula using these values, which will allow you to experiment rather than just go by what CoinChoose deems most profitable as everyone else is. This will reduce the likelihood even more that you're mining with the herd, which means the coin you're mining won't be most profitable for very long once difficulty and trading volume catch up.