Hacking The KNC Firmware: Overclocking

[lenny_]

gminer3.8.5 didn't do it this time. using 3.9.0.

Here it is. 305 is the code. Don't change the last digit. If you want more, start increasing 315 325 335 345 etc, until 3F5, after that 405 etc. I havent tried past 345.

If you want less use 2F5, then 2E5, then 2D5, 2C5 etc.. going down.

When chancing the value at cgminer.sh start always with /etc/init.d/cgminer.sh.

Ok mate but where to put that code? November devices have completely different cgminer.sh file.

[1714133056]

1714133056

[1714133056]

1714133056

[1714133056]

1714133056

[1714133056]

1714133056

[1714133056]

1714133056

[temen]

I think the asic is not warming up as much as the vrm's. Tried it by hand, vrms u couldn't even keep your finger on for a moment but on asic heatsink you can=)

Someone asked that november devices have different file. It's true, and you have to copy that cgminer.sh file from this thread some post's back.

Same commands apply I think.

There's this 0x86 line that you want to find.

It's been explained quite a few times so read back those posts, because somebody did tutorial on how to do this.

Myself i have copied that cgminer.sh from the thread to /config/cgminer.sh and there it survives reboots. Then after reboot i copy this to /etc/init.d/cgminer.sh.

And if you don't do any modifications to hardware its quite impossible to achieve this.

My saturn is on floor level, sucking cool air. If I lift it to desktop height it starts to show fault 4. So it's on the edge.

[lenny_]

I think the asic is not warming up as much as the vrm's. Tried it by hand, vrms u couldn't even keep your finger on for a moment but on asic heatsink you can=)

Someone asked that november devices have different file. It's true, and you have to copy that cgminer.sh file from this thread some post's back.

Same commands apply I think.

There's this 0x86 line that you want to find.

It's been explained quite a few times so read back those posts, because somebody did tutorial on how to do this.

Myself i have copied that cgminer.sh from the thread to /config/cgminer.sh and there it survives reboots. Then after reboot i copy this to /etc/init.d/cgminer.sh.

And if you don't do any modifications to hardware its quite impossible to achieve this.

My saturn is on floor level, sucking cool air. If I lift it to desktop height it starts to show fault 4. So it's on the edge.

You saying - just copy October cgminer.sh file to November device? Will it work just straight out of the box?
Can you paste your file with description, which frequencies you've been using on November device?

[temen]

Don't know what frequencies are you talking about ?=)

I don't have any other tuning capability than bertmod which I was unsure to install at first. I can't change any frequencies, is there TUNING-mod for november devices?

Here is the file I am using:

--- start of file ---


TH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

use_bfgminer=
if [ -f /config/miner.conf ]; then
        . /config/miner.conf  #if bfgminer is enabled, this file contains: use_bfgminer="true"
fi
if [ "$use_bfgminer" = true ] ; then
        DAEMON=/usr/bin/bfgminer
        NAME=bfgminer
        DESC="BFGMiner daemon"
        EXTRA_OPT="-S knc:auto"
else
        DAEMON=/usr/bin/cgminer
        NAME=cgminer
        DESC="Cgminer daemon"
        EXTRA_OPT=
fi


set -e

test -x "$DAEMON" || exit 0

