Hacking The KNC Firmware: Overclocking

[CYPER]

So to answer the earlier guys question if 211 is: cmd=$(printf "0x86,0x%02X,0x02,0x11" $c)

Would 231 be?: cmd=$(printf "0x86,0x%02X,0x02,0x31" $c)

Correct.

[1714201085]

1714201085

[1714201085]

1714201085

[1714201085]

1714201085

[1714201085]

1714201085

[joeventura]

231 is risky unless you have your heat and voltage under control.

My units are sitting in a room that is -5 degrees C running 231

Be careful!

[FeedbackLoop]

231 is risky unless you have your heat and voltage under control.

My units are sitting in a room that is -5 degrees C running 231

Be careful!

How dry is the air? Be careful with condensation as well.

[elasticband]

can anybody help me revive a Die 0?

[pedrosoft]

Hit escape

then hit the COLON which is ":"

then type

wq

then

<enter>

where i have to type ? could you please help me (and us I think) with a screenshot?

I'm so sorry, I'm a beginner !

[joeventura]

Hit escape

then hit the COLON which is ":"

then type

wq

then

<enter>

where i have to type ? could you please help me (and us I think) with a screenshot?

I'm so sorry, I'm a beginner !

If you don't know how to SSH into your Miner with PuTTY then there is going to have to be some payment for me to write you a tutorial with screen shots.

Here are the full instructions, hopefully you know how to SSH into your Miner with PuTTY

DISCLAIMER: Not my fault if you blow it up! Smiley


Ok first make sure your Miner is updated with the .99 Firmware (tuning)

Then with Putty SSH into your miner

login with your root ID
and your password

type:

screen -r

You will see cgminer running.

Hit Q to stop cgminer

then type this at the command prompt:

vi /etc/init.d/cgminer.sh

Use the cursor keys on your keyboard to scroll down till you see this code:

Look for the line that says:

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


NOTE: some of the characters at the end (especially the F1) may be different.

The key is the line with the 0x86, when you see that you are on the right line.


change this:

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

to this:


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



Hit escape when finished. Then hit the : key, then x to save and exit


relaunch cgminer with the command line:


/etc/init.d/cgminer.sh restart


You should then see cgminer and you should be hashing between 150-154 per module. (Saturn should be 300-310GH)



NOTE:
If you don't know how to use VI then you can screw things up

here is a shortcut,
when you move the cursor over the 1 in "0x01" that you want to change to a 2, do this:
hit r
then hit 2

and it should Replace the 1 with a 2
then do the same with the F
hit r
then hit 1

Hit escape

then hit the COLON which is ":"

then type

wq

then

<enter>

[Tehfiend]

Great work to everybody in this thread!

I've finally decided to try OC'ing my 8 VRM Jupiter but am not having much luck.  Right now I'm just trying to get 211 working but I get lots of disabled cores. What SPI voltage and frequency are people with 8 VRM's running?

Thanks in advance...

[Ghrindy]

hi i have a October jupiter knc with 0.99.1Tune firmware with 4 vrms, I would like to give OC, but i don't know how to start, could someone help me?

I'm Spanish, I forgive my English.

Have you read through the thread? It tells you exactly what you need to do..

Where exactly???

Here start with this:

DISCLAIMER: Not my fault if you blow it up!

<good summary intructions of joeventura >

give me some address to send for some beers thank you

Besides learning a lot of the KnC machine, linux, voltage-settings(..etc) and OC´ing in general, when you would have read this whole thread, u would've probably noticed fpgaminer, bondus and tolip_wen had a breakthrough post w.r.t OC'ing:  https://bitcointalk.org/index.php?topic=313978.msg3819202#msg3819202 (msg #19)
and tolip_wen 'flooded' the thread with more usefull posts.

Therefore, imho, i would nominate tolip_wen, OP (fpgaminer) and bondus as most entitled for a donation.

tolip_wen: 13362fxFAdrhagmCvSmFy4WoHrNRPG2V57
OP: 1NT4RyJMqtRuDRr6zHdXdKSpmX3SR5he6z
bondus: (where's ur donation address?)

(with all respect to all other contributors in this thread and joeventura for his quick response to your specific question, btw)

[r1senfa17h]

I got bored and started tinkering again. Finally up to 1TH/s! Pulling about 1300 watts at the wall though, so I split the load across two PSUs. I also added a large box fan facing down over the modules and the temps dropped a lot. Some of the DC/DCs are running at ~60 amps, so I'm close to the upper limit. I'm also getting about 1.3% HW errors.

[CeeCee]

managed to get my 4vrm unit to ~625GH/s but as already mentioned before my 8vrm unit is just showing a lot of hardware errors. so i will let the 8 vrm unit as it is. maybe i will try my luck if i have a little bit more time. just tried on both with 211.

and thanks to everyone involved in this thread!

[jtoomim]

Two things:

(1) I tried wizkid057's build of cgminer (3.8.5 with no flushing), and that improved performance on my November Jupiters from about 620 Gh/s to 660 Gh/s at the pool, and brought performance on Eligius up to par with the best I've gotten on other pools. Thanks, wizkid. I'll send a few mBTC to 1StatsQytc as thanks.

(2) I made an attempt at overclocking one of my November Jupiters, and the results were not promising. I tried two things: first, I copied over (with minor modifications) the /etc/init.d/cgminer.sh script from an October Jupiter to the November Jupiter, hoping that I could underclock the Nov to Oct speeds as a proof of concept. The only differences between the Oct and Nov cgminer.sh is the presence/absence of the PLL block of spi-test commands (and maybe some i2c stuff that looks related; can't remember, but I can check if it's important to someone). I used 1D1 for the PLL settings. After I ran this, I saw 5 (or maybe 4, memory is fuzzy) VRMs on the bertmod status page switch from green OK to red FAULT 96 or (IIRC) FAULT 95 on module 0. IIRC, the errors were on the 2nd, 4th, 5th, 6th, and 8th VRMs. The first VRM on module 0 was showing a current of around 40 A, and the other two functional ones were showing around 20 A each, for a total of about 80 A. For comparison, it usually runs 25 A on each of the 8 VRMs for a total of 200 A. The other three modules were normal (OK on the VRMs; no unusual current figures). The miner then proceeded to hash at around 500 Gh/s for about a minute before I rebooted. After rebooting, everything was normal and functional again, and it was hashing around 660 Gh/s. I then tried again, copy-pasting the additions to cgminer.sh that complang used in this thread:

https://bitcointalk.org/index.php?topic=313978.msg4095149#msg4095149

I think I used the same settings (211 and 1F1) as complang. Those additions only changed the PLLs for two of the six ports (both of which I had modules plugged into, IIRC) instead of all four of six. I thought that should be fine, and hoping that I had made some mistake the last time when generating the cgminer.sh, I tried it again. The results were, as far as I remember, identical to the previous instance. Five (or four?) VRMs went into FAULT 96 or FAULT 97. I think it was the same five VRMs, but I'm not sure. I think the second time I saw a FAULT 97 and the first time a FAULT 95, but I'm not sure. I then rebooted about 30 seconds after having started the overclock attempt. Before I rebooted, I again saw a hashrate of around 500 Gh/s. After rebooting, everything was normal.

I do have a second Nov Jupiter, so I could try it on the other one to see if the FAULT errors are per-VRM/module/Jupiter and not a programmatic error, but... I'm a bit afraid to. I'm not particularly fond of smoke, and prefer to only take risks that others would perceive as slightly reckless. I would estimate that the probability of losing a module this way would be about 10%, so I'd be willing to make further tests if people wanted to send me some btc at 1HaBP5xqQaqGdkahEqmAL9iYtUyquoz7u (or put some in escrow to be paid out IFF there's damage) to compensate me for that risk. I can disconnect all but one module so I only risk the control board and one module.

Does anybody here know much about SPI and/or spi-test? My guess is that the first value in $cmd for spi-test is a memory address, the second value is the port number, and the third and fourth are the bytes to be written to that memory address. Perhaps the register addresses changed from the Oct to Nov firmware, and so 0x86 was actually an address related to VRM function instead of PLL function. Does anyone know how to test that, or where I might be able to find the real PLL address if that's true, without losing any magic smoke?


P.S.: I hereby suggest that we name wizkid's no-flushing cgminer build the Broken Toilet Edition.

[sickpig]

Great work to everybody in this thread!

I've finally decided to try OC'ing my 8 VRM Jupiter but am not having much luck.  Right now I'm just trying to get 211 working but I get lots of disabled cores. What SPI voltage and frequency are people with 8 VRM's running?

Thanks in advance...

8 VRMs... so october jup I suppose. When you increase the clock for your ASICs they need more power to work  correctly, so you need to increase voltage settings for each dies. Ideally u should be able to get an idea of what are the dies with the higher numbers of disabled core looking at the Amps comsumption on the advanced tab, the lower the amps the higher the number of disabled  ores, the higher u need to set the voltage for that die. Something near 50 Amps per die is ok.

To get a more accurate idea of disabled  cores you should use bertmod, but pay attention cause it seems to me that it overwrites cgminer.sh.

[Tehfiend]

Great work to everybody in this thread!

I've finally decided to try OC'ing my 8 VRM Jupiter but am not having much luck.  Right now I'm just trying to get 211 working but I get lots of disabled cores. What SPI voltage and frequency are people with 8 VRM's running?

Thanks in advance...

8 VRMs... so october jup I suppose. When you increase the clock for your ASICs they need more power to work  correctly, so you need to increase voltage settings for each dies. Ideally u should be able to get an idea of what are the dies with the higher numbers of disabled core looking at the Amps comsumption on the advanced tab, the lower the amps the higher the number of disabled  ores, the higher u need to set the voltage for that die. Something near 50 Amps per die is ok.

