Topic: CGWatcher 1.4.0, a GUI/monitor for CGMiner & BFGMiner to help minimize downtime - page 14. (Read 402549 times)

Alright, super thanks! Seems like the mapping had to be:

0:0,1:2,2:1,3:3

No idea why they changed place like that, but now it makes much more sense with temperatures increasing for the right GPU!

Is there any way to monitor the GPU voltage and (re-)set it so a specific value?

Every now and then either cgwatcher or cgminer resets my "undervolted" GPU to to standard voltage. The gpu then overheats and overheat protection kicks in, lowering my hashrate.
I am using Sapphire Trixx to set the correct speeds and voltages. But since this problem occured, i also set the desired GPU speed and voltage in the config file, but that doesn't seem to help. When i start Sapphire Trixx and apply the correct voltage again, temps lower and everything works fine for a while. The problem occurs more often when a pool is instable and cgminer gets restarted more often. Other than that mining works like a charm. No HW errors and few rejects.

I am using a Club3D HD7970 '13 edition and a Club3D R9 280X Royalqueen which are both voltage-unlocked.
When i was only using the HD7970, that card had this problem. Then i put the 280X in its place and moved the 7970 in a lower PCI-e slot. Now the 280X has this problem. The cards are not in crossfire.
I am using Catalyst 13.11, cgminer 3.7.2 and cgwatcher (1.3.3) and now 1.3.4.
Rest of the system is an Intel Core i5 2500K and a ASRock Z68 Extreme3 Gen3.

I am using these settings:
"api-allow" : "W:127.0.0.1",
"api-listen" : true,
"scrypt" : true,
"gpu-threads" : "2",
"intensity" : "13, 13",
"vectors" : "1, 1",
"kernel" : "scrypt,scrypt",
"worksize" : "256, 256",
"lookup-gap" : "2, 2",
"shaders" : "2048, 2048",
"thread-concurrency" : "8192, 8192",
"temp-cutoff" : "83, 83",
"temp-overheat" : "77, 77",
"temp-target" : "65, 65",
"gpu-fan" : "75-100, 75-100",
"auto-fan" : true,
"gpu-engine" : "1000, 1000",
"gpu-memclock" : "1455, 1500",
"gpu-powertune" : "0, 0",
"gpu-memdiff" : "0, 0",
"gpu-vddc" : "1.062, 1.081"

Do it from a command prompt, only needs doing once not neccessary to run them each time.


--gpu-vddc 1.000 looks a likely culprit to me, my 7950's run with 1.100, 1.125 or 1.150

How/where can we set this:
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1

into a cgwatcher profile?

Hi all,

Setting up a 3 x 7950 rig. So far 2,0+ MHash with CGMiner, no problems.
Now I'm trying to set up CGWatcher and I'm encountering a number of weird things. Hoping someone can help me out here.

1) Can't seem to edit my profiles under settings. '(Collection)' cell is grey.
http://s28.postimg.org/67d1jp8nt/Capture.jpg

2) Once I start mining via CGWatcher, it'll tell me one of my cards isn't functioning properly and switches it off.
http://s23.postimg.org/y2492fqnb/Untitled.jpg

3) To top things off, my graphics driver will crash after a few seconds of mining

I don't think I've made any different settings in CGWatcher than in the .bat I use to start CGMiner directly. The latter contains

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer --scrypt -I 15 --thread-concurrency 21712 -w 256 --gpu-powertune 10 --gpu-engine=1125 --gpu-memclock=1500 --gpu-vddc 1.000 -o stratum+tcp://pool1.eu.multipool.us:7777 -u mb0erman.megamine -p x

Profile arguments in CGWatcher are --scrypt --thread-concurrency 21712, rest of arguments are set in config file.

Clarifying my earlier post a bit..

Let's say I have 1 computer which is a pure miner, and 1 which is a normal pc which should lower intensity while someone's working on it. Both have similar graphics cards, and require intensity 13 while mining at full speed. Intensity 11 works for mining while someone's working.

Currently, I'd have to set the intensity to 11 in all my profiles on the work pc, then copy them over to the mining pc and set all intensities to 13. Intensity-while-idle is set to 13 on the work pc. This is a bit of a hassle when the mining pc is slow due to mining and you've got more than 10 profiles set up.

