Hacking The KNC Firmware: Overclocking

[pedrosoft]

sorry 

[1713570011]

1713570011

[mekadeka]

Temen, sent you a modest something.

Updates for folks OC'ing October Saturns in particular (because it seems there are differences):

I tried 265 on a machine running 0.99.1-tune. This seems to have netted me the best hashing results so far, FWIW.
EDIT: At about 340ghs right now with low pool rejects. Best I could do with 211 (the next best) was around 311.

Temen or anyone else, why would 265 work particularly well? Can anything be extrapolated from this particular clocking? I've tried a slew of them, and this FW (0.99.1-tune) are the best for me so far. I did not make any tuning changes, nor did I use wizkid's cgminer, nor do I have bertmod in place right now.

I know that 265 itself is faster than 211, but that's not all of it. I tried a bunch faster than 211 (221, 231, 241, 251, 305), and none worked as well as 265. I don't know for certain if 0.99.1-tune was on each of those, however, which is what I'm using right now.

Can anything be told from the 265 clock setting? Can I set it a logical multiple up from here? (Sorry, I really do not know anything at all about OC'ing. Apologies.)


Thanks!

[FeedbackLoop]

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!

[mekadeka]

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!

Hi, feedback. Yes, I am measuring at the pool, too. Currently, the miner GUI is showing 341gh. Cgminer is showing 338g/341. The pool is showing 316g with .13% rejects. I have not looked at the error rate on cgminer yet to see if it fills the gap. Instead, I am going to reset the pool worker's stats, since I have some things to do this morning. I'll report back.

[temen]

mekadeka, thank you! Thats my first ever donation received, gonna put it on the wall=)

I think the consumption is part of many different parameters. I would love to lower the volts. That 265 might just "fit" in between clocks etc. Like somekind of "best time to open transistor gate, capacitance pumped full just before" etc.

Setting 5D6 works for me also, just has to be restarted many many times before it "catches" that=). It has somehow lower poewr consumption and it settles for 450gh/s after a while. I tried with 5E6 and 5F6 but even initially showing fast hash-rate it always settles to 450gh with this.

Before i used to have that 340gh/s as a norm. Then installed 3.8.5 and once i noticed that when starting and immediately with screen -dr seeing what happens it started right away like 2 times faster, then got up to 4 times and after that initial sequence it settled for 370gh/s.

If i want to get better gh/s even with 305, I have to start many times, best result is when initially on the screen there is reading like 700+ gh/s, after that if shows 1,68 th/s and then fluctuates between 500-700 gh/s for moment. Then it settles to 459 (cgminer) which on the poolside shows 488 =) Not normally that much but now it seems to be that.

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

[tolip_wen]

@temen

What speed is each 'die' running at?
(48 core per die, 4 die per ASIC)

clock settings ending in 5 are likely the same as ending in 1
The last digit is the divisor but may only recognise lowest 2 bits


ie: 265 prolly the same as 261 (975MHz)

I'm prepared to be proven wrong but need die speed to do so!

YMMV

[tolip_wen]

It was asked earlier the location of the temp measurement IC

It is located straight in from the ribbon cable connection at the corner of the ASIC package.

Repeating.........

The corner of the ASIC is not an ideal location (it is cooler at the corners)
The ASIC is easily 10C hotter than the temp chip.
I measured back side of PCB and see higher temps.
(measured both IR (gun) and direct contact thermocouple)

The VRM's are WAY hotter than the temp chip on both sides of PCB.
The VRM's are designed for airflow in the direction of inside to outside (as placed by KnCMiner) FWIW

Don't forget you need some air to flow UNDER the PCB too, it is a heatsink also!


Thx for thr thermal pics!

YMMV

[temen]

@new_pilot: Where would I be able to see die speed on november unit? Can i just run october tuning with november unit or what to do?!

Just tried setting 301 (changed the last to from 5 to 1 ) It start hashing at the same rate, if a hint less ie like 459gh with 305 and 450gh with 301. It was short test but tolip is correct i think.

I think i need to start lowering that 12V input voltage to asic-vrm as to lower the power consumption in them 

[crashoveride54902]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

[ImI]

Whats more important for the safety of those VRMs? Ampere or Watt?

I have one VRM with 60A and 46Watt.

[idee2013]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

i don't get it. how did you use bfgminer for the stats for each asic and had the possibility to try the 251 settings. After flashing bertmod 0.4 for the use of bfgminer the cgminer.sh is an other. and after changing the volts all amp are droping(wellknown) and than it is not possible to change the values in cgminer.sh and restart bfgminer.

[Biffa]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

