Hacking The KNC Firmware: Overclocking

[wizkid057]

On the November unit I have for testing, disabling work flushes in the cgminer source and running cgminer with -q -T gives me the following stats:

(5s):731.0G (avg):681.2Gh/s | A:88420915  R:1590264  HW:133439  WU:9414.2/m

Comes to ~0.15% HW errors.  Pool side 3-hour rate is 670Gh.  Disabling flushes causes an increase in rejected shares, but this seems to be far less of a loss than the false HW errors.

Basically, flushing is broken in all current firmwares it seems.  There is also a false HW error issue in the cgminer driver that was partially fixed in this commit to their cgminer fork.

I'm currently working on a fresh rewrite of the driver.

Just figured I'd throw this out there somewhere.

-wk

What was this Jupiter reporting at the pool for a 3-hour before this change? Any chance you would be willing to share the build? Would like to shake it out some on one of my Octobers..

~650Gh-ish and would steadily fall.

Binary I made that works on the november unit I have for dev, untested on prior units (but should work): http://vpn.wizkid057.com/nas/cgminer-binary-wizdev20131222

-wk

[1714125911]

1714125911

[1714125911]

1714125911

[1714125911]

1714125911

[1714125911]

1714125911

[1714125911]

1714125911

[padrino]

~650Gh-ish and would steadily fall.

Binary I made that works on the november unit I have for dev, untested on prior units (but should work): http://vpn.wizkid057.com/nas/cgminer-binary-wizdev20131222

-wk

Thanks for posting.. Gave it a shot on my October.. Spewing out 6-8 HW errors per second on the console.. The hash rate on the pool settled about 10% less than it was before so I reverted back..

Interesting experiment, I assumed the performance would be similar to yours but I guess there are more differences between October and November than I would have first guessed.

[sickpig]

On the November unit I have for testing, disabling work flushes in the cgminer source and running cgminer with -q -T gives me the following stats:

(5s):731.0G (avg):681.2Gh/s | A:88420915  R:1590264  HW:133439  WU:9414.2/m

Comes to ~0.15% HW errors.  Pool side 3-hour rate is 670Gh.  Disabling flushes causes an increase in rejected shares, but this seems to be far less of a loss than the false HW errors.

Basically, flushing is broken in all current firmwares it seems.  There is also a false HW error issue in the cgminer driver that was partially fixed in this commit to their cgminer fork.

I'm currently working on a fresh rewrite of the driver.

Just figured I'd throw this out there somewhere.

-wk

thanks for sharing wk!

Flushwork has been the weakest point of knc cgminer driver since the beginning. Just drop us a line when
your rewrite will be complete. 

[sickpig]

Just to share my settings/performance:
- October unit (Asic 1 = 4 VRM, other 3 are 8 VRM but only 4 active)
- Firmware 0.99-tune
- Clocksetting on 231, no other firmware changes.
- Harware mod: Lowered the Asicboard-fans (more airflow over the board), added 2 fans at the outlet (so now push + pull) and slightly lowered fan speed to reduce the noise (80%).

Images
Status page --> 676 GH/s / 9131 WU
Advanced page --> 2.5V SPI and 256kHz frequency, slightly modded volts (higher, as required for the increased clock), not completely fine-tuned.
CGminer --> Error rate used to be 3%@560GH/s, since I lowered the volts a bit after the initial increase this increased to just below 4%. Fine with me as it lowered the temps 5-10 degrees an decreased power to 'around' 40 W per DC instead of closer to 50 W.
Pool stat  --> 650ghs average
Power consumption in bertmod used to be 453 W, now it is 651 W (43% increase in consumption for 18/19% performance increase). With voltage finetuning the power consumption should be able to come down a bit, now it is all pretty much on the safe side (safe as in: higher voltage as required to avoid that cores get shut down).

thanks for sharing your configuration!

I've just bump up the OC to my miners, not as far as you did, though

I've different OC setting for each asic board. The hotter they run in the factory configuration the lower the OC. So I've the two front asics using the 201, left-rear using 211 (additional side fan, 80x80, pushing air unnder the main sink), right-rear using 1F1.

For the SPI i'm using 2.05 V, 299707 Freq.

I've found that to lower the hasrate under 5% I need to rise the voltage per die to get at least 35-6 Watts for each VRM.

With this setting I get a WU of ~ 8400 and an error rate of ~ 4%.

