Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 571. (Read 5806088 times)

Check the debug log file.  Sometimes ADL does return -1 from fan speed/temp APIs.  I've had people reporting it with 6000 series cards (not cgminer, my akbash watchdog) BTW, -1, is "Most likely one or more of the Escape calls to the driver failed".

Not sure why, maybe it is "not always supported" (as their ADL docs says) ?!?. I raised this issue with AMD support. Waiting for their response.

Not sure how re-order would help, ADL APIs use adapter index, not opencl gpu #.

What should temp-cutoff and overheat be to avoid card throttling down in speed?

I have watercooling and want the app to shutdown if core reaches 60c.

I found this in my cgminer.cfg
"temp-cutoff" : "95",  This I put to 60c
"temp-overheat" : "85",  This I can keep at 85?
"temp-target" : "75",     This I can keep at 75?
^^^^^^^ There is no fans controlled by GPU, it's radiator with fans.

So MAX temps on my 7950 is: Core MAX 52c, VRM MAX 65c.

I'm assuming just changing the  "temp-cutoff" to 60 and hysteria at 3 and not changing other stuff incase of waterpump failure the GPU once it reaches 63c will turn off the mining then?

Unlucky to hit save at that moment, but yeah, possible. Not so sure that's something to worry about.

Just an idea/suggestion anyway.

However, if your main pool has a temporary outage, then it may be moved from the top position.
So it would have to take that into account also ...

Another this I've noticed:
When you change the priority of a pool to the top (via the API) and you save the config file, the order of the pools in the config file remains unchanged from is original. Maybe this should change to match the current priority order?

Finally got around to sending those cents.  You should see them in the next block.  Thanks again for the great contribution to the community.  I'd send more if I was richer.

You can read from SSDs almost indefinitely without causing wear.  It's the writing that causes problems.

So by doing a level 1 read across the drive, you're forcing the wear logic to realize failing sectors are having problems, which it then swaps out to a spare one.

Steve's words:


from: https://www.grc.com/sn/sn-343.pdf

I'm not even sure how that would make sense?

Actually, I read recently that spinrite level 1 is read only, and can work wonders on SSDs. 

I heard -haven't tried- that it doesn't quite work as expected on balancing.  I use it for failover only.

Please take a good look through the readme, and read carefully the extensive documentation on the advanced option --gpu-map.

The lack of RPM for the one 5970 has to do with how it died. The GPU that failed was the one closest to the output, so this card isn't capable of outputting an image, or controlling/reporting on fan speed. The fan is just always pegged at 100.

I tried --gpu-reorder, and it did organize them in a more logical layout but it doesn't fix the problem.


Here, I changed the core of the single GPU 5970 to 200MHz and the voltage to 0.950V. The hashrate dropped on GPU2, but the corresponding drop in temperature happened on GPU3.

Although in my experience, it was only necessary when I used Windows. So far it's been accurate without that flag on Ubuntu.

No, I haven't. What does the flag do?

Have you tried using the --gpu-reorder flag?

Has anyone else noticed that the order of temperatures and fan speed is incorrect sometimes? For instance, this is a rig with 3 cards; a 6870, a 5970 and a 5970 with one bad GPU.

GPU 0 is the 6870, the one with the exceedingly low temperature and no fan speed is the one with the bad GPU.
The GPU order corresponds with what I see in clocktweak.
Reading data:
Adapter#:0 Temp:75 Load:99 Fan:67 Level:2   CoreL0:250 CoreL1:399 CoreL2:900 MemL0:198 MemL1:799 MemL2:800 mVoltL0:950 mVoltL1:999 mVoltL2:1150
Adapter#:3 Temp:62 Load:99 Fan:NA Level:2   CoreL0:250 CoreL1:500 CoreL2:750 MemL0:198 MemL1:199 MemL2:200 mVoltL0:950 mVoltL1:999 mVoltL2:1000
Adapter#:4 Temp:43 Load:99 Fan:NA Level:2   CoreL0:157 CoreL1:399 CoreL2:750 MemL0:198 MemL1:199 MemL2:200 mVoltL0:950 mVoltL1:999 mVoltL2:1000
Adapter#:5 Temp:60 Load:99 Fan:86 Level:2   CoreL0:157 CoreL1:400 CoreL2:750 MemL0:198 MemL1:199 MemL2:200 mVoltL0:950 mVoltL1:999 mVoltL2:1000

In this case, I changed the clock speed on the 5970 with only one GPU (Adapter #4) to 400MHz, and as you can see the hashrate of GPU1 when down instead of GPU2.

It's not just this configuration of cards either, I've noticed this before with 4 GPUs in the system but the cards in different orders.

It sounds like it tries to balance the work equally, but I haven't tested it out myself to see how it works.

How accurately would it load balance between the pools?

OK, I have a few issues I would like to raise. Now I would look at these myself, but I just don't have the time to analyse/learn the code and do the work myself. I am still looking at it, it's just going to take me some time...

1. If a config file is specified in the cmd line, don't attempt loading from the default location, even if the file specified is invalid. Only attempt to read from the default location if no file is specified.

2. To save a file via the API, a blank parameter (Null text), indicates that the loaded file should be updated... It should save to the file which it uses, whether that's the file specified in the cmd line, or the default location. (Kano is looking into this, I think?).

3. For the BFL (and possibly the other FPGA), when the unit is disabled, either by the user or fault, the worker thread should not be terminated. Comms with the device should be maintained for (at least) 2 reasons:
a) To update the state of the device, Alive or dead etc: no comms attempts means we don't know.
b) To update the temps of the device: no comms mean we can't ask for the temperature.
Disabling the device should just stop new work being sent to it.

4. For the BFL (and possibly the other FPGA), if a device dies and a re-enable request is sent, the device should be re-initialised.
I found that when a BFL throttles, CGminer would report it having zero hashes and disable it. Hitting re-enable didn't do anything, but restarting CGminer would bring it back to life. This suggests the BFL just needs re-initialising.

Also,
I see that when work is submitted to the BFL, it waits 4500ms then start's polling at 10ms intervals for work. I think there should be a timeout at maybe 10s (BFL say that work should take 5.125s so 10s is ample) when the BFL is declared sick, and is re-initialised.