Hacking The KNC Firmware: Overclocking

[elasticband]

okay it is not as back and white as just yes or no things can go up down left right or just straight sideways  

[1714173128]

1714173128

[1714173128]

1714173128

[1714173128]

1714173128

[jelin1984]

You think leave it as it is

Hashing at 640 gh
Code 211

And firmware 1.00

[crashoveride54902]

Got my second October 4VRM Jupiter in and on first bootup worked fine for a few hours.  I updated to 1.0 to test and I noticed when I turned off SPI Auto this:



I've tried the hit it with SPI 3.3 and max voltage.  Let it run a few hours like that.  I have had them drop when OC to high but this I can't seem to rescue.



There is it at max voltage on that one.  I've swapped back to .99.1 , .99.2 and 1.0 and can't seem to get it to jump back up.

I've tried running 231 and 221 but sadly nothing helped kick that one up even.  

Any other suggestions so I can put this Jupiter to a happy #

I've been having the same problem until today on my O S+1. Now SPI @3.3V and die1 with -0.0806V and 675MHz made it work. I was getting higher rates with 231 around 450GH/s. Now with all other dies @775MHz total close to 425GH/s with less errors.... Also with all other dies at -0.1465V,  power dropped from 560W (w/ Stock values) to 460W at the wall.

Is there a way to 231 the other ASICs and leave this slepy die1 on ASIC alone @675MHz?

yes read the thread and find the msg where it talks about making every die different oc

[jelin1984]

Advanced Tuning
SPI voltage


Auto SPI Voltage
SPI Frequency


Power Consumption

666.498  W

ASIC 1

die 1
die 2
die 3
die 4

Temp : 54.0 °C



Power : 161.148 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.7822   50.0000   39.110
2   0.7822   49.8750   39.012
4   0.8008   53.0625   42.492
7   0.7861   51.5625   40.533
ASIC 3

die 1
die 2
die 3
die 4

Temp : 58.5 °C



Power : 174.061 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.8135   53.0625   43.166
2   0.7969   53.5625   42.684
4   0.8047   54.5625   43.906
7   0.8037   55.1250   44.304
ASIC 4

die 1
die 2
die 3
die 4

Temp : 57.0 °C



Power : 169.884 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.7832   51.3750   40.237
2   0.7949   53.6875   42.676
4   0.8096   55.0625   44.579
7   0.8008   52.9375   42.392
ASIC 5

die 1
die 2
die 3
die 4

Temp : 43.0 °C



Power : 161.405 W


DC/DC   Voltage (V)   Current (A)   Power (W)
0   0.7891   48.8125   38.518
2   0.8076   49.6875   40.128
4   0.7832   51.1875   40.090
7   0.7920   53.8750   42.669
Apply changes

[jelin1984]

is too high?

[DPoS]

I've been having the same problem until today on my O S+1. Now SPI @3.3V and die1 with -0.0806V and 675MHz made it work. I was getting higher rates with 231 around 450GH/s. Now with all other dies @775MHz total close to 425GH/s with less errors.... Also with all other dies at -0.1465V,  power dropped from 560W (w/ Stock values) to 460W at the wall.

Is there a way to 231 the other ASICs and leave this slepy die1 on ASIC alone @675MHz?

So you ran the whole board at 1A1 and the dead die came back to life?  Did you have to roast it to 80c first?

I just tried to run the dead die at that speed and keep the rest overclocked and it didn't wake up.. maybe the whole board huh?

no magic bullet yet

[jelin1984]

Mining Status

CGMiner Status   Running (pid=22518)
Last Checked   Sun Feb 23 17:25:03 UTC 2014
Avg. Hash Rate   644 Gh/s
Difficulty Accepted   198,080
Difficulty Rejected   2,496 (1.4 %)
Hardware Errors   2,110 (1.2 %)
WU   9,000
Difficulty Stale   0
Network Blocks   3
Pool Rejected   1.2 %
Pool Stale   0
Best Share   288,540
Found Blocks   0
HW Status

ASIC slot #1   51.5 ℃
ASIC slot #2   -
ASIC slot #3   56.0 ℃
ASIC slot #4   59.0 ℃
ASIC slot #5   45.0 ℃
ASIC slot #6   -

[kendog77]

The 1.0 firmware works really well with November Jupiters.

I simply changed the speed of all cores from 900 to 1000 and did nothing more, and my best November Jupiter increased from 675 GH to 750 GH. My other November Jupiter increased from 650 GH to 725 GH. Hardware errors also did not increase after overclocking, so the systems have been very stable after the overclock.

The 1.0 firmware really does nothing for October Jupiters though, as the overclocking options are very limited since the core speed can only be increased from 750 to 775. Custom hacking / overclocking still works best for October Jupiters.

[jelin1984]

Is safe to go at 1000 .?

[crashoveride54902]

Is safe to go at 1000 .?

not on 4vrm units

[Tigggger]

The 1.0 firmware works really well with November Jupiters.

I simply changed the speed of all cores from 900 to 1000 and did nothing more, and my best November Jupiter increased from 675 GH to 750 GH. My other November Jupiter increased from 650 GH to 725 GH. Hardware errors also did not increase after overclocking, so the systems have been very stable after the overclock.

