Pages:
Author

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

sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
Good to hear. That's interesting, and yet another thing to add to the list of unexpected behaviors. I'm not sure which setting(s) are causing this, but most likely I'll change it to not leave out any options, even if they are set to default values. As I mentioned, my concern in doing this would be that it would introduce a new unexpected behavior, so I want to think about this more before I just make the change and I'm heading to bed at the moment.

If you get a chance and don't mind, make sure you have the latest version (1.1.8.0b) and remove those two lines (api-listen and api-allow), save the config, and start the miner again. I'm just curious as to whether your particular issue has been fixed in the update. If you get a chance to do that and can let me know if the hashrate is affected, I'd really appreciate it.

I've also made additional changes in 1.1.8.0b that limit the need for CGWatcher to modify a config file when starting the miner even more. If I can ultimately have it avoid doing this at all, that is my goal. But if you're using arguments and a config file, it is currently necessary in order to have the argument settings override the config file settings... as well as the other couple scenarios I mentioned like API enabling (although this has been limited more in 1.1.8.0b). Anyway, I'll make sure this is resolved in 1.1.9. Thanks again for the help.
full member
Activity: 181
Merit: 100
ok i added

Code:

"api-listen" : true,
"api-allow" : "W:127.0.0.1",


to my config file and.......it works!!! Grin Grin
hashrate is now as before

thanks for your help
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
Unfortunately I didn't see anything that stood out that would explain this. I did make a few proactive changes so I'd recommend you download again to get the updated files. Then as a test to make sure this is not a config file issue, can you add the options to your config file to enable the API? Add the two lines (api-listen and api-allow) to your config file as shown below and save. (I added them after api-port, but you can put them anywhere. Just make sure to include any necessary commas in between options):

Code:
...
"temp-overheat" : "85",
"temp-target" : "75",
"api-port" : "4028",
"api-listen" : true,
"api-allow" : "W:127.0.0.1",
"expiry" : "120",
"gpu-dyninterval" : "7",
...

Why I suggest trying this is because enabling the API will mean CGWatcher does not have to modify your config file before it launches the miner. You can see from the info you posted that it did modify your config file to enable the API right before it started the miner (debug_config.txt), and then restored the original after the miner started. You can see when comparing your config file with debug_config.txt that no settings were changed aside from API being enabled, but settings that were set to default values were left out because they're default values and those values should be used anyway. The reason for this initially was to reduce the options listed in config files because CGWatcher has a lot of users new to mining and there is often confusion about setting up config files. I figured the less options there were, the easier it would be to follow.

I was also leaving out scrypt options like lookup-gap, shaders, and thread-concurrency if the scrypt option was not enabled, but I just changed that as well to make sure it is not a misunderstanding on my part how those work. I've also reduced the number of options that it may leave out if set to default values. Now only numeric options (e.g. vectors, worksize, etc.) set to the default value explicitly listed in cgminer's Readme are left out. Before it was also doing this to non-numeric options like kernel path, etc., (which also have default values explicitly listed in the Readme.)

