OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[crazyates]

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

Care to explain how that works?

[os2sam]

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

Care to explain how that works?

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

[crazyates]

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

Care to explain how that works?

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

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

[os2sam]

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

Care to explain how that works?

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

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

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

[Subo1977]

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"

[-ck]

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

Care to explain how that works?

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

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.

[gyverlb]

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).

[-ck]

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).

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.

[bronan]

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.

[os2sam]

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

Care to explain how that works?

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

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.

I think this is the post I was referring to.

https://bitcointalk.org/index.php?topic=28402.msg742189#msg742189

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

[kano]

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.

[ewibit]

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

[rav3n_pl]

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

[crazyates]

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

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...

[ewibit]

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

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

[The00Dustin]

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

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

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.

[rav3n_pl]

kill pgrep cgminer
cgminer -options

[The00Dustin]

kill pgrep cgminer
cgminer -options

is there any way to run cgminer with different configs (night/day) with the scheduler without restarting cgminer?

[JinTu]

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

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

This doesn't meet all your criteria wrt not restarting cgminer, but here is something I whipped up before API support was added:

Code:

#!/bin/sh

export DISPLAY=:0
export GPU_USE_SYNC_OBJECTS=1

while true ; do
 killall -HUP cgminer > /dev/null 2>&1
 now="`date +%Y%m%d%H%M%S`"
 if [ -e "/usr/tmp/mine-high" ];
 then
   echo "Starting cgminer in high mode"
   cgminer --url xxxx --user xxxx --pass xxxx --url xxxx --user xxxx --pass xxxx --auto-fan --auto-gpu --gpu-engine 300-750 --gpu-memclock 150 --gpu-vddc 1.0 --intensity "d,8,8,8" --gpu-fan 30-85 --temp-target 73 -w 256 --text-only 2> /home/jintu/cgminer-logs/run.$now.$$.log
 else
  if [ -e "/usr/tmp/mine-low" ];
   then
    echo "Starting cgminer in low mode"
    cgminer --url xxxx --user xxxx --pass xxxx --url xxxx --user xxxx --pass xxxx --auto-fan --auto-gpu --gpu-engine 300-550 --gpu-memclock 150 --gpu-vddc 1.0 --intensity "d,8,8,8" --gpu-fan 30-50 --temp-target 73 -w 256 --text-only 2> /home/jintu/cgminer-logs/run.$now.$$.log
   fi
 fi
 echo "Sleeping for 10 seconds."
 sleep 10

done

This script fires up automatically when X starts (my miners are setup to autologin).

I also have the following cron config to control when it should be in each mode:

Code:

#Weekdays
0 0 * * mon,tue,wed,thu,fri /usr/local/bin/mine-high.sh
0 12 * * mon,tue,wed,thu,fri /usr/local/bin/mine-low.sh
#Weekend
0 0 * * sat,sun /usr/local/bin/mine-high.sh
0 13 * * sat,sun /usr/local/bin/mine-low.sh

and finally here are the scripts called by cron:

mine-high.sh

Code:

#!/bin/sh
#
rm /usr/tmp/mine-low > /dev/null 2>&1
touch /usr/tmp/mine-high > /dev/null 2>&1
killall -HUP cgminer > /dev/null 2>&1

mine-low.sh

Code:

#!/bin/sh
#
rm /usr/tmp/mine-high > /dev/null 2>&1
touch /usr/tmp/mine-low > /dev/null 2>&1
killall -HUP cgminer > /dev/null 2>&1

[kano]

Step 1:
 ensure --api-listen --api-allow w:127.0.0.1 is set

Step 2:
 Have 2 cron jobs that run at whatever 2 times you want e.g.
  00 23 * * * root /usr/local/bin/cgspeed up
  00 6 * * * root /usr/local/bin/cgspeed down

Step 3: /usr/local/bin/cgspeed (don't forget to chmod +x /usr/local/bin/cgspeed)

Code:

#!/bin/sh
#
if [ "$1" = "up" ] ; then
 echo -n 'gpuintensity|0,9' | nc 127.0.0.1 4028 ; echo
fi
#
if [ "$1" = "down" ] ; then
 echo -n 'gpuintensity|0,d' | nc 127.0.0.1 4028 ; echo
fi

... I haven't tested it but it looks OK

Also, if your linux doesn't have 'nc' it may be called 'ncat' or 'netcat'

Lastly if you don't want the email status messages sent to root twice a day, then make the echo lines look like:
  echo -n 'gpuintensity|0,d' | nc 127.0.0.1 4028 &> /dev/null on the end of each 'echo' line