Hacking The KNC Firmware: Overclocking

[pedrosoft]

45 degrees fans = best performances and best hashrate. thanks ! how many watts ( psu )251 setting requires ?

[1714137382]

1714137382

[1714137382]

1714137382

[crashoveride54902]

well i did put heatsinks on my vrms...IDK how it lowered the temp but it did...I saw 5c or so lower temps w/o changing anything...i try the 45 degree fan method too..but i was doing that before n after heatsinks so that wasn't the change in temp...and one module didn't even have a vrm fan on it so just with the heatsinks it droped...

Think i might try removing the stock hsf as i saw you can get a better fan placement on there...i just have mine proped up on the black shroud

[captain-v]

"What temps do you get on the chip itself? From the web interface and from your readings?  And what hash rate do you get per board?
If there is a better way to cool the down side of the VRMs, we'd be able to achieve better performance, any ideas?"

@Redbluebg
Well OC 231 in the ~23C ambient on stock settings WI ASIC temps are below 48C ( w/ ~175W DC, ~165 GH/s per ASIC, 1.23W per GH/s  and ~2.5% Reject + HW ...)

At this time I think forced air is most practical method to cool the VRMs. And it would be good to keep them dust free with brushes and pressurized air. Also keep/aim away the PSU so it doesn't blow hot air near the miner. I am direct driving with the PSU (HX750) cables to save on power loss and heat generation on the miner cables.

Immersing VRMs in oil bath (in synthetic Mobil1  0-20W ) may be an alternative for some of us but not sure if it will accomplish much...

BTW, I thank to all those who help opening the KNC OC doors to us

[CYPER]

And it would be good to keep them dust free with brushes and pressurized air.

+1
Yesterday I cleaned one of my Jupiters and temps fell 10 degrees.
Inside it looked like a dust bomb has exploded. I used a painting brush with long and soft bristles to wipe everything, even between the fins of the cooler and the fan blades while sucking everything with the vacuum cleaner at the same time. It took me around 30 minutes for a good deep clean.
I have to clean all the others soon, but I hate to turn them off.

[mekadeka]

Im running cgminer wizkid 3.8.5 with november 0.99.1 firmware and bertmod.

Temen, how does one put wizkid's version of cgminer in place? I looked around for an answer, but I am unclear.
Thank you.

[idee2013]

Hi everybody, waiting for donations  

please use bertmod to see individual vrm stats.

Please keep in mind that i put the front blowers to different place, they aim straight to boards themselves. I also removed the bent-metal part that supplies airflow to beaglebone. Don't know if this has any effect on beaglebone in the long run. I put heatsinks on vrms, took the yellow tape off, cleaned with cleaner + acetone and put arctic silver thermal adhesive, as I didnt want to risk heatsinks "moving" and falling of from vrms. Temperature sensor wont give you correct reading, you can only watch if faults start to appear on vrm's.

Im having one issue at the moment, current readings from other asic have started to fall down. Hashing drops some, but not quite that much.

Yesterday I started to reverse engineer VRM voltage setting, but didnt have guts to try anything yet. On BMR464 manual it says that the output "master" voltage is set with resistor, but you can go like 15% higher by accidently issuing wrong command. Hope that this doesnt kill the asic=)

Im not to blame if it dies, please remember!

Thanks again. You'll receive a donation from me soon for sure  
Hope others do so as well, because without your balls risking to blow up an asic we still wouldn't know about it.


Ok, did some further testing and measurements.

Notice please, case was off otherwise I'm not able to measure temps.
And I've used an infrared pistol, maybe I can borrow another thing which I can put directly on tiny parts to measure temps.

Standard clock-settings:
859W at the wall
67°C for those tiny blocks next to the voltage regulators
80°C for the voltage regulators (yellow area)
cores in the web-gui stats up to 53°C

no big diff between boards

Code:

