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

I used the method of flashing 99.2E then back to 99.2, this enables the 8vrm's and then i just proceeded to tune and OC. Been running very stable with low HW and some buzzing noise for about a week.

the volts are pretty even among each pair, nothing additional done, no problems here.

As voltage has to die each orient?

clock setting 291, been running fr over a week now

you can put your configuration?

It is a Octember Unit, or maybe it was a Novober  

Although I ordered all the parts, for the one off parts I cheated.
I have resistor assortment kits, have not figured out the values yet.
I will measure them next downtime.

YMMV

780 gh

What is November or October Jupiter?

Mining Status

Miner Status   Running BFGMiner (pid=29686)
Last Checked   Wed Feb 26 00:14:17 UTC 2014
Avg. Hash Rate   782 Gh/s
WU   10808
Difficulty Accepted   91349361
HW Status

ASIC slot #1   -
ASIC slot #2   45.5 ℃
ASIC slot #3   -
ASIC slot #4   42.0 ℃
ASIC slot #5   40.0 ℃
ASIC slot #6   47.0 ℃




SPI voltage - 1.7



SPI Frequency 170666


Power Consumption

798.750  W

ASIC 2

die 1
die 2
die 3
die 4

Temp : 45.5 °C



Power : 204.802 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.8252   29.8750   24.653
1   0.8232   34.8125   28.658
2   0.8164   32.6875   26.686
3   0.8281   29.3125   24.274
4   0.8174   30.3750   24.829
5   0.8213   30.8125   25.306
6   0.8125   28.8125   23.410
7   0.8086   33.3750   26.987
ASIC 4

die 1
die 2
die 3
die 4

Temp : 42.0 °C



Power : 187.352 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.8262   29.6250   24.476
1   0.8115   33.8750   27.490
2   0.8145   23.5000   19.141
3   0.8320   19.6875   16.380
4   0.8105   29.6875   24.062
5   0.8340   32.0625   26.740
6   0.8242   27.6875   22.820
7   0.7998   32.8125   26.243
ASIC 5

die 1
die 2
die 3
die 4

Temp : 39.5 °C



Power : 203.942 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.8301   28.9375   24.021
1   0.7988   35.0000   27.958
2   0.7900   30.9375   24.441
3   0.8096   28.3750   22.972
4   0.8135   30.2500   24.608
5   0.8223   31.0625   25.543
6   0.8447   30.1875   25.499
7   0.8184   35.3125   28.900
ASIC 6

die 1
die 2
die 3
die 4

Temp : 46.5 °C



Power : 202.654 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.8174   27.0625   22.121
1   0.8008   33.3750   26.727
2   0.8115   31.9375   25.917
3   0.8311   29.7500   24.725
4   0.8350   32.8125   27.398
5   0.8271   32.5000   26.881
6   0.8174   26.2500   21.457
7   0.7979   34.3750   27.428

Too bad I do not have access to a proper electronics lab
Most of your ideas could be easily tested with a scope and some other basic tools.

But I have made some other observations that might be interesting:

Iout and Vout from the two VRMs in the pairs are not even.

Typical values (as reported by the VRMs):
table]

VRM Nr	V	A
0	0.8154	24.8750
1	0.7998	27.6250
2	0.8066	30.3125
3	0.8164	26.8125
4	0.8184	30.5000
5	0.8096	30.0000
6	0.8235	27.6250
7	0.8164	31.8750

0,3 and 6 have slightly higher voltage that the other VRM in each pair. The pair 4,5 is pretty even.
Current is a bit higher on the VRMs with lower voltage. It looks the same on many different boards.
You would expect voltage and current to be the same on both VRMs in a pair. Odd.

The buzzing gets louder the more power you use. You can clearly hear when a block is found
I haven't had time yet to open a box and check what VRMs are buzzing.

Since you have ordered the parts you must know the value of then RTUNE and RTrim resistors for the VRMs?

I copy cgminer.sh run but did not work, but the firm was 0.99.1tune.

0.99 will use the copied file and will update the firm 1.0

