You think leave it as it is

Hashing at 640 gh
Code 211

And firmware 1.00

Well the above has finally sparked me into doing what I have wanted to do for several weeks now.

Not every die is going to enjoy being overclocked. Use something like Bertmod to see which dies have disabled cores due to hardware errors. Using the per module, per die script, return troublesome dies to their original clock setting of 1D1 or whatever yours was. There's no strict rules. You have to experiment to see what works best for your machine. If you PM your Bertmod per module stats and your script, I can recommend clock settings.

You need to tune each h board. Send me team viewer details if you would like me to take a look

you'll have to post some pics (and let the miner run for 15 mins first)

what you posted doesnt really make sense

Paste just below line 61 or whichever line the original 0x86 register is at.
Also change if [ $c -eq 0 ] to your particular board configuration.

http://pastebin.com/vy7jppS3

Bfgminer just names your asic 0-3. So working out the control board placement is irrelevant I think. I have not done this so could be wrong though

Bash script is here. Keep the original clock setting on line 61 and paste the script in beginning on the next line (line 62):

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

That script is for a 4 module, 4 VRM machine and assumes you modules are plugged in 0 through 3 connectors on the controller board. Change to your setup. Also, you need to add or subtract the number of module IF statements based on your machine. Mine is a Jupiter+2, so I added 2 additional statements for modules 4 and 5 that are plugged into the controller board.

The 4 die clock settings within each module IF statement assumes 4 VRM. If you have 8 VRMs, add 4 more within each IF statement.

1. Not sure about the diffs in Bertmod versions.
2. I haven't touched Advanced Tuning because I also have no idea what I'm doing there
3. My procedure is the same as yours but you forgot /etc/init.d/cgminer.sh restart after :wq the changes. Don't reboot the machine or you'll lose your changes. Also applying changes at Advanced Tuning wipes changes to cgminer.sh. There's instructions in this thread to make your custom cgminer.sh persist on reboot, but I haven't done it.

I currently get around 920GH/s on a Jupiter+2.

Just my 0.02: I noticed better hash rate matching between the pool and client with cgminer 3.9.0 on firmware 0.99.1-tune. As far as reducing errors, I've had good luck with not overclocking, or underclocking, some dies and overclocking others. Use the bash script that CYPER posted in this thread a while back in order to set per die clock settings. I still use Bertmod ZPM fix to analyze individual module/die performance.

Regarding this wiki-style page...how to realize ?

I'll contribute, but I'd prefer to have all donations flowing to those who risked their hw and shared their knowledge with us in order to motivate such people for the next time we might need them. Writing a guide is no work/value in comparison.

I think it was tolip_wen and temen, in case I forgot one please forgive me and stand up.

To have a custom script executed at boot time, you need to modify/rebuild the firmware (I'm going to do so for myself these days as soon as I'm done I'll post it in here how to do it)
Regarding your 3h question, a simple cron job or some kind of loop with sleeps would do the trick in general.

Suggestion: we move the OC of KnC devices onto a wiki style page, thereby the information can be easily updated, and formed into a readable form. (Unlike ~600 fragments that we all need to interpret and join together each time a new person reads?)

mekadeka, did you measure it at the pool? If you didn't have time for that, which of the numbers in cgminer did you use as a reference?

cheers!