do_start() {
        # Stop SPI poller
        spi_ena=0
        i2cset -y 2 0x71 2 $spi_ena

        good_ports=""
        bad_ports=""

        # CLear faults in megadlynx's
        for b in 3 4 5 6 7 8 ; do
                for d in 0 1 2 3 4 5 6 7 ; do
                        i2cset -y $b 0x1$d 3 >/dev/null 2>&1 || true
                done
        done

        for p in 0 1 2 3 4 5 ; do
                i2cset -y 2 0x71 1 $((p+1))
                good_flag=0
                ar="$(spi-test -s 50000 -OHC -D /dev/spidev1.0 0x80,3,0,0,0,0,0,0 | tail -c 13)"
                if [ "x$ar" = "x00 30 A0 01" ] ; then
                        good_flag=1
                fi
                ar="$(spi-test -s 50000 -OHC -D /dev/spidev1.0 0x80,2,0,0,0,0,0,0 | tail -c 13)"
                if [ "x$ar" = "x00 30 A0 01" ] ; then
                        good_flag=1
                fi
                ar="$(spi-test -s 50000 -OHC -D /dev/spidev1.0 0x80,1,0,0,0,0,0,0 | tail -c 13)"
                if [ "x$ar" = "x00 30 A0 01" ] ; then
                        good_flag=1
                fi
                ar="$(spi-test -s 50000 -OHC -D /dev/spidev1.0 0x80,0,0,0,0,0,0,0 | tail -c 13)"
                if [ "x$ar" = "x00 30 A0 01" ] ; then
                        good_flag=1
                fi

                if [ "$good_flag" = "1" ] ; then
                        good_ports=$good_ports" $p"
                else
                        bad_ports=$bad_ports" $p"
                fi
        done

        if [ -n "$good_ports" ] ; then
                for p in $good_ports ; do
                        # Re-enable PLL
                        i2cset -y 2 0x71 1 $((p+1))
                        for c in 0 1 2 3 ; do
                                cmd=$(printf "0x84,0x%02X,0,0" $c)
                                spi-test -s 55000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
                                cmd=$(printf "0x86,0x%02X,0x03,0x05" $c)
                                spi-test -s 55000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
                                cmd=$(printf "0x85,0x%02X,0,0" $c)
                                spi-test -s 55000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
                        done

                        # re-enable all cores
                        i=0
                        while [[ $i -lt 192 ]] ; do
                                i2cset -y 2 0x2$p $i 1
                                i=$((i+1))
                        done
                        spi_ena=$(( spi_ena | (1 << $p) ))
                done

        fi

        if [ -n "$bad_ports" ] ; then
                for p in $bad_ports ; do
                        # Disable PLL
                        i2cset -y 2 0x71 1 $((p+1))
                        for c in 0 1 2 3 ; do
                                cmd=$(printf "0x84,0x%02X,0,0" $c)
                                spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
                        done

                        # disable all cores
                        i=0
                        while [[ $i -lt 192 ]] ; do
                                i2cset -y 2 0x2$p $i 0
                                i=$((i+1))
                        done
                        spi_ena=$(( spi_ena & ~(1 << $p) ))
                done
        fi

        # Disable direct SPI
        i2cset -y 2 0x71 1 0

        # Enable SPI poller
        i2cset -y 2 0x71 2 $spi_ena

        start-stop-daemon -b -S -x screen -- -S cgminer -t cgminer -m -d "$DAEMON" --api-listen -c /config/cg
}

do_stop() {
        killall -9 bfgminer cgminer 2>/dev/null || true
}
case "$1" in
  start)
        echo -n "Starting $DESC: "
        do_start
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        do_stop
        echo "$NAME."
        ;;
  restart|force-reload)
        echo -n "Restarting $DESC: "
        do_stop
        do_start
        echo "$NAME."
        ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0

--- enf of file ---

line you want to edit:

cmd=$(printf "0x86,0x%02X,0x03,0x05" $c)

Where the number 3 is the first digit, an 05 are the last digit. Those i have changed. I put 55000 on spi-test dunno why.  I think it's just the speed of that command on spi line?

so if you want to change to 295 you would write:

cmd=$(printf "0x86,0x%02X,0x02,0x95" $c)

Voila!

Donations accepted=)

[temen]

Dont know if that is for october or november, but it works for my november =)

My firmware is 0.99.1-e, I tried 0.99.2-e but I didn't like.

Of course everybody should ask themselves if they are willing to risk the loss of asics, this is not some light consideration to do!

There might be risk of fire hazard etc. so use caution and common sense.

[complang]

With a good PSU there should not be any risk of any outages than that the rig is just dying. But otherwise I agree with you.
Crazy shit you are running there

[jelin1984]

You mean you overclocked the November Jupiter
At which hashing speed?

[giletto]

Dont know if that is for october or november, but it works for my november =)

My firmware is 0.99.1-e, I tried 0.99.2-e but I didn't like.

Of course everybody should ask themselves if they are willing to risk the loss of asics, this is not some light consideration to do!

There might be risk of fire hazard etc. so use caution and common sense.

At how much Ghash your november Jupiter run now?

[CeeCee]

@giletto and jelin
just look at page 24 the last 6-7 posts

[giletto]

Maybe i am blind, but i can't found anything about november jupiter hashing speed from 650Gh/s before OC up to XXXGh/s after OC? 

[CeeCee]

he has a saturn and its working at ~459GH/s so you can double this for a jupiter to ~920GH/s.
you can see this here: https://bitcointalk.org/index.php?topic=313978.msg4620979#msg4620979

and here he describes what you should do to overclock it:
https://bitcointalk.org/index.php?topic=313978.msg4621190#msg4621190

[temen]