You may ask why not just use arguments to enable the API. That is because cgminer gives priority to the config file, not to arguments. (I wanted CGWatcher to do the opposite, allowing you to, for example, use a base config file for multiple profiles and just tweak some options using arguments. This is what I'd guess users would expect to happen.) This means if I want to make sure an option is set, I have to do it in the config file. If I set --api-allow W:127.0.0.1 in arguments and in the config file api-allow was set to "api-allow" : "W:123.45.67.89", cgminer would use the 123.45.67.89. I have and will continue to try to reduce the situations where CGWatcher has to modify a config file at all... but for now if you don't have API enabled, have forced API port enabled, or are using arguments and a config file together, CGWatcher will modify the config file right before starting the miner and then restore it afterwards. This is the purpose of debug_config.txt... so if the thought of CGWatcher modifying your settings worries you, you can see exactly what the config file said when the miner was started.

Aside from those options being left out of the config file having an effect (even though they were set to default values), I don't see a reason for a drop in hashrate cause by CGWatcher. Are you reading the hashrate from cgminer both times? I have CGWatcher and cgminer running on multiple machines and have not seen any decrease. Even running multiple instances of CGWatcher and cgminer on the same computer did not cause a decrease in hashrate.
full member
Activity: 181
Merit: 100
hi, thanks for the quick reply

- my config file :

{
"pools" : [
   {
      "url" : "http://eu-stratum.btcguild.com:3333",
      "user" : "xxx",
      "pass" : "xxx"
   }
]
,
"intensity" : "11",
"vectors" : "1",
"worksize" : "256",
"kernel" : "poclbm",
"lookup-gap" : "0",
"thread-concurrency" : "0",
"shaders" : "0",
"gpu-engine" : "1100",
"gpu-fan" : "0-85",
"auto-fan" : true,
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "75",
"api-port" : "4028",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "2",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "60",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}


- debug_config.txt

// [DEBUG : F:\cgminer-3.2.1-windows\cgminer.conf]
// This is the config file text used to start CGMiner using profile "Default" at 20/06/2013 22:13:16.
// It may have been modified before starting the miner in order to correctly apply arguments or API settings.
// If it was modified, it is restored to its original version after the miner starts or fails to start.
// Arguments used at miner start were "--config cgminer.conf --api-listen --api-allow W:127.0.0.1"


{
"pools" : [
   {
      "name" : "eu-stratum.btcguild.com",
      "url" : "http://eu-stratum.btcguild.com:3333",
      "user" : "xxx",
      "pass" : "xxx",
      "pool-priority" : "0"
   }
],
"api-allow" : "W:127.0.0.1",
"api-listen" : true,
"auto-fan" : true,
"gpu-engine" : "1100",
"gpu-fan" : "0-85",
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"intensity" : "11",
"temp-target" : "75",
"temp-overheat" : "85",
"temp-cutoff" : "95",
"vectors" : "1",
"worksize" : "256",
"no-pool-disable" : true
}

- report tab :

CGWatcher information:
 CGWatcher start time............. 20/06/2013 22:25:59
 CGWatcher version................ 1.1.8.0
 Active profile................... Default
 Monitor enabled.................. True
 Current monitor start time....... 20/06/2013 22:26:00
 Monitor duration................. 1 min, 2 sec
 System idle seconds.............. 3 sec
 Checks performed................. 10
 Last check date/time............. 20/06/2013 22:26:57
 Restarts performed............... 0
 Last restart reason..............


Current Mining Session:
 Miner............................ CGMiner
 Version.......................... 3.2.1
 API version...................... 1.25
 Arguments........................ --config cgminer.conf
 Miner executable................. F:\cgminer-3.2.1-windows\cgminer.exe
 Config file...................... F:\cgminer-3.2.1-windows\cgminer.conf
 Miner is running................. True
 Miner using profile.............. Default
 Miner using pool (worker@URL)....xxx@http://eu-stratum.btcguild.com:3333
 Miner start time................. 20/06/2013 22:26:02
 Miner stop time.................. N/A
 Mining duration.................. 60 sec
 Current total hashrate........... 249,13 Mh/s
 Current average hashrate......... 257,12 Mh/s
 Accepted shares.................. 2
 Rejected shares.................. 0
 Stale shares..................... 0
 Discarded work................... 4
 Local work....................... 13
 Getworks......................... 3
 Getwork failures................. 0
 Hardware Errors.................. 0
 Best share....................... 7
 New blocks....................... 1
 Found blocks..................... 0
 Efficiency....................... 66,67%
 Strategy......................... Failover
 Hash Method...................... SHA256
 Current Block Time............... 1371759965,67959
 Current Block Hash............... 0000000000000005490fb1f53de9e19fb34cb29051e5f04dd2e9643795995273
 Current Block Difficulty......... 19339258,2723867
 LongPoll......................... False
 Work Utility (diff1 shares)...... 2,25/minute
 Accepted work rate (utility)..... 0,033/sec (2,000/min)
 Rejected work rate............... 0,000/sec (0,000/min)
 Stale work rate.................. 0,000/sec (0,000/min)
 Discarded work rate.............. 0,067/sec (4,000/min)


Profile Information:
 Active Profile................... Default
 Miner executable................. F:\cgminer-3.2.1-windows\cgminer.exe
 Config file...................... F:\cgminer-3.2.1-windows\cgminer.conf
 Arguments........................
 Real arguments................... --config cgminer.conf


Network statistics: (all pools)
 Times Sent....................... 6
 Bytes Sent....................... 491
 Times Received................... 10
 Bytes Received................... 3 916
 Net Bytes Sent................... 1 248
 Net Bytes Received............... 3 916


Hardware
 GPU count......................... 1
 GPU order type.................... Device ID
 GPU-map...........................
 ADL disabled...................... False
 GPU-platform...................... 0
  GPU0............................. AMD Radeon HD 7800 Series
   -miner ID....................... 0
   -status......................... ALIVE
   -intensity...................... 11
   -original intensity............. 11
   -hashrate....................... 249,13 Mh/s
   -temperature.................... 69°C
   -temp-target.................... 75°C
   -temp-overheat.................. 85°C
   -temp-cutoff.................... 95°C
   -has overheat protection........ True
   -overheat reduced intensity..... False
   -overheat caused disable........ False
   -bus............................ 1
   -device......................... 0
   -device path....................
   -identifier..................... /atigpu/0
 FPGA count........................ 0
 ASIC count........................ 0


This information was last updated: 20/06/2013 22:27:02
-----------------------------------------------------------------------------------------------------------------------

Debug Information:
 Operating system................. Microsoft Windows 7 Édition Familiale Premium  6.1.7601.65536
 Pools............................ 1
  Pool0........................... http://eu-stratum.btcguild.com:3333 (ALIVE)
 Miner Process ID................. 4804
 Miner MyProcess ID............... 4804
 Total miner instances............ 1
 Miner launched by me............. True
 Miner last started by............ Monitor
 Miner startup grace period....... 3 min
 Has API access................... True
 Had API access to process........ True
 Has full API access.............. True
 Had full API access to process... True
 Default miner API port........... 4028
 Current miner API port........... 4028
 Force API port on miner start.... False
 Use backup hardware mode......... False
 OpenCL platforms count........... 1
 OpenCL device count.............. 1
 Last (a/r/s) share change........ 20/06/2013 22:26:47 (15 sec ago)
 Last accepted share change....... 20/06/2013 22:26:47 (15 sec ago)
 Last rejected share change....... 20/06/2013 22:26:00 (1 min, 2 sec ago)
 Last stale share change.......... 20/06/2013 22:26:00 (1 min, 2 sec ago)
 Last discarded share change...... 20/06/2013 22:26:21 (40 sec ago)
 Monitor enabled.................. True
 Monitor interval................. 5 sec
 Restart Hashrate enabled......... False
 Restart Hashrate cutoff.......... 0 Mh/s
 Restart Every X Hours enabled.... False
 Restart Every X Hours hours...... 24 hour(s)
 Restart Share Totals enabled..... True
 Restart Share Totals minutes..... 10 minute(s)
 Restart Sick/Dead GPUs enabled... True
 Restart API Access Loss enabled.. False
 Ensure miner is running enabled.. False
 Schedule Enabled................. False
 Schedule Start Time.............. 22:26:00
 Schedule Stop After hours........ 8 hour(s)
 Change intensity on idle......... False
 Change intensity to value........ 10
 Idle minutes required............ 30
 Installed UI culture............. fr-FR
 Culture decimal separator........ (,)
 Culture group separator.......... ( )
 Max available log entries........ 100
 Version Response................. STATUS=S,When=1371760022,Code=22,Msg=CGMiner versions,Description=cgminer 3.2.1,VERSION,CGMiner=3.2.1,API=1.25,
 Privileged Response.............. STATUS=S,When=1371760022,Code=46,Msg=Privileged access OK,Description=cgminer 3.2.1,
 Config Response.................. STATUS=S,When=1371760022,Code=46,Msg=Privileged access OK,Description=cgminer 3.2.1,
 Coin Response.................... STATUS=S,When=1371760022,Code=78,Msg=CGMiner coin,Description=cgminer 3.2.1,COIN,Hash Method=sha256,Current Block Time=1371759965.679593,Current Block Hash=0000000000000005490fb1f53de9e19fb34cb29051e5f04dd2e9643795995273,LP=false,Network Difficulty=19339258.27238668,
 Summary Response................. STATUS=S,When=1371760022,Code=11,Msg=Summary,Description=cgminer 3.2.1,SUMMARY,Elapsed=53,MHS av=257.12,Found Blocks=0,Getworks=3,Accepted=2,Rejected=0,Hardware Errors=0,Utility=2.25,Discarded=4,Stale=0,Get Failures=0,Local Work=13,Remote Failures=0,Network Blocks=1,Total MH=13690.2083,Work Utility=2.25,Difficulty Accepted=2.00000000,Difficulty Rejected=0.00000000,Difficulty Stale=0.00000000,Best Share=7,


Last 10 Log entries:
[20/06/2013 22:26:00]    [d] WER DontShowUI value exists (1) and was set to 1 (disabled).
[20/06/2013 22:26:01]        Active profile is "Default"
[20/06/2013 22:26:01]        No CGMiner instance found.
[20/06/2013 22:26:01]        You requested I run CGMiner upon starting. Attempting to start using profile "Default"...
[20/06/2013 22:26:01]    [d] Preparing to autostart miner using (Miner=F:\cgminer-3.2.1-windows\cgminer.exe; Config=F:\cgminer-3.2.1-windows\cgminer.conf; Arguments=--config cgminer.conf)
[20/06/2013 22:26:01]    [d] Miner.StartMining called. (Profile=Default;Miner=F:\cgminer-3.2.1-windows\cgminer.exe;Config=F:\cgminer-3.2.1-windows\cgminer.conf;Arguments=--config cgminer.conf --api-listen --api-allow W:127.0.0.1;Anticipated Port=4028;Used Port=4028;HasFullAPIAccess=True)
[20/06/2013 22:26:03]    [d] API initialized and process matched to profile Default.
[20/06/2013 22:26:05]        CGMiner started successfully.
[20/06/2013 22:26:05]        CGMiner was successfully launched upon startup as you requested.
[20/06/2013 22:26:11]        Monitoring is turned on at 5 second intervals.


 Huh
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
Can you provide a little more info? Are you looking at the hashrate in cgminer both times? I ask that to make sure it is not just a problem with CGWatcher displaying hashrates incorrectly. CGWatcher doesn't change any settings other than enabling the API, and specifying the API port if necessary.

Can you provide your config file and/or arguments? Also, if you use a config file there should be a file called debug_config.txt in the CGWatcher directory. If you can include that as well to make sure nothing is getting incorrectly changed before the miner is started. Also the text in the Report tab may be helpful.

It's a lot of info, but it will help me find a problem quickly if one exists. You can either post the contents of the files here or email them to me (email address in ReadMe).

Thanks, I appreciate the feedback.
full member
Activity: 181
Merit: 100
hello, there is something wrong with the latest version, i have an hd7850 ashrate around 330-340 mh/s with cgminer, when i lauch cgwatcher 1.1.8, i loose 100 Mh/s  Huh
ashrate is around 240 Mh/s  Shocked
Go back to version 1.1.5 which works fine.
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
It is possible that at the highest intensity, the extra work needed to display CGWatcher slightly affects performance... especially for scrypt and intensity 20. Although this is not something that has been reported previously, and I haven't experienced this with my (two) 7950s. I'm not doubting your post, just hoping this is not the cause because there is not a whole lot I can do about it in this case. It's no secret that displaying a GUI requires more work, but in my opinion its advantages justify it. This is likely a top reason cgminer doesn't have a GUI. Perhaps I could ultimately move to a very basic window showing hashrate, temps, etc. and only show the main window when necessary (or requested) since it is filled with controls.

I don't think the API calls would cause this because neither program uses much CPU, but increasing the monitor interval in CGWatcher would help if this is an issue as API calls would occur less often. I've been reducing API calls whenever possible over the past few versions anyway, but there may still be some room for improvement.

If you experience a decrease in performance at max intensity (especially for scrypt), I guess you just have to decide if the benefits CGWatcher provides outweigh the decrease. I'd like to think it does... if cgminer unexpectedly stops working for an hour, the slight decrease suddenly becomes acceptable. But I guess that depends on how often your miner has issues or whether or not you prefer a GUI.

Either way, thanks for the info and I'll definitely keep this in mind and look to reduce the footprint whenever possible in future updates.
sr. member
Activity: 662
Merit: 250
I have 8 7950s hashing away at 660-670 with cgminer only, -I 20, but as soon as I try to run the same config through cgwatcher, I'm maxing out around 648 per card.

This drop doesn't appear to occur if I run cgminer with cgwatcher and -I 19 per card.  I don't want to spout any assumptions, but I did want to note the phenomenon.
sr. member
Activity: 252
Merit: 250
Fallon: Thanks, this was a bug and is fixed in 1.1.7 which is now available.


WuLabsWuTecH: Yes, make sure you're using the latest version because previous versions didn't support this. Right now you would have to run each CGWatcher instance from a separate folder because I haven't handled multiple instances writing to the same INI file yet. So, for example, you'd have to create C:\Miners\CGWatcherA and C:\Miners\CGWatcherB. Also, each instance and miner need to use their own API port, so

CGWatcher A  <->  Miner A    (port 4028)

CGWatcher B  <->  Miner B    (port 4029)


In CGWatcher A, go to the Settings tab and make sure Miner API Address is set to 127.0.0.1:4028, and check Force this API port. Click Save Settings.

In CGWatcher B, go to the Settings tab and set Miner API Address to 127.0.0.1:4029, and check Force this API port. Click Save Settings.

This will ensure that when you start a miner from each CGWatcher, it will make sure the miner is using that port regardless of what its config file or arguments say. Both CGWatcher instances can point to the same miner, and even point them to the same config file... but you'll need to use each CGWatcher's arguments to set which devices you want each instance to use.

To make things easier, you could setup CGWatcher A and then copy all its files to CGWatcher B. That way it will copy profiles and settings and all you'll need to change is the port setting mentioned above and set which devices each instance will use. As as example, CGWatcher A would use a profile with arguments -d 0 (to use device 0) and CGWatcher B would use a profile with arguments -d 1 (to use device 1).

I'm not sure what you mean by "shut down one device", but if you just want to stop a GPU or FPGA from mining you can disable it using the Disable button in the GPU or FPGA tab. I don't think there is currently a similar option for ASICs, but I can't think of a reason you'd want to disable an ASIC if you have one anyway.

Thanks!  I will give this a try in the morning.  And yes, I'd like to disable the ASIC because I shut it down and take ith with me to work/school in my pocket Smiley  Not that it costs that my electric to run anyways!
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
Fallon: Thanks, this was a bug and is fixed in 1.1.7 which is now available.


WuLabsWuTecH: Yes, make sure you're using the latest version because previous versions didn't support this. Right now you would have to run each CGWatcher instance from a separate folder because I haven't handled multiple instances writing to the same INI file yet. So, for example, you'd have to create C:\Miners\CGWatcherA and C:\Miners\CGWatcherB. Also, each instance and miner need to use their own API port, so

CGWatcher A  <->  Miner A    (port 4028)

CGWatcher B  <->  Miner B    (port 4029)


In CGWatcher A, go to the Settings tab and make sure Miner API Address is set to 127.0.0.1:4028, and check Force this API port. Click Save Settings.

In CGWatcher B, go to the Settings tab and set Miner API Address to 127.0.0.1:4029, and check Force this API port. Click Save Settings.

This will ensure that when you start a miner from each CGWatcher, it will make sure the miner is using that port regardless of what its config file or arguments say. Both CGWatcher instances can point to the same miner, and even point them to the same config file... but you'll need to use each CGWatcher's arguments to set which devices you want each instance to use.

To make things easier, you could setup CGWatcher A and then copy all its files to CGWatcher B. That way it will copy profiles and settings and all you'll need to change is the port setting mentioned above and set which devices each instance will use. As as example, CGWatcher A would use a profile with arguments -d 0 (to use device 0) and CGWatcher B would use a profile with arguments -d 1 (to use device 1).

I'm not sure what you mean by "shut down one device", but if you just want to stop a GPU or FPGA from mining you can disable it using the Disable button in the GPU or FPGA tab. I don't think there is currently a similar option for ASICs, but I can't think of a reason you'd want to disable an ASIC if you have one anyway.
sr. member
Activity: 252
Merit: 250
Question: is there a way to run two instances of this for two separate mining devices?  Right now, everytime I want to shut down one device, I have to change profiles.  Can I run 2 instances of CGWatcher with two instances of CGminer?
newbie
Activity: 13
Merit: 0
Bug report: For the past couple versions, the "Download" link after clicking on the Check for Update button doesn't work. I just updated to 1.1.6a & can't test as I'm now at the latest version.
hero member
Activity: 924
Merit: 1000
Watch out for the "Neg-Rep-Dogie-Police".....
Thanks for the answer milone. Yes, I read about cgremote - that seems to be exactly what I'm after if it can monitor regardless of OS. To be honest, I'm not too bothered about having the ability to control the miners via cgremote - if it has the ability to reset/restart the miner/rig if it hangs/locks then that will be enough for me.

Kudos to you for your work milone, I hope to see the fruits of cgremote soon....

Peace  Grin
sr. member
Activity: 319
Merit: 250
Thanks, that worked.

I love the program, please don't make it ignore cgminer instances it doesn't create. Or at least make that a checkbox. I do a lot of switching cgminer.conf files, to mine different coins during the day, and cgwatcher works great. It allows me to use something like CrytoSwitcher and CGWatcher to make sure everything stays up and mining the best coins.
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
The best answer would be to just create a profile for the miner. If you have and it still prompts you, please send me more info. The Report tab text, your profiles.dat file contents (you can open in Notepad), and any relevant log entries would be helpful.

Any time CGWatcher detects a miner process running that it did not start and didn't previously monitor, it tries to match it to a profile. The reason for this is because if it knows which profile/config file/arguments the miner is using, it can provide better information and control for things like overheat protection (where it needs to know your config temp-target, temp-overheat, temp-cutoff, etc.) and isn't reliant on the API alone. It also makes it more easier for new users to setup profiles for different miners.

How it works specifically is that CGWatcher tries to match a miner process to a profile based on miner path and API port (from the profile's config file or arguments). In other words, it looks to see which API port the profile is using and if it can establish communication on that port... and the process's filename match the profile's miner path (executable path if a .bat or .cmd file is used)... it assumes that is the correct profile. It also checks profiles in a specific order to try to best determine the profile in the case that multiple profiles match. If it finds that the miner does not match a profile, it will ask if you want to create one. It should only ask you this once per process, so it won't ask again unless you close and re-launch, or restart the miner (because restarting creates a new process). I suppose it could get a little annoying if you restart the miner and it prompts you again, so I'll try to fix this.

I think if I ever create version 2.0 it will just ignore any miners it did not start. That would make things much simpler.
sr. member
Activity: 319
Merit: 250
How do you prevent the popup asking if you want to create a profile? Is there a switch to add when you run the exe? Or an entry in the ini?
hero member
Activity: 714
Merit: 500
Are ฿itcoins Radioactive?
...
ct1aic: cgminer deserves the credit for that. It allows you to set clock speeds above what the AMD (or similar) software allows. I don't know how the AMD software determines what the max clock speeds are, but I'd guess that cgminer either doesn't check this or ignores it. The same is probably true of voltages, although if you raise voltages past what AMD recommends you risk damaging components.
...

Thanks for the kind answer, milone.
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
gektek: You're welcome, I'm glad you find it helpful.


ct1aic: cgminer deserves the credit for that. It allows you to set clock speeds above what the AMD (or similar) software allows. I don't know how the AMD software determines what the max clock speeds are, but I'd guess that cgminer either doesn't check this or ignores it. The same is probably true of voltages, although if you raise voltages past what AMD recommends you risk damaging components.


PatMan: CGWatcher is currently Windows only, though that may change in the future. I'm also working on a program called CGRemote, which will allow you to monitor multiple miners regardless of OS (however if it is a Windows miner I recommend running CGWatcher on the miner as well because this will give you better control - see diagram in reply above). There is another project I'm going to be working on for the next 6-8 weeks but hasn't been finalized yet so aside from any bugs popping up in CGWatcher, I will be trying to get as much done on CGRemote until I begin the other project.


RandyMagnum: Correct, if cgminer is managing temperatures for a GPU, CGWatcher will not interfere. The only exception to this is if cgminer disables a GPU for exceeding temp-cutoff (default 95c). It is supposed to re-enable the GPU once it cools down, and will even show in its UI that it attempts to... but in testing I've never seen it succeed in successfully re-enabling the GPU. So when this occurs, CGWatcher will restart the GPU to make sure it gets going again. This only happens if CGWatcher's overheat protection is enabled (in the Monitor tab).

You can verify which program is providing the overheat protection for a GPU in the GPU tab. If you scroll down the large textbox at the bottom, you'll see "Overheat protection........" It will say either "CGMiner auto-gpu mode" if cgminer is doing it, "CGWatcher" if CGWatcher is doing it, or "None" if neither program is doing it. It also displays a green shield or yellow warning symbol next to the temperature, which if you put your mouse over will provide you with details of what overheat protection is enabled for that GPU.

If you don't want CGWatcher to interfere at all when it comes to overheat protection, you can disable it in the Monitor tab. There was a bug with the checkbox not being checked correctly when the program starts up (even if overheat protection was enabled) that I fixed yesterday, so make sure you've downloaded 1.1.6.0a to ensure it will correctly show you whether it is enabled or not.
sr. member
Activity: 662
Merit: 250
Regarding the 1.1.6 update and temperature control:

If I've setup my cgminer.conf with auto fan, target temp, overheat, and shut off temps, cgwatcher doesn't interfere with these config setting does it?

I haven't toyed with overheat protection through cgwatcher is why I'm curious.
hero member
Activity: 924
Merit: 1000
Watch out for the "Neg-Rep-Dogie-Police".....
This is a great app, well done. Do you have any plans for it to be able to communicate with miners on Linux? All my rigs run on Xubuntu but my main PC runs windoze - it would be great if I could use this app to monitor my linux miners from my windoze PC.

Peace.
Pages:
Jump to: