Pages:
Author

Topic: Hacking The KNC Firmware: Overclocking - page 42. (Read 144362 times)

hero member
Activity: 491
Merit: 514
January 22, 2014, 12:55:11 PM
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 Smiley

You're running at 80C without any failing VRM's? When I overclocked a Nov Jupiter a few VRM's started failing after temps passed 65C. I'm going to try again when I have time to take the cases off and point an external fan on them since it ran fine for about 15 minutes at lower temp...
member
Activity: 119
Merit: 10
January 22, 2014, 07:18:44 AM
Hi everybody, waiting for donations  Grin

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!
sr. member
Activity: 812
Merit: 250
January 22, 2014, 12:50:06 AM
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 Smiley
Wow, thanks! Temperature is 80 C and more, is it not quiet dangerous for the boards?  Shocked

The hashing rate sounds nice but the temperature make me worry a bit...how was the temperature in your jupiter before you OC? My miner is 50-62 C already at 678Gh/s speed.

Could you test how much watt the OC jupiter suck at the wall?
full member
Activity: 147
Merit: 100
software developer
January 21, 2014, 04:23:34 PM
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 Smiley
ImI
legendary
Activity: 1946
Merit: 1019
January 21, 2014, 02:52:38 PM
Margins, yes Smiley but 100% (or even more?).

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

why do you assume that they arent?
newbie
Activity: 32
Merit: 0
January 21, 2014, 02:40:56 PM
Margins, yes Smiley 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 Wink
sr. member
Activity: 812
Merit: 250
January 21, 2014, 01:53:44 PM
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://bitcointalksearch.org/topic/m.4620979

and here he describes what you should do to overclock it:
https://bitcointalksearch.org/topic/m.4621190
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.
member
Activity: 119
Merit: 10
January 21, 2014, 01:49:14 PM

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.

newbie
Activity: 32
Merit: 0
January 21, 2014, 01:36:06 PM
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 Smiley
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).
member
Activity: 119
Merit: 10
January 21, 2014, 01:27:22 PM
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?!

newbie
Activity: 32
Merit: 0
January 21, 2014, 01:13:24 PM
24A? Smiley
Found a way to reglate voltage?
member
Activity: 119
Merit: 10
January 21, 2014, 10:40:13 AM
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=(

full member
Activity: 237
Merit: 100
January 21, 2014, 10:22:23 AM
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://bitcointalksearch.org/topic/m.4620979

and here he describes what you should do to overclock it:
https://bitcointalksearch.org/topic/m.4621190
sr. member
Activity: 812
Merit: 250
January 21, 2014, 10:14:34 AM
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?  Huh
full member
Activity: 237
Merit: 100
January 21, 2014, 07:53:56 AM
@giletto and jelin
just look at page 24 the last 6-7 posts
sr. member
Activity: 812
Merit: 250
January 20, 2014, 11:55:49 PM
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?
legendary
Activity: 2408
Merit: 1004
January 20, 2014, 07:49:12 PM
You mean you overclocked the November Jupiter
At which hashing speed?
newbie
Activity: 32
Merit: 0
January 20, 2014, 02:02:21 PM
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 Smiley
member
Activity: 119
Merit: 10
January 20, 2014, 12:04:46 PM
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.

member
Activity: 119
Merit: 10
January 20, 2014, 11:58:21 AM

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=)
Pages:
Jump to: