I rolled back my October Jupiter firmware from 1.0 to rev .99 (not the tuning version) without any issues.
I suspect rolling back from 1.0 to a tuning revision is causing problems.
Topic: Hacking The KNC Firmware: Overclocking - page 26. (Read 144362 times)
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
Contemplating using the recovery file now
I think I've got mine back to it's previous 625GH
Had to roll back to 0.99.1-tune to achieve any success
Changed the cgminer.sh file back to 211, started cgminer, redid the SPI settings and all the voltages (fortunately I'd taken a screenshot after I initially set them up), restarted cgminer and appears to be OK
I am getting some AJAX errors from the GUI, but just ignoring those as it's running.
Looking at the source code for the 'Advanced' tab I find in line 44-46 the following:
var dieFreqTemplate = $('');
$.each(config.valid_die_frequencies, function(i, frequency) {
dieFreqTemplate.append('');
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?
var dieFreqTemplate = $('');
$.each(config.valid_die_frequencies, function(i, frequency) {
dieFreqTemplate.append('');
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..
Are you going to reverse-engineer the waas executable or are you modifying the cgminer init script to overwrite settings applied by the waas executable?
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.
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.
Looking at the source code for the 'Advanced' tab I find in line 44-46 the following:
var dieFreqTemplate = $('');
$.each(config.valid_die_frequencies, function(i, frequency) {
dieFreqTemplate.append('');
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?
var dieFreqTemplate = $('');
$.each(config.valid_die_frequencies, function(i, frequency) {
dieFreqTemplate.append('');
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..
Looking at the source code for the 'Advanced' tab I find in line 44-46 the following:
var dieFreqTemplate = $('');
$.each(config.valid_die_frequencies, function(i, frequency) {
dieFreqTemplate.append('');
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?
var dieFreqTemplate = $('');
$.each(config.valid_die_frequencies, function(i, frequency) {
dieFreqTemplate.append('');
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?
@ 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?
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?
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.
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?
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?
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
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 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
Contemplating using the recovery file now
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 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
Quote
cmd=$(printf "0x86,0x%02X,0x01,0xF1" $c)
to this:
cmd=$(printf "0x86,0x%02X,0x02,0x11" $c)
to this:
cmd=$(printf "0x86,0x%02X,0x02,0x11" $c)
Will I have to roll back firmware or is there a new edit ?
Is safe to go at 1000 .?
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 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.
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 -
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 -
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
is too high? 
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
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
Jump to: