Hacking The KNC Firmware: Overclocking

[CYPER]

Does someone have the code handy for a cgminer.sh file that has each board or die for that matter OC'able?  I think I can get more performance out of particular boards but not by doing the entire Jupiter. Thanks.

Paste just below line 61 or whichever line the original 0x86 register is at.
Also change if [ $c -eq 0 ] to your particular board configuration.

http://pastebin.com/vy7jppS3

Cyper, please, does the script require the "DC/DC ID" for each die or the "Die ID"? KNC's GUI shows 1,2,3,4 for Die ID but 0,2,4,7 for DC/DC ID, but I'm not clear on which to use.


       if [ $c -eq ? ]
       then
               cmd=$(printf "0x86,0x%02X,0x02,4xB2" $c)
       fi
       if [ $c -eq ? ]
       then
               cmd=$(printf "0x86,0x%02X,0x02,4xB2" $c)
       fi
       if [ $c -eq ? ]
       then
               cmd=$(printf "0x86,0x%02X,0x02,4xB2" $c)
       fi
       if [ $c -eq ? ]
       then
               cmd=$(printf "0x86,0x%02X,0x02,4xB2" $c)
       fi
fi

Die ID and they start from zero. So if GUI shows 1,2,3,4 then it is 0,1,2,3

[1714202360]

1714202360

[1714202360]

1714202360

[1714202360]

1714202360

[1714202360]

1714202360

[1714202360]

1714202360

[j03]

Thank you very much j03. I'm not clear on exactly what to modify in the bash script for an October Saturn, but I'm getting there.

KNC gui shows ASIC slot #3 and ASIC slot #4 are used. I assume this is 3 and 4 on the control board? There are two free spots to the left and two to the right.

---------------beagleboard side----------------------
 plug        plug        plug       plug        plug       plug
{FREE}   {FREE}   {USED}   {USED}   {FREE}   {FREE}  
                             |            |
                             |            |
                             |            |
                             |            |
                          [ASIC]    [ASIC]
                           4 dies     4 dies
---------------ASIC/FAN side-----------------------


How do you count these spots for the script?

Looking down at the controller board from the direction you have illustrated, the plugs (ASIC board numbers) are 0 through 5 counting from right to left. So, your boards that are in use are: 2 and 3 from right to left.

[mekadeka]

Die ID and they start from zero. So if GUI shows 1,2,3,4 then it is 0,1,2,3
[/quote]

Thank you.

[crashoveride54902]

DO NOT ATTEMPT THIS


Three attempts with a single 8vrm board for tests and each time i got the same result, a CRAZY buzzing noise from each VRM.

I have had this before from a board that got RMA'ed.


edit: few minutes after powering off i hear this clicking noise, like a switch being flicked. I also heard this on the faulty 4vrm board.

just did this and i can confirm it works and i hear no funny noises...i used same volts as he did -0.0527

5-8c drop in vrm temp, i'm rocking 2 241 n 2 271 now...temps all below 50c and the 8vrms mods are lower temp then 4vrms n oc'd more man i wish i had more 8vrm mods...

730gh/s 10200 WU with .31 hw errors...guess i'll wait for 24hr avg to see if it holds yay!!

[elasticband]

DO NOT ATTEMPT THIS


Three attempts with a single 8vrm board for tests and each time i got the same result, a CRAZY buzzing noise from each VRM.

I have had this before from a board that got RMA'ed.


edit: few minutes after powering off i hear this clicking noise, like a switch being flicked. I also heard this on the faulty 4vrm board.

just did this and i can confirm it works and i hear no funny noises...i used same volts as he did -0.0527

5-8c drop in vrm temp, i'm rocking 2 241 n 2 271 now...temps all below 50c and the 8vrms mods are lower temp then 4vrms n oc'd more man i wish i had more 8vrm mods...

730gh/s 10200 WU with .31 hw errors...guess i'll wait for 24hr avg to see if it holds yay!!

just tried it with a second 8VRM jupiter, same result, crazy buzzing/hissing noise from all boards.

1.95spi3.3spi  201442mhz -0.0527

TAKE SCREENSHOTS OF HOW YOUR BOARDS ARE TWEAKED FOR AN EASY RESET


eit: i tried to record it, but the sound of other fans over powers it in the

edit: well here goes my sunday, going to test each 8vrm board individually

edit: first board, buzzing, HW 0% hashrate 205GH. Don't know if this is good or bad.

edit: -0.07 seems to have calmed the buzzing a little, but still there. going lower. -0.0527 really sets the buzzing off and HW high.

edit: -0.089 seems to have stopped it, but not getting near 190GH. only 155GH with 1.5% HW

edit: now this is interesting, despite the above, the board reads at taking 130w for 155GH

edit: second board, 8vrm all taking power, there is a very faint buzzing noise, nothing like the last. away to try OC now

edit: OC 271, 187GH 0.03%HW, power 213w. -0.0527, buzzing noise
edit: no buzzing noise, NO OC, -0.0798, 165-170GH 140w, 0.03% HW
edit: low buzzing noise, 271 OC, -0.0798, 190-195GH 195w, 0.00% HW

edit: third board, all 8vrm have power, really faint buzzing. OC coming
edit: buzzing increased,OC 271 180GH 210w .26%hw -0.0527. buzzing increasing
edit: lower buzzing, OC 271, 190GH 201w 0.11% HW -0.0798
edit: much lower buzing, 0c 271, 185GH 195w 2.3HW -0.0894

edit: suns semi out, going out. getting no where.

edit: did the last board whilst waiting for the woman. pretty much same results as above but never as nice of a GH rate.

[bondus]

DO NOT ATTEMPT THIS


Three attempts with a single 8vrm board for tests and each time i got the same result, a CRAZY buzzing noise from each VRM.

I have had this before from a board that got RMA'ed.


edit: few minutes after powering off i hear this clicking noise, like a switch being flicked. I also heard this on the faulty 4vrm board.

just did this and i can confirm it works and i hear no funny noises...i used same volts as he did -0.0527

5-8c drop in vrm temp, i'm rocking 2 241 n 2 271 now...temps all below 50c and the 8vrms mods are lower temp then 4vrms n oc'd more man i wish i had more 8vrm mods...

730gh/s 10200 WU with .31 hw errors...guess i'll wait for 24hr avg to see if it holds yay!!

just tried it with a second 8VRM jupiter, same result, crazy buzzing/hissing noise from all boards.

I have inspected what the November firmware has actually changed.

What I can see it has changed a value in one of the registers in the VRMs. It has set the "ON" bit in the OPERATIONS register,changing what conditions are needed to turn the VRMs on.
This change will be permanent even if rebooted or power-cycled. It can be changed using i2c commands:


Turn all VRMs on:

#!/bin/sh
# Stop SPI poller
i2cset -y 2 0x71 2 0

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 1 0x80 >/dev/null 2>&1
        done
done


Restore to factory settings:

#!/bin/sh
# Stop SPI poller
i2cset -y 2 0x71 2 0

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 1 0x0 >/dev/null 2>&1
        done
done


I suggest stopping cgminer before doing this to limit the power when the operation is done.

Reading the datasheet for the VRMs I can see that when using them in pairs (as we do when all are turned on) there are some requirements on how they should be turned on. This method does not do that!

I have heard that hizzing sound as well. Some boards do that. They did that on 0.90 firmware too. No idea why.

I do not know if this is safe or not, it might be unsafe and burn your boards.

[crashoveride54902]

OK guess i was wrong...I can hear a faint buzzing noise from my vrms...didn't know you had to have yer ear right next to the board to hear it...i thought it was loud hehe...i dunno then..but i'm liking the speed increase....

[elasticband]

OK guess i was wrong...I can hear a faint buzzing noise from my vrms...didn't know you had to have yer ear right next to the board to hear it...i thought it was loud hehe...i dunno then..but i'm liking the speed increase....

Bondus: do you have buzzing noises too? I'm using 3v spi n 170666 freq and with that code above...i don't get what it does cause both are same

mine are much louder than what you describe, my girlfriend could here it in the next room when i had the door open and that is with fans running on top. at faintest i could still hear it when about 3 feet away from the jupiter with other noise around, including outside noise(open window, busy street)

[crashoveride54902]

OK guess i was wrong...I can hear a faint buzzing noise from my vrms...didn't know you had to have yer ear right next to the board to hear it...i thought it was loud hehe...i dunno then..but i'm liking the speed increase....

mine are much louder than what you describe, my girlfriend could here it in the next room when i had the door open and that is with fans running on top. at faintest i could still hear it when about 3 feet away from the jupiter with other noise around, including outside noise(open window, busy street)

dayum thats loud...then i guess i won't worry too much about my little buzzing noise i can't even hear sitting next to it...can't believe all the different build qualities knc had with their units...maybe we should start a grading system hehe

[sickpig]

I have inspected what the November firmware has actually changed.

What I can see it has changed a value in one of the registers in the VRMs. It has set the "ON" bit in the OPERATIONS register,changing what conditions are needed to turn the VRMs on.
This change will be permanent even if rebooted or power-cycled. It can be changed using i2c commands:


Turn all VRMs on:

#!/bin/sh
# Stop SPI poller
i2cset -y 2 0x71 2 0

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 1 0x80 >/dev/null 2>&1
        done
done


Restore to factory settings:

#!/bin/sh
# Stop SPI poller
i2cset -y 2 0x71 2 0

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 1 0x0 >/dev/null 2>&1
        done
done


I suggest stopping cgminer before doing this to limit the power when the operation is done.

Reading the datasheet for the VRMs I can see that when using them in pairs (as we do when all are turned on) there are some requirements on how they should be turned on. This method does not do that!

I have heard that hizzing sound as well. Some boards do that. They did that on 0.90 firmware too. No idea why.

I do not know if this is safe or not, it might be unsafe and burn your boards.

amazing findings! kudos.

Next time I'll go to my "mining facility" I'll give it a try for sure.

ps this one of the more knowledgeable thread I've ever found on btctalk

[elasticband]

271, loud buzzing, 753GH/ 780W 1.6% overall HW, cannot get them as low as i could with the boards individually

[crashoveride54902]

271, loud buzzing, 753GH/ 780W 1.6% overall HW, cannot get them as low as i could with the boards individually

lol your gona drive yer gf more batty...doing them individually vs whole machine shouldn't make a difference...you sure all cores fired up? i've had some cores not enable n bertmod showed them enabled but i was getting less hash...a oc'in restart got'em to fire up again thou...or sometimes a different volt for that die was needed...sure are picky asics

[elasticband]

got my second one running, buzzing noise also, but not as bad as the other.

271, 760/750GH 1.3%overall HW 780w power between the 4 boards.

when i was testing them all individually as mentioned in my previous post, i had some running at 190GH with 0.03% HW, i cannot repeat this with multiple boards.

[sickpig]

got my second one running, buzzing noise also, but not as bad as the other.

271, 760/750GH 1.3%overall HW 780w power between the 4 boards.

when i was testing them all individually as mentioned in my previous post, i had some running at 190GH with 0.03% HW, i cannot repeat this with multiple boards.

so maybe the controller board is the bottleneck.

did you try to tweaks SPI freq and voltage?

[elasticband]

i tweaked many things - https://bitcointalk.org/index.php?topic=313978.msg5175175#msg5175175

they are running fine, with under 1.5% HW. 740 + 750GH, going on a couple of ours now. Still buzzing...... but oh well just going to roll with it.

[sickpig]

i tweaked many things - https://bitcointalk.org/index.php?topic=313978.msg5175175#msg5175175

they are running fine, with under 1.5% HW. 740 + 750GH, going on a couple of ours now. Still buzzing...... but oh well just going to roll with it.

thanks for sharing.

Did you turn all 8 VRMs on applying the 0.99.2-E or did you use the trick bonsus posted here https://bitcointalk.org/index.php?topic=313978.msg5176922#msg5176922 ?