The next thing I want to try is lowering the Asicboard-fans, adding another small lateral onf the right-rear board and the pushing the OC settings higher for all the boards.

[Ghrindy]

Best settings so far for my oct jupiter (4 VRM):

FW: 0.99.1-tune (oct)
OC: 231
Advanced tuning: None (default from stock version) see "Other findings"

Before OC:
Avg.HR: 560 Gh/s, poolside: 520-530 Gh/s
WU: 8045
HW err%: 3%
Pool rejects%: 0.6%
Watts: 550 W (bertmod)

After OC:
Avg.HR: 650 Gh/s, poolside: 620-640 Gh/s
WU: 9083
HW err%: 5-7%
Pool rejects%: 0.9%
Watts: 680-690 W (bertmod)
ASIC1: 56.0 ℃ , avg 53 Amps
ASIC2: 42.0 ℃ , avg 52 Amps
ASIC3: 61.5 ℃ , avg 56 Amps (highest die: 61 Amps)
ASIC4: 51.5 ℃ , avg 54 Amps

Other findings:

I've played a lot with the Advanced tuning part with different SPI volt,freq and individual die-voltage settings.
The 'trick' is to get the Amps between 50-55 for ultimate power/Gh ratio (correct me if i'm wrong).
After days of experimenting it came down to what hno (from irc) once said: it's like chasing ghosts!

At the end the default-settings for Advanced tuning works best (for now), BUT after playing with those
settings, and at the end setting all the Advanced tuner settings back to original values(manually) resulted in the worst performance of 250 Gh/s and the only remedy was to reflash the FW.
I'll play again with the settings after next diff change.

Btw, a lot of thanks to all contributers in this thread and to iterate Cablez's remark:
"Wonderful thread gentlemen, really shows the pioneering spirit of the mining core. Thank you."

and last but certainly not least: OP (1NT4RyJMqtRuDRr6zHdXdKSpmX3SR5he6z) and tolip_wen (13362fxFAdrhagmCvSmFy4WoHrNRPG2V57) !

[PaulyC]

This is a bit odd, i tried running the SED command and when it rebooted CGminer it prompted me to enter the pool credentials etc... I rebooted the miner and now cgminer and now i am getting some CGminer errors related to pool credentials etc?  Any ideas?

Edit: Very odd, eligius works with this mod, but bitminter does not.  Perhaps it has something to do with the pool credentials?  Anyone have any insight?

Edit2: Bitminter pool seems to be back up using original unmodified file.

There's absolutely no possible way that the sed command (if run on cgminer.sh) would have altered your pool credentials in any way. Is it possible that you ran sed against cgminer.conf instead?

Nope - no possible way.  For some reason, it takes 5 minutes or so for CGminer to figure out that the bitminter pool is alive.  Eliguis works perfectly well right at bootup.  After about 10 minutes of mining, CGminer will revert back to the bitminter pool once it verifies that it is alive.

In summary - For those of you running on bitminter, please configure a backup pool in the KNCminer web interface ( i had only configured mine in the cgminer.conf file) BEFORE running this command.

Just wanted to remark that I had this exact same problem, running sed command, but with BTCguild..  not until changing back to the original .sh, then the quota came back to "alive" but was "dead" for awhile and couldn't change with the sed version. I tried many things and just assumed the pool died at the exact moment I ran the command, but thought that was somewhat coincidental. heh.
my failover backup pool was Eligius too. worked fine with sed.

Anyways... interesting.

[sickpig]

(remove a lot of useful info)

At the end the default-settings for Advanced tuning works best (for now), BUT after playing with those
settings, and at the end setting all the Advanced tuner settings back to original values(manually) resulted in the worst performance of 250 Gh/s and the only remedy was to reflash the FW.
I'll play again with the settings after next diff change.

it's quite peculiar.

in my experience an overclocked die need more voltage to keep the number of disabled cores low.

e.g. on my 211 asic board I get at least 20 and 15 cores disabled in the first and the third die respectively if I left the same voltage settings used for 1F1. I had to set it way higher to get almost all cores enabled, and after that another bump has been  necessary to lower the error rate.

Speaking of power consumption:  all dies across the boards are between 45 and 49 Amps. I have different OC settings  for each board. The higher is 211 the lowest 1F1 and I've noticed that despite the OC settings and factoring out the voltage settings, the 4th die of each board is the one that drain more energy. 

[padrino]

(remove a lot of useful info)

At the end the default-settings for Advanced tuning works best (for now), BUT after playing with those
settings, and at the end setting all the Advanced tuner settings back to original values(manually) resulted in the worst performance of 250 Gh/s and the only remedy was to reflash the FW.
I'll play again with the settings after next diff change.

it's quite peculiar.

in my experience an overclocked die need more voltage to keep the number of disabled cores low.

e.g. on my 211 asic board I get at least 20 and 15 cores disabled in the first and the third die respectively if I left the same voltage settings used for 1F1. I had to set it way higher to get almost all cores enabled, and after that another bump has been  necessary to lower the error rate.

Speaking of power consumption:  all dies across the boards are between 45 and 49 Amps. I have different OC settings  for each board. The higher is 211 the lowest 1F1 and I've noticed that despite the OC settings and factoring out the voltage settings, the 4th die of each board is the one that drain more energy. 

I suspect the variability in the quality of the boards has quite a bit to do with it.. It's a crude comparison but that same challenge exists with CPU or GPU overclocking... I say crude because in those cases you are talking about millions of parts, but the same core concepts hold, variability in ASIC quality and quality of a given board build being two of the most important things.

[gateway]

I applied

Code:

sed sBD1BC1B </etc/init.d/cgminer.sh >/config/zzz.sh ; /config/zzz.sh restart

And bumped up a bit of hashing rate, My Oct Jup never had any die issues and seems to run great.. I see people mention 211 and 231.. is their a single line sed command for these?

[CYPER]

I applied

Code:

sed sBD1BC1B </etc/init.d/cgminer.sh >/config/zzz.sh ; /config/zzz.sh restart

And bumped up a bit of hashing rate, My Oct Jup never had any die issues and seems to run great.. I see people mention 211 and 231.. is their a single line sed command for these?

No.

[gateway]

I applied

Code:

sed sBD1BC1B </etc/init.d/cgminer.sh >/config/zzz.sh ; /config/zzz.sh restart

And bumped up a bit of hashing rate, My Oct Jup never had any die issues and seems to run great.. I see people mention 211 and 231.. is their a single line sed command for these?

No.

Here is my current zzz.sh file..

http://pastie.org/private/f5ywbvozimw4ritvdamzg

[CYPER]

I applied

Code:

sed sBD1BC1B </etc/init.d/cgminer.sh >/config/zzz.sh ; /config/zzz.sh restart

And bumped up a bit of hashing rate, My Oct Jup never had any die issues and seems to run great.. I see people mention 211 and 231.. is their a single line sed command for these?

No.

Here is my current zzz.sh file..

http://pastie.org/private/f5ywbvozimw4ritvdamzg

I don't see any overclocking values in this file.
You seem to have installed Bertmod, which replaces the original cgminer.sh file with a new one, that does not have the 0x86 value needed for overclocking.
And then using the sed command you have created a copy of the new cgminer.sh file.

[rico666]

Hi,

so after the recent difficulty changes, I thought of past times when 3 of my November Jupiters could do easily 1,5 BTC a day, then 1,1 then... right now it's 0.9 BTC for all 3 give or take some pool luck. So I would like to test safe limits - some 10% increase of hashrate would be great.

As far as I understand this thread, it's mainly about October Jupiters. While I could rise frequency, I will have trouble raising voltage, as I do not have the 0.99-tune FW.

While I do have significant Linux experience (and feel on the BBB like home), I'm quite a chicken when it comes to potential toasting of not inexpensive hardware. Is someone here who has tried the OC on a November Jupiter with or without changes to DC/DC voltage?

Or the other way round: How do you adjust voltage on November Jupiters? I have no "Advanced" Tab in my FW.


Rico

[rico666]

For anyone still wondering how to get bfgminer + overclocking the easiest way is to install bertmod and then make a copy of the cgminer.sh:

Code:

cp /etc/init.d/cgminer.sh /config/bfg1.sh

Then you need to edit the newly created file by:

Code:

vi /config/bfg1.sh

Delete everything by pressing this on your keyboard: 120dd
Make sure all text is gone.
Then press i and paste everything from this into your file: http://pastebin.com/fFCWngnq

All this seems quite kludgy to me. You are copying a file just to delete all its contents and then paste something from somewhere.

To start out with an empty file, use the command "touch"

Code:

touch /config/bfg1.sh

On the other hand if you simply give vi a file that doesn't exist, the editor will create it for you.

Code:

vi /config/bfg1.sh

But why fiddling around with editor at all and copy and paste, when KnC gave us a great linux distro within the Jupiter?

Enter the wget command!

Code:

wget -O <FILE> <URL>

Fetches the content from the URL and writes it to file FILE.


Rico

[CYPER]

Hi,

so after the recent difficulty changes, I thought of past times when 3 of my November Jupiters could do easily 1,5 BTC a day, then 1,1 then... right now it's 0.9 BTC for all 3 give or take some pool luck. So I would like to test safe limits - some 10% increase of hashrate would be great.

As far as I understand this thread, it's mainly about October Jupiters. While I could rise frequency, I will have trouble raising voltage, as I do not have the 0.99-tune FW.

While I do have significant Linux experience (and feel on the BBB like home), I'm quite a chicken when it comes to potential toasting of not inexpensive hardware. Is someone here who has tried the OC on a November Jupiter with or without changes to DC/DC voltage?

Or the other way round: How do you adjust voltage on November Jupiters? I have no "Advanced" Tab in my FW.


Rico

I don't think you can overclock November Jupiters. They are already maxed out.

All this seems quite kludgy to me. You are copying a file just to delete all its contents and then paste something from somewhere.

Because I am no Linux guru and do things as I can, helped by Google

[rico666]

I don't think you can overclock November Jupiters. They are already maxed out.

What? With every VRM running at a modest ~20 Watt?

and

Total DC/DC power output: 663 W

according to Bertmod?

KnC said something about a 1200 PSU to unleash the full potential of November Jupiters. So far, my Jupiters have been running on 850W PSUs like nothing (~800W at the wall).

So I certainly hope to redefine "maxed out". ;-)


