(so before luke implement the mechanisms to automatically disable and re-enable problematic cores),
I haven't looked at that implementation yet
here the link to the commit that introduce automatic en/dis core algo:
https://github.com/luke-jr/bfgminer/commit/8b690959dd4b107010217289fa69da82889e63cfquoting comments:
+ If a core gets 10 HW errors in a row without doing any proper work
+ it is disabled for 10 seconds.
+
+ When a core gets 10 HW errors the next time it checks when it was enabled
+ the last time and compare that to when it started to get errors.
+ If those times are close (50%) the disabled time is doubled,
+ if not it is just disabled for 10s again.
I have done similar test runs like you, and it is nice to just leave off the really bad ones and just keep on the rest, but it is also a wonder if even a 70% HW error core isn't worth just leaving on since it still provides 30% valid work
Does one terrible core effect another? Do HW errors tax the control unit?
hno on kncminer irc said that there colud be some kind of tourbolence, a sort of bad interaction between good cores and bad one if you keep the latter enabled.
anyway this morning (UTC) I've discovered that my miners were running cgminer since sunday morning due to a temporary glitch in the power line at the colo that makes the miners restart. As soon as I realized that I've checked the cores status and guess what... all cores were enable again. this is strange.
Just after that I've stopped cgminer and restart bfgminer and after 12hs I get almost the same performance.
If KNC would sell extra control units I would play around with a bad module but I am done taking downtime setting up different tests. At some point I will RMA a few problem modules.
I do agree. It would be fantastic, imho
If you have good hardware you can run .96 at very nice Gh
I will give it a try, but I don't know if I really have good HW. I had a dead die on a asic slots for each machine. I was able to bring it back using Enablecore.bin on 0.95. This improved my hashrate at the pools from 480 to almost 520Gh/s at the pool.
I've tried 0.97 on one of them but the higher hastrate was balanced by a way higher HW error rate (10-15%)
I put 4 of my best modules in one miner and get 545-565 on avg at btcguild
wow it would be good to gain another 25Gh/s per jup.
This is the list of the thing that I've to try next:
- (SW) ckolivas cgminer version
- (SW) bfgminer automatic en/dis mechanism
- (SW) test 0.96 to really see if I could gain another 20GH/s
- (HW) mod the heatsink fans as you did (lowering them)
- (HW) add two small fans in the front to improve the intake at BBB/VRM level
- (HW) improve the VRMs airflow take into account what "The Avenger" share here:
https://bitcointalksearch.org/topic/m.3375668 maybe using something like trepex did here: