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

kill pgrep cgminer
cgminer -options

I'm guessing you could use something like curl in cron to do this via the API, but you'd have to figure it out yourself unless someone else chimes in with specific instructions.

thx
no I mean it automatically every day in Linux...

If you're in Windows, you could make a .bat file with a IF statement inside a loop, that compares the time, and then starts your miner with different configs. Then have a 2nd very simple batch file on a loop that kills CGMiner every 10800 seconds (3 hours). I ran like this for a while, but for a different issue. Not a very clean way of quitting CGMiner, but it works...i guess...

Just use console to change it in the fly
G I D
G I 9

hi
is there any way to run cgminer with different configs (night/day) with the scheduler without restarting cgminer?
eg:
night 11:00 PM:  -I 9,9
day   06:00 AM: -I d,9

TIA

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.