DC/DC ID 	ON/OFF 	Status 	Input Voltage 	Output Voltage 	Output Current
0 	OFF 	OK 	11.8 V 	0.829 V 	25.2 A (20.9 W)
1 	OFF 	OK 	11.8 V 	0.829 V 	25.4 A (21.1 W)
2 	OFF 	OK 	11.8 V 	0.827 V 	25.3 A (20.9 W)
3 	OFF 	OK 	11.9 V 	0.828 V 	25.4 A (21 W)
4 	OFF 	OK 	11.8 V 	0.83 V 	25.4 A (21.1 W)
5 	OFF 	OK 	11.8 V 	0.833 V 	25.1 A (20.9 W)
6 	OFF 	OK 	11.8 V 	0.83 V 	24.8 A (20.6 W)
7 	OFF 	OK 	11.8 V 	0.829 V 	24 A (19.9 W)

Modified clock-settings:
1098W at the wall
70°C for those tiny blocks next to the voltage regulators
90°C for the voltage regulators (yellow area)
cores in the web-gui stats up to 66°C

For the overclocked one bertmod showed after some time several 'FAULT 4' for the two boards in the back, nevertheless it was hashing very nice.
No clue what this means.

Code:

0 	OFF 	FAULT 4 	11.7 V 	0.819 V 	30.8 A (25.2 W)
1 	OFF 	OK 	11.6 V 	0.82 V 	30.7 A (25.2 W)
2 	OFF 	FAULT 4 	11.7 V 	0.822 V 	31.5 A (25.9 W)
3 	OFF 	OK 	11.8 V 	0.824 V 	31.4 A (25.9 W)
4 	OFF 	OK 	11.7 V 	0.821 V 	30.1 A (24.7 W)
5 	OFF 	OK 	11.7 V 	0.821 V 	30.2 A (24.8 W)
6 	OFF 	FAULT 4 	11.7 V 	0.823 V 	30.7 A (25.3 W)
7 	OFF 	FAULT 4 	11.7 V 	0.821 V 	31.3 A (25.7 W)

BMR series offers a nice feature, btw: "Over temperature protection"
http://www.ericsson.com/ourportfolio/products/bmr464-series


Aaaaannd....here's what you all had been waiting for, I guess.
Gives me peaks in the pool over >850

Keep in mind the usual stuff: donate a little to temen, warranty void, blow-up risk, ..

Code:

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

use_bfgminer=
if [ -f /config/miner.conf ]; then
        . /config/miner.conf  
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
echo "k";
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 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
				                cmd=$(printf "0x86,0x%02X,0x02,0x85" $c)
				                spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null 
				                cmd=$(printf "0x85,0x%02X,0,0" $c)
				                spi-test -s 50000 -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/cgminer.conf $EXTRA_OPT
}

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
	echo "cooling down for 60s.."
	sleep 60 #let it cool down!
        do_start
        echo "$NAME."
        ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0

which part of this code is swithing the power of the other 4 vrms of the 8 vrms on? i have 3x boards with 8 vrms and 1x with 4 vrms (after a rma).
Is it possible to use the same code for 8 and 4 vrms asics for october jups but with 251 setting instead ?

[temen]

@mekadeka: wizkid you can get like this, instructions were on kncforum posted by bitbuster, didint find the link but here are instructions, you need to ssh to the miner first and grab control of the miner with screen -dr:

q
wget http://vpn.wizkid057.com/nas/cgminer-binary-wizdev20131222
chmod +x cgminer-binary-wizdev20131222
screen -dm ./cgminer-binary-wizdev20131222 -c /config/cgminer.conf
screen -d -r

My experience is that when applied same setting this version gets better hashrate on console and little bit less current consumption BUT on the poolside It's always less than with cgminer 3.9.0. Dont know if its issue with pool or what. On the other hand I have seen with 3.9.0 on the poolside even more hash-speed than it shows. Like if cgminer shows 459gh/s, poolside it sometimes as high as 488gh/s. This is with 3.9.0. Of course there is some variation.

For me setting 305 seems to be absolute STABLE maximum. With higher settings either one die or one vrm fails. Dont know which it is because don't have advanced tuning.

I fiddled some more with this clock divider. Setting 606 works for me, it gets around 450gh/s. 777 works somehow. The most control is with this xx5 range. With this you can set everything in small steps.

Waiting for donations xD

[padrino]

For me setting 305 seems to be absolute STABLE maximum. With higher settings either one die or one vrm fails. Dont know which it is because don't have advanced tuning.