how do I put the bfgminer and not cgminer?

regards

Edit to say, after to put again the firm 0.99.1 tune, i have a little problem with voltages.. it was crazy.. now is working well after reset to factory defaults in advanced but a line 12v of my 1100w PSU now is dead, i got a screenshot, any idea of this?

Surely you kept a backup of your overclock.sh or zzz.sh or cgminer.sh before you upgraded right? It should be in your /config directory like the original overclocking instructions indicated. You didn't modify the original cgminer.sh directly did you?

I guess even if you did modify it you kept a copy just in case you overclocked too far and needed to go back or made a mistake and corrupted the original.

Last resort is to flash back to 0.99 (non tune version) then start again from the beginning.

Also FYI if you had kept the modified cgminer.sh from before the flash you can run it and it will overclock like before even with v1.0 of the firmware.

+1

 I have a jupiter October 4vrm to 647Gh using 221 firm 0.99.1 tune, I've updated to 1.0 and now firm not give OC, the lines are different from 0.99.1 tune.

help please

bondus thx !

Is the buzzing 1 VRM, ALL VRM's, or just a few?

DISCLAIMER:
I have Oct 4 VRM hardware.
I have extra VRM's(and associated parts) that I thought to install, that is why I have studied it.
At this point not cost effective, at over .25 BTC ( >USD$125 ) per ASIC in VRM's alone.

I have 'ideas' why 8 VRM's MIGHT misbehave.
(notice the lack of absolutes in the above sentence!)

Each 'idea' depends on flimsy evidence.

Looking at a 4 VRM Oct unit one might notice that the VRM's are numbered 0,2,4,7.
At minimum this is just an aesthetic anomaly. (the 7 is odd)
What if it is the result of KnCMiner having difficulty with the address resistors for the VRM's?
(mis-calculated, placement switcheroo, whatever)
One could measure the address parts on the bottom of the PCB to SIG_GND.
or
What if there are routing errors with the VRM clocks?
If the clocks are not in correct pairs with each part of the pair on the correct clock this could lead to the buzzing OR WORSE!

The VRM clocks on an Oct module originate in the following part
http://cds.linear.com/docs/en/datasheet/6902f.pdf

An installed part
http://i.imgur.com/nu2ImZ5.png

Leftmost resistor is RMOD
Next to it is RSET
Along the top are inline components between the VRM clock output and the VRM.
If I measured them I forgot, but I assume 0 ohm parts inline.

KnCMiner implimented the reference design almost exactly including the external part placement! (thx KnC).
The main difference is 400KHz instead of 500KHz (this is what the GE VRM needs).