The 1.0 firmware really does nothing for October Jupiters though, as the overclocking options are very limited since the core speed can only be increased from 750 to 775. Custom hacking / overclocking still works best for October Jupiters.

I noticed similar on my november one. I had to leave one die at 950 as the voltage/amps on it kept dropping to 0, but all the rest at 1000 and gone from 650 to 725 so very happy, and the reduction in HW errors is massive, previously around 1.5% now down to 0.07%

Changed my october one as well to reduce the hardware errors, changed them all to 775 but only getting 570GH which is down from the previous 620GH

Went to change the cgminer.sh file but the line I used to edit has gone

cmd=$(printf "0x86,0x%02X,0x01,0xF1" $c)

to this:

cmd=$(printf "0x86,0x%02X,0x02,0x11" $c)

Will I have to roll back firmware or is there a new edit ?

[capa]

I am in the same position, I've tried rolling back the firmware but it just trashed the miner and i had to put 1.0 firmware back on

Contemplating using the recovery file now

[Scoobypup]

If the 1.0.0 firmware now has an "overclocking" feature built into the web interface, couldn't we just modify the web interface files to include increases past the 775/1000 limit that the stock firmware has? That seems like it would be an easier method (if possible) for those unfamiliar with a *nix interface and editing files with vi. Just an open thought of course.

[DPoS]

If the 1.0.0 firmware now has an "overclocking" feature built into the web interface, couldn't we just modify the web interface files to include increases past the 775/1000 limit that the stock firmware has? That seems like it would be an easier method (if possible) for those unfamiliar with a *nix interface and editing files with vi. Just an open thought of course.

I was thinking that..  but currently running ~43Gh per die (at the pool) so don't want to mess with anything

[electrox]

Hi out there.

I am quite newbie to overclocking my October Saturn and have so far limited myself to using the new 1.00 firmware to increase clock frequenzy from 750 to 775 Mhz and it worked out fine.

I made a configuration backup (under the 'Upgrade' tab) and looking into 'advanced.conf' I can read the clock frequenzies mentioned at 775 Mhz as expected.

Since the miner probably does not actually uses the value '775' directly when setting the settings internally in the miner I would assume these frequencies/values refer to a list somewhere which interprets the clock frequenzy into a hex. For example 775 interprets into 1E1 if I read the list correctly. 1E1 is then used to configure the clock frequenzy. Am I correct?

So my thinking is that maybe the user interface of firmware 1.00 limits me from going higher than 775 Mhz on my October Saturn but I think KNC use the same firmware also for November units.
So maybe the dropdown list is limited to max 775 Mhz (because the firmware recognizes my miner as an October unit) but the actual list used for interpreting 775Mhz into 1E1 may be complete up to 1000Mhz (but only used for November units).

So my idea (which I did not dare to test yet...) is that I could change the 'advanced.conf' file to mention a higher clock frequenzy value and up load this new configuration to the miner which then finds a corresponding setting in the (hidden) list and voila... the overclocking is a reality.

Did somebody already try this approach?
What do you think about this? Could it work?

[capa]

I've tried editing the advanced.conf and changing the 775 value up to 975, the only thing that happened was, it blanked out the mhz value in the web interface.  

[electrox]

@ capa
Thanks for the feedback. Did you try a more modest increase. For example 800?
You say it blanked out the value in the web interface. But did the miner continue to run at 775Mhz?

[electrox]

Looking at the source code for the 'Advanced' tab I find in line 44-46 the following:

var dieFreqTemplate = $('<select/>');
         $.each(config.valid_die_frequencies, function(i, frequency) {
            dieFreqTemplate.append('<option value="' + frequency + '">' +   frequency + ' MHz</option>');

it looks like this is a lookup of valid die frequencies from a file named 'config.valid_die_frequencies'.

Maybe we just have to find this file and amend it?

[padrino]

Looking at the source code for the 'Advanced' tab I find in line 44-46 the following:

var dieFreqTemplate = $('<select/>');
         $.each(config.valid_die_frequencies, function(i, frequency) {
            dieFreqTemplate.append('<option value="' + frequency + '">' +   frequency + ' MHz</option>');

it looks like this is a lookup of valid die frequencies from a file named 'config.valid_die_frequencies'.

Maybe we just have to find this file and amend it?

In short the CGI backend calls "waas -i valid-config" to determine which settings the ASIC allows. "config.valid_die_frequencies" is the JSON element reqturned from waas that is used to populate the drop down. waas itself also applies all settings and it will not accept anything outside of the range supported, be it 775 on the October and 1000 on the November. I hacked up the firmware to allow settings outside of the range, I am working through one issue now and will post it when it's done..

[idee2013]

Hi,

does anyone know, if  it is ok to flash the 99.2E FW and flash back to 99.2 oct unit FW with a 4vmrs asic board

the problem is, that i have 3x8vmrs and 1x4vrms boads after a RMA. And now i woul like to activate all 8 vrms on the 3 8vrms boards and do not know what will happen with  the last 4vrm board.