Can't you see what failed with bertmod? Maybe you can't do anything about it without advanced tuning but perhaps see if it's temperature related (FAULT 4, etc.)

[idee2013]

For me setting 305 seems to be absolute STABLE maximum. With higher settings either one die or one vrm fails. Dont know which it is because don't have advanced tuning.

Can't you see what failed with bertmod? Maybe you can't do anything about it without advanced tuning but perhaps see if it's temperature related (FAULT 4, etc.)

do i understand it right. 305 ist only for november units?

[pedrosoft]

For me setting 305 seems to be absolute STABLE maximum. With higher settings either one die or one vrm fails. Dont know which it is because don't have advanced tuning.

Can't you see what failed with bertmod? Maybe you can't do anything about it without advanced tuning but perhaps see if it's temperature related (FAULT 4, etc.)

do i understand it right. 305 ist only for november units?

Same question

[mekadeka]

do i understand it right. 305 ist only for november units?

Same question

There is something quite different about the November Saturns, IMHO.

To me, it seems the answer has to be yes, only November. I have an October unit. Last night I tested a number of different variables used on Temen's version. The biggest fault in my test is that I could not let each test run for more than about 6-10 minutes. This might or might not be long enough to determine if a given configuration will *eventually* become a faster hash rate. I have not tried Temen's full configuration yet (including bertmod), but I did do Temen's speed 305.

So far, for my October machine, the fastest has been cgminer 3.9.0 and 211. I also threw on three additional case fans placed in the middle of the case (just standing there, not affixed right now) and blowing directly on the chips. This drastically reduced my temps from mid/high 60s to mid 40s.

Things I tried with my October unit that didn't seem to be faster (but tests might not have been long enough):

1. Tried Nov-only FW 0.99.1-e with 305. Just a shot in the dark that didn't do much.
2. Tried 251, 231 with I think 99 and 99-tuning. I don't think these were notably faster.
3. Tried 99-tuning with 241 and 221. I think 221 looked promised, but not run long enough.

I tried a variety of voltages in 2 steps, but nothing seemed faster. TBH, I am clueless and nearly ever OCer knows better, so I'm just a blind tester. I don't understanding tuning at all.

I think three things so far:

1. A true testing matrix trying a full variable set trying FWs, clock speeds, and custom cgminers, and voltage, spi frequency, and spi voltage is needed.
2. A determination concerning length of testing time is needed.
3. I'm probably missing 3 more things.

[mekadeka]

My experience is that when applied same setting this version gets better hashrate on console and little bit less current consumption BUT on the poolside It's always less than with cgminer 3.9.0. Dont know if its issue with pool or what. On the other hand I have seen with 3.9.0 on the poolside even more hash-speed than it shows. Like if cgminer shows 459gh/s, poolside it sometimes as high as 488gh/s. This is with 3.9.0. Of course there is some variation.

'
Thanks, Temen. I'll definitely throw something your way for giving me a hand.

I did try the wizkid cgminer. The result appears to be faster hashing  poolside but with pool reporting significantly more rejections . My errors have always been pretty low. Right now they're reporting about 6-7% after 15 minutes of testing. Former hash on the machine was 311, now4. showing 317 in wkcgminer. Pool rate is all over the place, right now at 304. I'll let it run a little more.

Temen, how should one go about testing clock speeds?

[temen]

I don't know anything about clock-speeds as I dont have any advanced tuning on november, just bertmod (which is by no means bad, its great tool to see vrm amp and other stuff). I wish i had some command to set voltage manually on asics. I think it has to be 12cset command and bus and address and commad bytes etc. combination. It writes number 3 on the line on the start to busses 3 4 5 6 7 8 and their respective vrms on part wher it says "clear faults on megadlynx". That number 3 is fault clearance on written to correct address (which seems to be 0x11...0x18 but dont have the guts to try it =) Dont know anything about coding so perhaps I leave it be..

VOUT setting would be PMBUS address 0x21 I think but where it is located here dunno.

---

3.8.1 Set TCK/SK Divisor (FT2232D)
0x86,
0xValueL,
0xValueH
This will set the clock divisor. The TCK/SK always has a duty cycle of 50%, except between commands where it will remain in its initial state. The initial state is set using the Set Data Bits Low Byte command (0x80). For example, to use it in JTAG mode you would issue:-