It might be a simple fanout issue, 4 clocks driving 8 VRM's and not enough oomph.
Would require extensive HW mods (barnacles) to fix.
About all you could do is check the inline part (between the clock source and the pairs of VRM's) assumed(by me) to be a 0 ohm 'resistor' and verify. Might try a 'pencil mod' on the parts if it is found to not be 0 ohm???

KnCMiner chose 4 clocks 90 degrees out of phase. (I need to recheck/reverify this)
If the clocks are not in proper pairs it might not even work, if it did, buzzing could be expected.
I will test for this next downtime by looking for continuity between the clock lines on the empty locations on a 4 VRM module. A short between any of those might indicate a routing error???
OR
The the clocks are in correct pairs but the address's of the VRM's are off and the commanded voltages may not be in proper pairs.
Do the voltages reported on an 8 VRM Oct module behave as expected in pairs???
Might require actually measuring VRM output voltages to determine. (two moving targets)
*THIS might BE FIXED WITH SOFTWARE*

I doubt spread spectrum clocks is an issue if the clocks go in correct pairs but it can be TEMPORARILY DISABLED on a running module to test.
DO NOT TRY THIS AT HOME KIDDIES!
You can short between pin #8 and pin #9 on the VRM clock chip with an Oscope probe (or sewing needle).
This will short MOD to ground (pin #8) and disable spread spectrum temporarily to listen for improvement.
**This will ALSO temporarily short chip power THRU the RMOD resistor to ground**
(a trivial current for a temporary test)
I have done this while watching a Kill-a-WATT and spread spectrum gains about 1 WATT in efficiency per ASIC.
It might also slightly effect HW errors due to different noise patterns.

If there are clock pair routing issues, changing from 4 phase clock to 2 phase clock domain might solve it.
One might expect other issues to surface, it's a major change.
This would definately be beyond the scope of the typical user though.

One other simple test would be to change the VRM clock speed.
Lick your finger and place it on the RSET resistor of a running buzzing module.
This will slightly raise the VRM clock speed.
Better or worse?

I'm still curious what it is.

Just my 2 Satoshi's

YMMV

How did you overclock 1.0? The cgminer.sh file is different.

Yes you can

Edit feb 25: Change initial adjustment to -0.0806. Higher voltage cause massive buzzing from the VRMs

I will start with a warning. It is unknown if this is safe. KnC may have turned off the VRMs due to that there is a problem with the design.
You board might burn! On the other hand they ran with all VRMs turned on for a few weeks when they were new without any major issues.
I have run a few machines with 8VRMs for almost 2 weeks without problems. Some machines will start buzzing pretty loud, I have no idea why.

Suggested procedure to enable all 8 VRMs:

1. Change all voltage adjustment to -0.0806.
When all VRMs are turned on the adjustment will be from a base of ~0.9V,
-0.0806 will give a voltage of ~0.82V which works fine for most chips at 1Ghz.
With -0.0806V and 1Ghz the machine will pull over 800W from the PSU (~190W reported per board).

2. Stop cgminer/bfgminer
Run on a shell:
/etc/init.d/cgminer.sh stop

3. Run the enable.sh script. (see below)
The script will take the voltage adjustments of the "official" 4 VRMs on each board and make sure that both VRMs for each die will have the same adjustment. It also turns on all VRMs.

4. reboot. Do not power cycle.
The VRMs have a tendency to get upset when they are turned on the first time and set error flags and in some cases not start properly. A reboot cleans things up.

5. Verify on the advanced settings page that the current on each pair of VRMs is in the same ballpark. The pairs are 0+1, 2+3, 4+5 and 6+7.

6. Overclock as usual

Each time you apply a voltage adjustment in the advanced page you have to run enable.sh again to make sure the pairs have the same adjustment.
This is VERY important!.


The script is safe to run on a machine with mixed 4 and 8 VRM boards. You may get some error message when the script tries to tank to the missing VRMs.

If you powercycle the machine I am pretty sure all changes are gone. I haven't powercyled my machines since October when there was a storm and we lost power for a few minutes.


The script (enable.sh):


#!/bin/sh

# Fetches the TRIM settings of the official 4 VRMs and sets the
# same value into each paired VRM.
for b in 3 4 5 6 7 8 ; do
    v0=`i2cget -y $b 0x10 0x22 w 2>/dev/null`
    if [ "$v0" != "" ] ; then
        i2cset -y $b 0x11 0x22 $v0 w 2>/dev/null
    fi

    v1=`i2cget -y $b 0x12 0x22 w 2>/dev/null`
    if [ "$v1" != "" ] ; then
        i2cset -y $b 0x13 0x22 $v1 w 2>/dev/null
    fi

    v2=`i2cget -y $b 0x14 0x22 w 2>/dev/null`
    if [ "$v2" != "" ] ; then
        i2cset -y $b 0x15 0x22 $v2 w 2>/dev/null
    fi

    v3=`i2cget -y $b 0x17 0x22 w 2>/dev/null`
    if [ "$v3" != "" ] ; then
        i2cset -y $b 0x16 0x22 $v3 w 2>/dev/null
    fi
done

# Turn On all VRMs using "on" in OPERATION
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


What the script does is that it reads the voltage adjustment register (VOUT_TRIM, address 0x22) from the official VRMs (0x10, 0x12, 0x14 and 0x17) and writes the same value to the other VRM in each pair. And then it sets the "On" bit (0x80) in the OPERATION register, address 1.

yes but then you can't use 1.0 with 8vrms settings...