Rico

[gateway]

I applied

Code:

sed sBD1BC1B </etc/init.d/cgminer.sh >/config/zzz.sh ; /config/zzz.sh restart

And bumped up a bit of hashing rate, My Oct Jup never had any die issues and seems to run great.. I see people mention 211 and 231.. is their a single line sed command for these?

No.

Here is my current zzz.sh file..

http://pastie.org/private/f5ywbvozimw4ritvdamzg

I don't see any overclocking values in this file.
You seem to have installed Bertmod, which replaces the original cgminer.sh file with a new one, that does not have the 0x86 value needed for overclocking.
And then using the sed command you have created a copy of the new cgminer.sh file.

Yep thanks, bingo, the bertmod removed the OC stuff in the cgminer.sh config.. TeknikL helped me out on the #kncminer channel.. I was like WTF where are my settings

cheers

[gateway]

so here is what my amps and volts are now at 211.. on a oct jup..



Using this file 211.sh http://pastie.org/private/tbqcfjkyh8pzwzjjiwhvda

These two high? should I take it to 210 or 209?

[CYPER]

so here is what my amps and volts are now at 211.. on a oct jup..

Using this file 211.sh http://pastie.org/private/tbqcfjkyh8pzwzjjiwhvda

These two high? should I take it to 210 or 209?

According to hno (engineer from KNC) we should not go above 50A per VRM/die and 200A per board.
According to Bitcoinorama (KNC Tech Communications) it is safe to go up to the firmware built-in limits, which are 64A per VRM/die.

There is no 209 or 210. Check the topic for available values.

[DPoS]

so here is what my amps and volts are now at 211.. on a oct jup..

Using this file 211.sh http://pastie.org/private/tbqcfjkyh8pzwzjjiwhvda

These two high? should I take it to 210 or 209?

According to hno (engineer from KNC) we should not go above 50A per VRM/die and 200A per board.
According to Bitcoinorama (KNC Tech Communications) it is safe to go up to the firmware built-in limits, which are 64A per VRM/die.

There is no 209 or 210. Check the topic for available values.

Remember we were all running well over 50amps the first week with our 4VRM miners. 

Oddly I found that my usually flaky miner really likes that sed command and is happy with ~760Gh poolside (5 boards, 1 an 8VRM)

But my more stable miner doesn't really like it and seems to just float down by itself (amps/watts go lower) and poolside goes lower than what it was running 98 beta

So I will probably try some of the more high OC ratings on that one since most of the boards are pretty sound and was a miner that ran over 50amps for many weeks in Oct