---

Thats excerpt from kncminer github some command processor manual.

There is also register which divides the clock speed by 5 as default. I wonder if kncminer just disables this division with neptune 

[mekadeka]

bertmod

which version of bertmod are you using?

[crashoveride54902]

I'm having a hard time getting 251 running good...had 241 running at 700gh/s with .5% hw errors...so i tried reseting volts to default and playing around with it...I'm hoping i can eventually get it running good...starting to notice 2 vrms like to drop down in amps like temen but a restart on oc'in will get them to play well...dunno if that means they are giving out to the stress or what but i hope they don't go will update after more playing...i'm on an oct. jup just incase anyone forgot...ya i don't think oct. jups will be able to oc as high as nov..not even close

I've also noticed if you play around with the volts on one module...it'll affect all modules..dunno if its just my unit or what but if i change the volts on one module...I get different hashrate/hw errors on all modules...or maybe i'm just seeing things idk hehe

[temen]

@mekadeka: I think its bertmod 0.4. I have november 0.99.1-E and it seems to wrk with it. Is there newer revidion hm... =)

[isimme]

I've also noticed if you play around with the volts on one module...it'll affect all modules..dunno if its just my unit or what but if i change the volts on one module...I get different hashrate/hw errors on all modules...or maybe i'm just seeing things idk hehe

This is the same in my experience and is why I OC but don't change the volts.
I couldn't get a good feel with the volts,
as even the way they react changes over an indefinable period of time.
It's like trying to mix paints and not understanding the underlying color theory.

[pedrosoft]

I'm having a hard time getting 251 running good...had 241 running at 700gh/s with .5% hw errors...so i tried reseting volts to default and playing around with it...I'm hoping i can eventually get it running good...starting to notice 2 vrms like to drop down in amps like temen but a restart on oc'in will get them to play well...dunno if that means they are giving out to the stress or what but i hope they don't go will update after more playing...i'm on an oct. jup just incase anyone forgot...ya i don't think oct. jups will be able to oc as high as nov..not even close

I've also noticed if you play around with the volts on one module...it'll affect all modules..dunno if its just my unit or what but if i change the volts on one module...I get different hashrate/hw errors on all modules...or maybe i'm just seeing things idk hehe

october jupiter ?

[FeedbackLoop]

I've also noticed if you play around with the volts on one module...it'll affect all modules..dunno if its just my unit or what but if i change the volts on one module...I get different hashrate/hw errors on all modules...or maybe i'm just seeing things idk hehe

I see the same. :/

I wasn't able to try different clocks in different boards because of that. Not able to  pass 201 (Oct Jupiter, all boards, cgminer, BFGminer gives me much lower hashrate for some reason, tune 0.99.1, 0.0542V on all dies).

[crashoveride54902]

I'm having a hard time getting 251 running good...had 241 running at 700gh/s with .5% hw errors...so i tried reseting volts to default and playing around with it...I'm hoping i can eventually get it running good...starting to notice 2 vrms like to drop down in amps like temen but a restart on oc'in will get them to play well...dunno if that means they are giving out to the stress or what but i hope they don't go will update after more playing...i'm on an oct. jup just incase anyone forgot...ya i don't think oct. jups will be able to oc as high as nov..not even close

I've also noticed if you play around with the volts on one module...it'll affect all modules..dunno if its just my unit or what but if i change the volts on one module...I get different hashrate/hw errors on all modules...or maybe i'm just seeing things idk hehe

october jupiter ?

you didn't read the whole post

Well thxs to Nil's help on IRC and his thread http://forum.kncminer.com/forum/main-category/main-forum/27841-0-99-x-tuning-die-tuning

I'm now able to see per die hw error n apply more volts to that trouble maker!! woot..and now playing around with volts and watching graph i guess we were seeing things cause i got one mod that doesn't have much error and hasn't moved since playing around with others

and yes adding to many volts to a die will increase hw error as well...that is why i was having such a hard time with 251...cause i just kept adding more n more...all is good now .5% hw and 720gh/s on 251