To get a more accurate idea of disabled  cores you should use bertmod, but pay attention cause it seems to me that it overwrites cgminer.sh.

Thanks! Yes it's a "day 2" 8 VRM October Jupiter. I understand the process of tweaking the voltage for each die but still haven't found any solid info on the best SPI voltage/frequency to use. I've managed to get most cores enabled while running 211 but I still get lots of hardware errors and the hashrate reported by the pool is no where near what's reported in CGminer so I'm wondering if there's a problem with the SPI settings but haven't found the sweet spot. Also has the discussion on max safe amps/VRM been settled? I've heard to keep them below 50A, 65A, or 200A total. No way I can get mine stable under 50A so I assume the safe limit is higher...

[elasticband]

trying the above method, but after changing and pushing escape, nothing happens?

[Tehfiend]

trying the above method, but after changing and pushing escape, nothing happens?

Don't forget this part:

then hit the COLON which is ":"

then type

wq

then

<enter>

Hitting escape just exits edit mode so you can enter those commands...

[elasticband]

trying the above method, but after changing and pushing escape, nothing happens?

Don't forget this part:

then hit the COLON which is ":"

then type

wq

then

<enter>

Hitting escape just exits edit mode so you can enter those commands...

I do this, but when i start to type it still edits. It's like Esc is not doing anything

edit: it tells me 'q' is not implemented

[pedrosoft]

trying the above method, but after changing and pushing escape, nothing happens?

Don't forget this part:

then hit the COLON which is ":"

then type

wq

then

<enter>

Hitting escape just exits edit mode so you can enter those commands...

I do this, but when i start to type it still edits. It's like Esc is not doing anything

edit: it tells me 'q' is not implemented

same !

[sickpig]

Great work to everybody in this thread!

I've finally decided to try OC'ing my 8 VRM Jupiter but am not having much luck.  Right now I'm just trying to get 211 working but I get lots of disabled cores. What SPI voltage and frequency are people with 8 VRM's running?

Thanks in advance...

8 VRMs... so october jup I suppose. When you increase the clock for your ASICs they need more power to work  correctly, so you need to increase voltage settings for each dies. Ideally u should be able to get an idea of what are the dies with the higher numbers of disabled core looking at the Amps comsumption on the advanced tab, the lower the amps the higher the number of disabled  ores, the higher u need to set the voltage for that die. Something near 50 Amps per die is ok.

To get a more accurate idea of disabled  cores you should use bertmod, but pay attention cause it seems to me that it overwrites cgminer.sh.

Thanks! Yes it's a "day 2" 8 VRM October Jupiter. I understand the process of tweaking the voltage for each die but still haven't found any solid info on the best SPI voltage/frequency to use. I've managed to get most cores enabled while running 211 but I still get lots of hardware errors and the hashrate reported by the pool is no where near what's reported in CGminer so I'm wondering if there's a problem with the SPI settings but haven't found the sweet spot. Also has the discussion on max safe amps/VRM been settled? I've heard to keep them below 50A, 65A, or 200A total. No way I can get mine stable under 50A so I assume the safe limit is higher...

'Orama a few weeks ago on the main knc thread said you have to increase both voltage and frequency for SPI in case you're OCing. if memory serves my settings for valtage is 2.05, I can't remember the freq value (maybe around 29KHz, I'll check as soos as I'll get back home).

With this value I get ~ 1.5% hw error rate

edit: SPI freq value -> 290707 Hz

[elasticband]

I've heard to keep them below 50A, 65A, or 200A total. No way I can get mine stable under 50A so I assume the safe limit is higher...

My merc is currently doing 160gh/s, but reading the above i am wondering if my Amps are too high?

eddit: reduced the volt on each Die to 0.1135, now its more in line with being bellow 200a total, still getting about 160gh/s

[sickpig]

I've heard to keep them below 50A, 65A, or 200A total. No way I can get mine stable under 50A so I assume the safe limit is higher...

My merc is currently doing 160gh/s, but reading the above i am wondering if my Amps are too high?


https://i.imgur.com/jEqKisR.png

https://i.imgur.com/xZtQmSB.png

don't worry too much. I've seen poeple reporting Amps quitre near to 60 or even above, not to mention their temperature.

I say that 50 Amps per die cause a long time ago on the main knc thread 'Orama said that the ASIC board was designed for a maximum total Amps of 200 (50 x 4 dies). But then again 'Orama quite recently revised the advice saying that we can run our die over the 50 Amps limit.

The fact is that I'm not a risk lover and I want to play on the safe side. But if you think about the how the total net hashrate is growing maybe it's worthy to risk a little bit more now rather than play it safe..  

Another thing that is keeping me from pushing harder is the fact that my miner it's not near my house, my colo is almost 40 Km away and  if something happen I've to drive through there and you know of life is.. work, family and everything... so it's not that I can run away in the middle of the day without any notice in advance.