[elasticband]

i tweaked many things - https://bitcointalk.org/index.php?topic=313978.msg5175175#msg5175175

they are running fine, with under 1.5% HW. 740 + 750GH, going on a couple of ours now. Still buzzing...... but oh well just going to roll with it.

thanks for sharing.

Did you turn all 8 VRMs on applying the 0.99.2-E or did you use the trick bonsus posted here https://bitcointalk.org/index.php?topic=313978.msg5176922#msg5176922 ?

No problem, it was easy way for me to keep track of what i was doing. 8vrm's were engaged with the 0.99.2E, i looked at the trick bonsus posted, but my cgimner looked slightly different than the default revert he posted, so i stuck with the 0.99.2E apply, a power cycle puts it back to only 4vrm running.

the one that struck me as most interesting was the following

edit: no buzzing noise, NO OC, -0.0798, 165-170GH 140w, 0.03% HW

that would be 0.825w per GH, that is just the board power consumption from the advanced page. Obviously with cntl board and fans it will be consuming more though, but still.......

[sickpig]

i tweaked many things - https://bitcointalk.org/index.php?topic=313978.msg5175175#msg5175175

they are running fine, with under 1.5% HW. 740 + 750GH, going on a couple of ours now. Still buzzing...... but oh well just going to roll with it.

thanks for sharing.

Did you turn all 8 VRMs on applying the 0.99.2-E or did you use the trick bonsus posted here https://bitcointalk.org/index.php?topic=313978.msg5176922#msg5176922 ?

No problem, it was easy way for me to keep track of what i was doing. 8vrm's were engaged with the 0.99.2E, i looked at the trick bonsus posted, but my cgimner looked slightly different than the default revert he posted, so i stuck with the 0.99.2E apply, a power cycle puts it back to only 4vrm running.

Yeah, I've thought the same thing. In my cgminer init script (0.99.1-tuning fw) this what's used:

i2cset -y $b 0x1$d 3 >/dev/null 2>&1 || true

on each VRM on each ASIC board to "CLear faults in megadlynx's" (their on comment at the beginning f the double loop in the start() funciton).

As you can see there're 3 parameters after the y switch whereas in the bondus snippet the i2cset command is issued with 4 pars

i2cset -y $b 0x1$d 1 0x80

I've to check more carefully the VRM manual though (https://github.com/KnCMiner/jupiter-hw-docs/blob/master/MDT040A0X.pdf) to understand properly what's going on.

Another things to take into account is that bondus settings remain valid across reboot.

the one that struck me as most interesting was the following

edit: no buzzing noise, NO OC, -0.0798, 165-170GH 140w, 0.03% HW

that would be 0.825w per GH, that is just the board power consumption from the advanced page. Obviously with cntl board and fans it will be consuming more though, but still.......

It could be that for some reasons using 4 VRM lead to a more efficient setup in term of power consumption. just a wild a guess though.

[mekadeka]

I have an October Saturn currently running 612/589ghs through cgminer and 585 through KNC's gui. This is far and away the absolutely highest numbers I've seen (for me and this machine), by almost double.

Thing is, it's doing no good. Error must be bad. WU is only 1450ish.

Poolside reporting is tragic -- looks like about 185ghs.

If someone can help me figure out how to make use of this apparent speed/reduce errors, I'll leave you a nice tip. I don't have enough knowledge and must resort to bribes.

[DPoS]

I have an October Saturn currently running 612/589ghs through cgminer and 585 through KNC's gui. This is far and away the absolutely highest numbers I've seen (for me and this machine), by almost double.

Thing is, it's doing no good. Error must be bad. WU is only 1450ish.

Poolside reporting is tragic -- looks like about 185ghs.

If someone can help me figure out how to make use of this apparent speed/reduce errors, I'll leave you a nice tip. I don't have enough knowledge and must resort to bribes.

you'll have to post some pics (and let the miner run for 15 mins first)

what you posted doesnt really make sense