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

Not every die is going to enjoy being overclocked. Use something like Bertmod to see which dies have disabled cores due to hardware errors. Using the per module, per die script, return troublesome dies to their original clock setting of 1D1 or whatever yours was. There's no strict rules. You have to experiment to see what works best for your machine. If you PM your Bertmod per module stats and your script, I can recommend clock settings.

Well 24hrs later, still getting an extreme buzz from both 8vrm jupiters, but 750 + 740 GH with bellow 1.5% makes me keep going, really everything seems fine.

You need to tune each h board. Send me team viewer details if you would like me to take a look

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

what you posted doesnt really make sense

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.

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.

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.

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


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

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://bitcointalksearch.org/topic/m.5176922 ?

i tweaked many things - https://bitcointalksearch.org/topic/m.5175175

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.

so maybe the controller board is the bottleneck.

did you try to tweaks SPI freq and voltage?

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.

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

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

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

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

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)

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

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.

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.

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