If the intensity-while-idle was changed to intensity-while-busy, this would happen:

I'd have to set the intensity to 13 in all my profiles, copy them to the mining pc and I'd be done.


A simple script could search and replace all intensity: 11 to intensity: 13, of course, but it'd be rather convenient if it could be done with a single setting somewhere. I just spotted an alternative, "start mining" schedule when the computer is idle and "stop mining" action when the computer is no longer idle, but that means I'd lose out on about 25% of my mining speed.


That said, it could be even simpler... perhaps default intensities for work and for idle times could be settable outside the profiles, somewhere in CGWatcher, so that leaving the intensity in a profile blank would have it use the default instead. I don't know why intensity would be per profile, the only common reason to change it would be if you switched from SHA to Scrypt and back, but if it has to be in the profile, you could consider letting it set a work and idle intensity in there too for completeness.


The last option would be ideal, of course. I do hope this post isn't too confusing, but I tried my best to explain what I was thinking.

Disable all but one GPU. Then look to see which GPU's temperature stays high. You should also see that the GPU's load and fan speed will be much higher than the others. That means you found the matching ADL device.

So you have 4 GPUs: GPU0, GPU1, GPU2, GPU3. Disable all but GPU0. Wait a couple minutes, then look at each GPU and find the one with the high temperature. For example, let's say GPU2 still has a high temperature and fan speed while the others don't. That means you need to map OpenCL device 0 to ADL device 2. That mapping would look like this: 0:2

Do this for each GPU until you have the mappings of all four. Then set them in the "gpu-map" config setting, separated by commas. Example:

"gpu-map" : "0:2,1:3,2:0,3:1"

Make sure you remove any gpu-maps you created before doing this, otherwise you may get inaccurate results.

Once you have created the mappings, cgminer should have the correct OpenCL:ADL maps. CGWatcher should pick up the "gpu-map" setting and copy it in its own mapping, but if it doesn't you can use the GPU Map window in CGWatcher (click the link in Devices tab) to map them the same way you mapped them in the "gpu-map" setting.

There are some circumstances where a scheduled action may be ignored. If this occurs the reason is written to the log. If you can email me a debug report (go to Tests tab, click Create Debug Report) and the file called cgwatcher.log in your CGWatcher folder I'll see if I can find a reason they were not triggered.

Look greats

Thank!

I too have noticed that the scheduled events have stopped working.

I deleted all of them and recreated them, yet they do not run.  Specifically the "switch profile to most profitable" event that worked fine for me before.

Any help is appreciated.

Are you sure you mapped the GPUs correctly? In my initial reply, I thought you only had two GPUs, which is why it may not have worked correctly.

You can think of intensity and hashrate as being an OpenCL property, and temperature & fan speed being ADL property. So if the OpenCL device is not mapped to the ADL device correctly, changing the intensity on one may cause it to appear as if the temperature is increasing on another.

For example, we have three GPUs... all the same but for this example we'll call them GPUA, GPUB, and GPUC.

OpenCL lists GPUs in this order

0: GPUA
1: GPUB
2: GPUC

ADL lists them in this order

0: GPUC
1: GPUB
2: GPUA

CGWatcher and cgminer will assume they are both in the same order, because that is the case most often. But in this example, they are not the same. So in cgminer, GPU0 will show GPUA's hashrate and intensity, but it will show GPUC's temperature, clock speeds, and fan speeds. GPU1 will be correct in this example, and GPU2 will show GPUC's hashrate and intensity, but GPUA's temperature, clock & fan speeds.

To correct our example, we would create a gpu-map matching the OpenCL GPU to the ADL GPU:

"gpu-map" : "0:2,1:1,2:0"

This would tell CGWatcher and CGMiner which OpenCL device matches which ADL device, so the temperatures correspond with the hashrate and intensity.

Now I guess it's possible that raising intensity on one causes another to get hotter, but only if the GPU you raised the intensity on also gets much hotter. This is why I think it's more likely that you have incorrect gpu-mapping.