I let it run a day on 430gh/s and amps were down to 24 A on 2 vrm's. Rate was also something like 421gh/s. No disabled cores, or fault codes on vrm:s. They are starting to take the hit I think =)

Now back to 460gh/s and everything seems fine. Im going to let it be at this for now and see if amps start to creep down.

Somebody had a picture that the temp sensor is actually one component on the asic board. My low 47 degrees celsius temps are somehow wrong as vrms are burning hot. It's the airflow that makes this like it is.

I searched for some oil immersion hardware but there isn't much "ready" made stuff. One option would be big hydraulic oil tank like on big construcion machines, different sizes and you can bolt the top shut so it wont spill (at least not much) even if topped over. And there is place for pump on the bottom, atleast somekind of outlet. Perhaps I will try this next but space is limited and this might not be option=(

[complang]

24A?
Found a way to reglate voltage?

[temen]

That affected amps on 1 asic, I think 1 die was behaving somehow strangely. One reason could be that if those vrms have after all some protection circuitry enabled then it would be just "emergency" shutdown happening. Those bmr464:s can be configured to go on with fault forever or for time that is programmable. But I didnt see any error codes so dont know what happened.

It it did that again with no mining-power loss it would be great but I think it affected it.

Now I have been using 325 for 2 hours, and my amps are between 33-34 per vrm. Total power 440watts, hashing at

cgminer version 3.9.0 - Started: [2014-01-21 17:46:57]
--------------------------------------------------------------------------------
 (5s):482.1G (avg):478.9Gh/s | A:250900  R:231  HW:369  WU:6690.7/m
 ST: 2  SS: 0  NB: 3  LW: 271605  GF: 0  RF: 0
 Connected to multiple pools with block change notify
 Block: 24b775a5...  Diff:1.79G  Started: [18:23:42]  Best share: 2.92M
--------------------------------------------------------------------------------
 [P]ool management [S ettings [D]isplay options [Q]uit
 KnC 0:                | 478.3G/479.1Gh/s | A:250900 R:231 HW:369 WU: 6692.6/m
-------------------------------------------------------------------------------

 Mean speed 479GH/s at the time.

(had to remove mark ] after S-settings because it caused line that draws over text, in case some wonders that)

EDIT: Nobody knows how to set core voltages on november device?!

[complang]

I wonder how high it will be able to go. I mean, did KnC underclock those chips or did they take a VERY safe value of clock?
A 100% overclock should not be possible imo
I'm running 295 atm, hashrate bumping between ~380-400 avg 389.
Starting to get a little bit scared for my 700W PSU when Bert reports 375W (thats way lower than actual power usage at wall).

[temen]

Perhaps these late november devices ( i got myself something like 12 december! ) have different kinds of asics than the previous. Or would they all be same.

I recall hearing that one knc blew up in early batches and also that the asic board might not be able to handle the heat generated. I (in my previous life) had something to do with pcb (simple pcbs) design and even then it was allowed to use full copper areas on pcb layout because that could cause explosion. It had to be "nettd" or dotted pattern etc.

Its best that they are having margins because it is great product and you wouldnt want to have good reputation gone bad by asics dying prematurely or other problems.

The heat is the culprit damn it. I think those bm464 modules are "stackable".. =) ( Im not sure about this ) But this way load could be halved per vrm.

[giletto]

he has a saturn and its working at ~459GH/s so you can double this for a jupiter to ~920GH/s.
you can see this here: https://bitcointalk.org/index.php?topic=313978.msg4620979#msg4620979

and here he describes what you should do to overclock it:
https://bitcointalk.org/index.php?topic=313978.msg4621190#msg4621190

Theory =/= practice. I heard that the november batch jupiter are not possible to OC...and if he or anyone don't OC a jupiter from nov with 650Gh/s i would not test it at first.

[complang]

Margins, yes but 100% (or even more?).

Why wouldn't nov jupiter be OCable when nov saturns are? I call that bullshit till the opposite is prooven

[ImI]

Margins, yes but 100% (or even more?).

Why wouldn't nov jupiter be OCable when nov saturns are?

why do you assume that they arent?

[ncs0ne]

thx for sharing temen!

My experience on a November Jupiter with 305 is so far that it works for one board, avg is >700 and temperature is 80+
Enermax 1500W PSU seems not to be sufficient as it is shutting off when I overclock all 4 boards and cgminer starts putting work on them.

I'm running stable at 2B5 and 2C5 with max temperature up to 80 °C and reaching with this ~830GH/s
I'm using "spi-test -s 50000" not the 55000 Mhz value, btw.

I'll leave it for good now and keep watching