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

Yo guys... Just encountered this issue on 2.9.3 running on Ubuntu 12.04 x86_64:

[2012-11-15 21:09:43] List of devices:                   
 [2012-11-15 21:09:43]    0   Cypress                   
 [2012-11-15 21:09:43] Selected 0: Cypress                   
 [2012-11-15 21:09:43] Error -6: Creating Command Queue. (clCreateCommandQueue) <--- is the debug shits (cgminer -D -T --verbose)

Worked fine until today. Now it refuses to start. Should i try to re-install FGLRX?

Incidently, I'm now running a debug version (stock 2.9.3) on my router. Hopefully the core dump will tell us what's going on.

What if cgminer just queued up the next pool in line, rather than all of them?

With Windows 8 there's a different result for some reason:

Screenshot:

What creating a different type of controller for every combination out there? I'm not even asking for that.

When the temp is below temp-target, don't slam the clock up to max, raise it one step at a time instead, and don't drop the fan fast, lower it one step at a time.

A couple if-statements, and that's it... why complicate it with pretending you'd have to make new algorithms for every card out there?

I know you think I'm stupid, but I'm not THAT stupid.

Believe it or not, this _is_ an issue that the auto-fan and auto-gpu aren't behaving as well as they should be, and all it is, is how fast it adjusts the fan and clock speed. There is NO reason why, just because the temp drops below temp-target minus hysteresis, that the clock speed has to be pushed back up to max, instead of being raised step by step the same as it does as if the temp is within the hysteresis.

-- Smoov

Whatever you can try or think of is most welcome. These latest builds totally disable creating threads for either getting or submitting work, serialising all work of that kind so the idea that it might be due to generating too many threads is basically not the issue here. RtlAnsiCharToUnicodeChar suggests perhaps it's some string function overflow, but that's not very definitive about which one or where...

Creating a PID type controller for every fan/gpu combination out there with different heat generation qualities, different cooling capacities, different fan speed change effects, different fan speed acceleration capabilities, etc. etc. etc....  is basically impossible. As per the the readme, the algorithm is an algorithm designed to work in most places well most of the time with most hardware, and will not get it right occasionally. Since GPUs mining are dead long term, I have zero interest in rewriting the algorithm or developing it further. It won't be long before GPU miners will be the poor relatives that give me nothing for further development when ASICs hit. Sad, since I really liked GPU mining, but that's the reality. Probably best to find some static fan speed workaround in your case.

Probably because cgminer returns a "failure" type return code if the number of shares it mined isn't exact.

Intentional due to other changes, it's clearing the screen and it doesn't update that frequently.

2.9.3 works fine for me in Win7 but when I get into the settings area, there's a 2 second lag. Weird. Older versions did not have this weird lag.

yes but it turns off the prompt for everything.
Change a single value at this point in registry.
HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting
Item is called
DontShowUI
Change to 1
or enabled.
Restart.
Magic it doesn't dick around anymore.

Sometimes Windows (7 x64) thinks cgminer has crashed when I ask it to stop mining after xxxx shares. Perhaps it IS a crash, because it doesn't happen all the time.

here is the latest info:

Cgminer 287 with two cards on my everyday PC. It mined 10001 of the 10000 requested, and it quits normally, but windows thinks it quit unexpectedly. Win pops up a dialog box asking if I want to quit cgminer.  Of course I want to quit... because I have it on a loop.


EDIT: Happened on my new build too... using version 285


I had it mine 10K shares and loop. Has looped a few times, and then this happens.  Wish there was a way to tell windows "it's okay, let it quit/crash and don't worry about it" and my loop would restart it w/o babysitting it.

Yeah I just checked the source now and noticed most of them had already been done.
Not sure if any others were missed, but there are some brackets in linux-usb-cgminer that were missed - in the first part '4)'

I have done this for stuff in

tags, and other text I have surrounded with

 so it doesn't need escaping yet.

But I will continue to work on it.


EDIT: looks like the 
 tags still need its contents to be escaped.  Well, that's an easy fix.  [strike]Working on that right now.[/strike]  Fixed.            