i don't get it. how did you use bfgminer for the stats for each asic and had the possibility to try the 251 settings. After flashing bertmod 0.4 for the use of bfgminer the cgminer.sh is an other. and after changing the volts all amp are droping(wellknown) and than it is not possible to change the values in cgminer.sh and restart bfgminer.

1. Make a copy of cgminer.sh before you install bertmod in your /config directory. Use that to modify and stop and start the miner.
2. Don't use Bertmod for bfgminer, use the latest firmware from KnC it has bertmod installed.
3. You will need to search for a modified cgminer.sh to use after you installed the latest firmware, it works with both cgminer or bfgminer to add back the overclocking parts of the script. There are a few floating around in this thread I believe

[pedrosoft]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

ok 251 is very high for october ? Could you please tell me you spi settings with frequency ? ( screenshot please ?)

[idee2013]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

 Could you please tell me you spi settings with frequency ? ( screenshot please ?)

+1

[idee2013]

1. Make a copy of cgminer.sh before you install bertmod in your /config directory. Use that to modify and stop and start the miner.
2. Don't use Bertmod for bfgminer, use the latest firmware from KnC it has bertmod installed.
3. You will need to search for a modified cgminer.sh to use after you installed the latest firmware, it works with both cgminer or bfgminer to add back the overclocking parts of the script. There are a few floating around in this thread I believe

ok, did not see this option in 99.2 ..thank you!

[crashoveride54902]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

ok 251 is very high for october ? Could you please tell me you spi settings with frequency ? ( screenshot please ?)

yes 251 very high...have 10 fans cooling it and still have have amps...my spi volts are 3.3 and the freq is 201442

after running it all nite...pool reported as high 723gh and cgminer avg settled at 714...thinking about trying the next step up or 261 but idk...amps are pretty high on one board

[ImI]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

shouldnt WATT be more important as A? in the end its the wattage that leads to temperature.

[pedrosoft]

If the gh-speed doesnt start initially from high value, then miner settles down to lower value. This is strange but perhaps there is some "initial modification" done on cgminer that sets the rate for rest of the session.

Sometimes i have to restart like 10 times to get this "high catch" effect. Its pain to wait in between, because without delay you just get fault 96/97 on vrms. Which means restarting the miner from the page (I dont like to switch off power but had to do that some times)I always wait like at least 45 seconds if vrms have been running for a while to let them cool down.

I've noticed that too, but my unit almost does it every time...if you mess with the spi freq. that can do it i think...cause i just increased mine and it didn't do it anymore...went back to stock and it did it again...

well on 251 with oct. jup...thxs to the graph i was able to finally get the hw error down to .4% and 718-723gh/s on cgminer, bertmod says 700w same as 241, but that was before better cooling fans added...have one board at 240a :O hope it doesn't fry..and also 1 board at 200a but its at 42c Hopefully pool will report higher hash now that i got the hw % down i'll know morrow morning

ok 251 is very high for october ? Could you please tell me you spi settings with frequency ? ( screenshot please ?)

yes 251 very high...have 10 fans cooling it and still have have amps...my spi volts are 3.3 and the freq is 201442

after running it all nite...pool reported as high 723gh and cgminer avg settled at 714...thinking about trying the next step up or 261 but idk...amps are pretty high on one board

You are my hero

1) have you changed the settings of the individual die (more volts ?) ?

2) or just general spi ? (in addition to frequency)?

3) How many amps and watts marks every single day? With a cooler master V850 can set the miner to 251 according to you?

Now I have 666 average with 231 setting  (3.3 spi and 256 k freq) with october jupiter and 4 45 degrees fans and 1 megaflow

[proclivity]

shouldnt WATT be more important as A? in the end its the wattage that leads to temperature.

In a "normal operating range," yes.. but as you get to the design limits and beyond, it is the current that makes a board melt, not a watt.

For example - properly insulated, you could push 40,000V at 1A through a thin wire, getting 40,000W in the circuit, and the wire would live.
But if you reduce to 1V and tried to get 40,000A through that same wire, the wire wouldn't live.

That's why power distribution lines run at a very high voltage, to keep the current within the wire's limits. Hope that helps.

[ImI]

shouldnt WATT be more important as A? in the end its the wattage that leads to temperature.

In a "normal operating range," yes.. but as you get to the design limits and beyond, it is the current that makes a board melt, not a watt.

For example - properly insulated, you could push 40,000V at 1A through a thin wire, getting 40,000W in the circuit, and the wire would live.
But if you reduce to 1V and tried to get 40,000A through that same wire, the wire wouldn't live.

That's why power distribution lines run at a very high voltage, to keep the current within the wire's limits. Hope that helps.

thx!