In CGWatcher, you can go to the Tests tab and halfway down there is a drop-down list of utilities and reports. There are two in particular that may be helpful: "Show OpenCL devices" and "Show ADL/NVAPI Devices" (NVAPI is Nvidia's version of ADL). The best way to determine which OpenCL device matches which ADL device is to disable all but one GPU and then watch to see which GPUs temperature does not drop. Then you'll know the GPU with the high temperature matches the OpenCL device you have enabled.

I hope I explained that clearly, but if you have any questions feel free to ask.

Thanks for that long explanation milone. Now, let me explain.

I started with the 2 7990 in a way, but they have now changed place.

I'm currently running like this:

74C 670kh/s I:13
74C 670kh/s I:13
74C 31kh/s I:8
83C 670kh/s I:13

And oddly enough, CGWatcher says 1.34Mhs atm.. was 2Mh/s before.. and I noticed CGWatcher now shows:
- AMD Radeon HD 7900 Series
- AMD Radeon HD 7900 Series
0 AMD Radeon HD 7900 Series
1 AMD Radeon HD 7900 Series

under Devices, as if it doesn't find the gfx card after I tried that mapping you suggested... What is going on here now? CGWatcher only seems to find one card which explains only showing 1.34Mh/s... cgminer and the pool works correctly though... :/

Status: INACTIVE it says...

Anyway, if I change I:8 to I:11 there it will become:
80+C 670kh/s I:13 This one increases in temp like crazy.
74C 670kh/s I:13
74C 100+kh/s I:8 This increases in hash.
83C 670kh/s I:13

So, what is going on here?

Edit: I used the GPU map editor, and had to pick the GPU's in the list there, so now the hashrate is correct in CGWatcher again... Still have that odd heat thing going on where I change intensity of one, and heat goes up on another.. really strange, unless it's because that gfx card generates more heat now, and the other card gets warmer air and heats that one up... Is this correct?


Also, I changed the cutoff to be 90. But it still keeps going... I mean, it stops the hashing, but temp could still keep increaseing for some reason... That is why I'm saying it should stop the mining if the temp is still increasing for ANY GPU!

CGMiner/BFGMiner has three temperature settings for GPUs:

temp-target - temperature miner tries to target by adjusting fans, only if auto-fan is enabled (default 75c)
temp-overheat - temperature at which miner downclocks gpu to try to get back to target, only if auto-gpu is enabled (default 85c)
temp-cutoff - temperature that if reached, miner will disable the gpu (default 95c)

If auto-gpu is enabled, CGWatcher will not provide overheat protection for AMD GPUs since the miner is already doing it. It will provide overheat protection for Nvidia GPUs since the miner does not get Nvidia GPU temperatures. If auto-gpu is disabled, CGWatcher will provide overheat protection for AMD GPUs as well if overheat protection is enabled (in Monitor tab).

*Note: when the miner disables a GPU for exceeding temp-cutoff, it will try to re-enable it once it cools down (to around temp-target) but this often fails. So CGWatcher will watch for this and if a GPU was disabled due to overheating and is now cooled down, CGWatcher will restart the GPU to resolve this. This will occur even if CGWatcher's overheat protection is disabled.

CGWatcher's overheat protection is pretty simple - it adjusts intensity based on temperatures. If temperature exceeds temp-overheat, intensity is lowered until it is back under temp-overheat. If the GPU exceeds temp-cutoff, CGWatcher disables the GPU just like the miner does.

When GPUs aren't mapped correctly, CGWatcher has the GPU associated with the wrong ADL information. ADL is the library to access things like temperature, clock speeds, fan speeds, etc. for AMD devices. This means when ADL device #1 is overheating, CGWatcher will send a command to the miner telling it to lower intensity for GPU #1, but the incorrect mapping means it is lowering the wrong GPU. So where does the miner get its GPU numbers from then? OpenCL. The miner uses OpenCL to hash, and ADL just provides the additional features cgminer has like controlling clock and fan speeds. Both the miner and CGWatcher have to try to match the OpenCL devices to ADL devices, and it isn't always a perfect match. Oddly enough, there are no identifying properties that are in both so it becomes more of a guess than anything else. This is why both cgminer and CGWatcher allow you to customize gpu-map.

Your GPU should not exceed 100c and remain hashing unless you have changed the temp-cutoff to something higher than 100. I don't believe you even have to have auto-gpu enabled for this to happen, but I can't remember at the moment.

If that doesn't make sense, feel free to ask questions I didn't answer clearly.

Oh, care to explain more how this overheat protection works? I've seen temps over 100C, and it's still running, so if I mapped correctly it would do what exactly? How to configure what values are max accepted ones?

2milone.
Thank you very much!
A great piece of software, btw.

CGRemote is in beta opened to anyone who donates $10 USD in cryptocurrency or $15 USD PayPal. I haven't decided on its exact price when finished, but it will be at least this much. All testers will get the final product free for up to 5 miners, more for larger donations. So testers are getting a better deal because I'm counting on them to give feedback and they're trustingv that I'll  finish it (although it does have a lot of functionality already.)

You can read more at http://manotechnology.blogspot.com/p/cgremote.html#joinbeta



Chillance: it sounds like your opencl and adl devices are mapped incorrectly. CGWatcher does have an overheat protection option but the adl devices have to be mapped correctly. Try adding the following to your config:

As arguments

--gpu-map "0:1,1:0"

or in a config file:

"gpu-map" : "0:1,1:0"



SethGecko: start the miner using CGWatcher so it can make sure the api is enabled correctly. You're missing the api-listen argument. Also set the ip address in CGWatcher back to 127.0.0.1.



Dekker3D: I think I understand what you're saying, but the 'Change intensity to X when computer is idle" should work, just set it to the opposite. Set the normal intensity to 11 and the idle intensity to 13, and you have the same effect. Either way, CGWatcher is going to use one intensity when the computer is idle and another when it's not.

Regarding profiles, they are a purely CGWatcher thing. CGMiner has no idea what profiles are... all it knows is the config you tell it (via config file or arguments).

Hello everyone!

I have a problem with CGWatcher.
It just cannot connect to the miner.

Here's what i've tried:
1. Opened cgminer 3.7.2 instance and started CGWatcher. Nothing happened, CGWatcher says Miner is not running.
2. Got to CGWather's settings and set IP address to 192.168.0.91. Both CGWatcher and cgminer are on the same machine. Didn't help.
3. Made sure that API port is 4028 in both cases.
4. Here's how my .bat file's options look like now :

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
C:\cgminer-3.1.1-windows\cgminer.exe --scrypt -o stratum+tcp://pool:3333 -u user.x -p pass -I 19 -g 1 -w 512 --thread-concurrency 15232 --api-network

What do I do wrong? Please help!

I send you an email milone, but I figured I post here to just in case it got lost.

I really love this application, and will donate as soon as I get more coins.

Now, I have 2 HD 7990 that are close to each other (I haven't gotten my extenders yet). Now, with the extenders this might not be much of an issue, but still I think what I'm asking for here would make me (and others feel more safe).

So, as they are close, I noticed that if I increase intensity for one of them, it increased the heat of the other! There is a neat function that will lower the intensity when it's getting too hot, but that won't help in this case, as it's one GPU affecting the other! I'm guessing one card creates heat that the other sucks in...

Another case is if for some reason the driver crashes, and resets the voltage, the heat will also increase a lot. I undervolt mine from 1.2 to 1.050, which gives me better temperatures. However, if the driver crashes, it resets, and as you can imagine, if the voltage is set back to 1.2, and then cgwatcher restarts the mining, temperature will increase fast and reach 100C+ quickly. Not good.

So, what I would really love, is a fail-safe, where CGWatcher will just terminate the mining if a certain temperature is reached. That way, I will feel more safe letting it be on, and restarting the mining. Even after a reboot, as then even if afterburner failed to apply it's setttings for some reason, CGWatcher would take care of it not exploding the card. Disable or turning the GPU off won't help in some cases I noticed (undervoltage not applied correctly I suppose), and that is why I was asking for this TERMINATE MINING feature. Just so it won't blow up anything if something failed.

What say you? Could you add this asap?

Thanks!

One thought: if we could set a non-idle intensity somewhere, we could keep the "normal" intensity set to the max of what a graphics card works well with. That way, the same mining profile could be used for a normal pc and a pure miner.

So, instead of setting intensity to 11 and setting idle intensity to 13 on my normal pc, and setting normal intensity to 13 on my mining pc... I'd just have it on 13 by default on all my pcs and set 11 or d as a "non-idle" intensity on computers that I want to be able to use. That way I don't need to modify every single profile I'd made, I'd just modify a single setting in CGWatcher.

I don't know if the profiles are parsed by CGMiner or by CGWatcher.. if it's CGMiner, I guess there's not much Milone can do about it.