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

People seem to miss that 'random' element of U: often.
You can't expect U: to do anything quickly of course
(nor can you expect it do anything with any real precision)

Basically a few days should start to converge on the expected U: value
(and maybe an hour to be within about 10% for most hardware in the 300-800MH/s range)

I guess one of the statisticians could work that out as a function of MH/s where it would be within say > 99% or even > 99.9% confidence ...
But from experience those numbers I've said ... seem ... to be close to reality.

I think this is the post I was referring to.

https://bitcointalksearch.org/topic/m.742189

When I was doing this I did find a spot where my Utility increased and obviously my hashrate increased too.  Funny how the minds eye works sometimes
Sam

Hey ckolivas
I posted my hardware and config file earlier, but non gave a suggestion nor an answer.
But before i read your post about the readme, i took an old batch for testing which had a small difference with my normal config file
my dual 7970 cards run for a long time fine with 750 core / 800 mem mhz speed this because our country has one of the highest energy price worldwide due to extreme taxes.
Anyway the old batch was as follows :
-I 7 --verbose --gpu-engine 800 --temp-target 75 --temp-cutoff 95 --temp-overheat 80 --gpu-memclock 800 --debug -T 2>logfile.txt

Now here comes the thing i do not understand the 2.4.3 runs fine with the settings earlier provided but here i post them again :

"intensity" : "7",
"gpu-engine" : "750",
"gpu-memclock" : "800",
"temp-overheat" : "85",
"temp-cutoff" : "95",
"temp-target" : "75",
"failover-only" : true,
"gpu-threads" : "2",
"retry-pause" : "5",
"scan-time" : "60",
"worksize" : "256",
"expiry" : "120",
"vectors" : "2",
"algo" : "auto",
"queue" : "1",
"log" : "5"

Believe it or not the difference is the 50 mhz lesser clock on the core which causes cgminer to crash with 2.4.4 and 2.5.0
Nevertheless i might miss a error or another reason for the fail, ofcourse you could says keep it running at 800 core but that would actually produce a lot of heat and ofcourse bigger usage on the meter.

Hardware errors would easily reveal this being a problem though. I would definitely advise to keep clocks below a level where HW errors start appearing. If you're not getting HW errors, there is no real mechanism for a lower utility at a higher hashrate.

I guess theoretically it may be possible that there's an overclocking zone where the GPU doesn't freeze but doesn't compute the hashes correctly either and misses some shares (an error occasionally flipping one bit of the resulting hash to 1 even if it should be a 0 could reduce the utility while being undetectable by the miner software).

Even if possible I suspect this isn't very common : the error must be located in the last stage of the sha256d computation and only affect high bits to exhibit this behavior and not a simple hardware error as detected by miners (where a share candidate doesn't pass the software-only check). I don't know enough about OpenCL to guess if the way the OpenCL compiler works may make it more probable though (hash results may end up in registers/memory cells statistically more prone to errors for example).

I did not ever say that. I said there are certain engine/memory clock combinations where the hashrate rises more than linearly with engine clock speed with the unorthodox kernels like phatk. Utility is hashrate * random luck and it should just be linearly related to hashrate.

Question about Config file:

Can i set up -g and -I for each Pool in the configfile
for example  for the pool at slot 0, "-g 1" AND "-I 7", for pool at slot 1, "-g 2" AND "-I 9"

After I found the clock that produced a higher Utility I ran it there for a while.  So yes.  Right now I'm back to running stock clocks since I'm running the AC.
Sam

And you verified this over a 24-48 hour period to negate any U variances, right?

No,I can't explain how that works, but, ckolivas posted a suggestion a while back.

He said that once you find your max GPU Engine clock that your card runs stable at try to drop your GPU clock 5Mhz at a time to see if there's a sweet spot where your Utility increases.  I tried that and I did find a spot where my Utility went up a little at a lower GPU Clock.

Maybe ckolivas could elaborate on that?
YMMV,
Sam

Care to explain how that works?

Sometimes,also, with a lower overclock setting and lower hashrate you will get a higher Utility.
Sam

Well of course a lower overclock will get you lower hashrates. What he's saying is that CGMiner at a 920MHz OC might be equal to another program at a 940MHz OC.

Not in my case. Overclock down — less Hashrate.

It would be great if author would make autorestart programm, after driver crash in next version of Cgminer.

Correct; I get the same when the AMD driver crashes and recovers. Quitting Cgminer and restarting it will allow you to start mining again.

Back off on your overclock a bit. Cgminer pushes your cards a bit harder than some other miner programs, and you can usually achieve the same or better hash rate with a lower overclock.

I'm pretty sure I get this when the video driver crashes and the OS recovers it. 

M

GPU Radeon 5870 Eyefinity 2Gb
Core 1010Mhz Temp.~68C

Perhaps overclocking, but I mine the year at this frequency using the Phoenix and there are no problems. I want to use CGMINER but I have this problem since version 2.4.0

#define CL_OUT_OF_HOST_MEMORY -6
What does this mean?

Part of My config file

#define CL_OUT_OF_HOST_MEMORY                       -6

Dunno what you're doing to suffer that. Probably too high intensity and/or worksize or something else...

http://img12.imageshack.us/img12/6288/36375924.png

Tell me how do I fix this?

windows 7 x64, version 2.5.0

No, I'm pretty sure the ztex bug  is a different thing.