Ok, one of my cards has a fan on it that is dying, but it has given me a chance to observe a behavior in cgminer that, I believe, needs tweaking, when it comes to auto-fan and auto-gpu.

I notice repeatedly, that the temps of my card are fluctuating a lot, and this is why...

I'm using the following options (I was using hysteresis 4, changed it to 2 a few days ago thinking it might do better at holding the temp on card #2 set to 2 instead, didn't work out that way)

"auto-fan" : true,
"auto-gpu" : true,
"gpu-threads" : "1",
"gpu-engine" : "600-825,600-825",
"gpu-fan" : "0-85,0-85",
"gpu-memdiff" : "200,200",
"intensity" : "9,5",
"temp-hysteresis" : "2",
"temp-target" : "70,70",
"temp-overheat" : "80,80",
"temp-cutoff" : "90,90"

What ends up happening, is the #2 card, immediately sets up at 825 engine, 50 fan, upon startup.

Ok... would rather have it start out of the gate at default with 85 fan, but no big deal, it'll find its sweet spot in a few minutes, right? wrong...

There is some lag time between the heat being generated, and the sensor picking it up, so my temp is constantly fluctuating at least 5 degrees.

First, since the temp hasn't risen yet, cgminer starts stepping down the fan. Usually with bigger steps when the temp is below 68. At the same time, the clock is already at 825, and is building up heat. By the time the sensors pick it up, it is raising the fan speed quickly up to 85, at which point the temp is usually over 72-73, and then starts dropping the clock speed step by step to generate less heat.

So far so good. It will make its way, most of the time, all the way down to 600 before the temp starts to come down. The fan speed gets reduced along the way as expected... but when my temp finally drops below 68 degrees, instead of gradually bringing the clock speed back up 1 step at a time like I would expect, it slams it back up to full in one go, from 600-650 directly to 825 again.

Since the temp is still low, the fan speed continues to be reduced, until finally the heat being generated, reaches the sensor, which then starts ramping up the fan again, quickly, as the sensor's temp is rising fast, and the cycle continues, over and over and over again.

These temp fluctuations can't be good at all for the card. Granted, the fan on that card isn't operating as efficiently as it used to, but it is still running, it just doesn't spin as freely as it should. This just gave me a chance to see auto-fan and auto-gpu do its thing over a long period of time.

I have observed my card's temp fluctuate like this for days now, never finding a sweet-spot to settle into, which I would expect it should, since the card does cool down when the engine is at a certain point.

My suggestion would be a change in behavior to auto-fan and auto-gpu...

for auto-fan: allow the fan speed to rise as quickly as it needs to, but never lower it by more than a single step at a time.

for auto-gpu: allow the engine speed to fall as quickly as it needs to, but never raise it by more than a single step at a time.

It should never go directly to the maximum overclock speed, but get there gradually.

Making them adjust more slowly, in the direction that would raise the temp of the card, gives the sensors on the card more time to pick up the heat being built up, since heat isn't an instant indicator, there is some lag time for heat to propogate, but don't limit how fast the card can react when the temp needs to be cut down.

The rationale is, that while the sensor may think the card's chips are at 80-85 degrees that instant, those chips may actually be at 90-95, but that the heat just hasn't reached the sensor yet, giving the chips even more of a pronounced heat/cool cycle than they should.

-- Smoov

You'll need to find any '<' and '>' and replace them with < and >
in:
 API-README
 FPGA-README
 README
 linux-usb-cgminer
 windows-build.txt

Oh, also any '&' with &
 in README and API-README

Hi,

i had the same problems on my Windows system too.
Running a ZTex 1.15x with CGMiner result in the following.



Where do all the HW Errors come from? Its no real problem, the hashrate is shown right on CGMiner and the Pool i am mining on. But its not nice to see these errors counting

Doh! Will fix asap.

EDIT: Fixed

Looks good! Cept the FAQ (point 10) link isn't working.

Hey guys.  I turned the help text files into one HTML help file.

Let me know what you think!

http://test.the47.net/cgminer/readme.html