I'm not so sure that's the case.  Looking at my one module I see what I think is an empty VRM spot near the "1" and there is a row of caps there.

KnC 0:  | 149.8G/138.1Gh/s | A:499611 R:33063 HW:39437 WU:2197.4/m

The above line is the best I've had yet and Slush is showing the miner doing 137.2GH/s.  I'm hesitant about shutting down a well working machine to add tantalum caps to the 12 rail on the module.  If it improves and I can use as a result 0.95 or 0.96 and drop over 100 watts at the wall, I still won't get any higher hash or WU than I'm getting right now.  Let's see, what's 100 watts costing me per month, (100watts)(24hours)=2.4KWhours/day.  30.5 days a month that's 73.2kw/month.  $0.075/kw * 73.2 = $5.49.

Thanks.  Then it may be the voltage in filtering.  Building a buck converter to drop voltage from 16.5 to 12 for a zTex, the requirements were a low ESR cap very near the input leads of the buck converter.  So, the 12v in rail has low ESR capacitors that remain in place even tho the VRM are turned off.

We have the 4 empty VRM slots with pads to which we can solder tantalum caps to the 1v rail.  The 12v in also has filtering and could use some too.

Are those tops snap on?

I mashed the ignore button.

Okay, back from the run.  Some thoughts.  Stick-on heatsinks/finned-heat-dispersion squares onto the VRMs so they lose heat more easily.  Perhaps as the VRMs heat an internal oscillator drifts away from it's best frequency like if internal caps change value.  And just before getting home the thought occurred to me that if the 8VRM boards are better than the 4VRM boards even tho half the VRMs are turned off, then it's because the 4 off VRMs have internal output filtering that is still attached to the 1 volt line.  Find a nice access point for that 1 volt rail or across the ground and 1 v output pins of the VRMs on the 4 VRM boards and solder tantalum caps.

Look, the cardboard goes from the metal bottom to the angled edge of the front.  Air pushed in by the front fans can only go out the sides but pushes down on the BBB at the same time.  Experiment.  If you're not running a Mercury then my arrangement ain't best for you.

Ha! New high avg hashrate:  KnC 0:  | 163.9G/137.2Gh/s | A:133086 R:10263 HW:10757 WU:2191.8/m

No, the broken cup is gone.  Trying not to dwell on that.  It's unhealthy.

I don't quite understand what you mean.  Your heatsink fans seem positioned same as mine although my single module is up front right.

All you'll see is the cardboard tucked under the module and tucked under the 90° angle of the front top.  There is a crease in the cardboard.  Unless it's you want me to search the cardboard from some indication that it was what my Jalapeno and broken coffee cup came in?

Now I recall, Avenger, embroiled in heated exchanges.  Are you with BFL?

Excuse me but I've got to get in some running with my dog.  A slow 7+miles RT to a nearby highway I think.

https://docs.google.com/file/d/0B_DLmNkCkkVpZGRTV1NvTzhOMEk/edit?usp=drive_web
https://docs.google.com/file/d/0B_DLmNkCkkVpRDVFTTZ4TGp0MkU/edit?usp=drive_web

Remember, this is just testing conditions and this will be much neater after I figure out what I need to do and button up.  Might take a while to get the connectors to relocate the BBB tho.

 KnC 0: | 171.1G/136.0Gh/s | A:77511 R:6588 HW:6205 WU:2187.4/m

The one core that was down came back on and all 4 at 100%. 

So, Google drive, allow anyone to view, paste the address between the image not-image ?

Ha! ran awhile and it's back to all four at 100%!

Back to 0.94, enablecores.bin run, have 100% cores for a few minutes then one core goes off.  Same die all the time.  Since the low voltage of the 0.95 lost such a high percentage of  cores, and since I've had the Vin adjusted to 11.7v yesterday and today, I adjusted it up to 12.0 and found the same failure; then adjusted it down to 11.5v and again after a few minutes it drops from all cores 100% to 1 core off at 97.9% of die 3.  It's right up to above 131GH/s avg. so I'm going to let it be at 11.5v, 180w from BertMod, 269½watts at the wall.

Wow, not settling out at all.  Back to the failure to reach 100GH/s and it had started out with 100% cores.  I know from experience that adjusting my Vin, for an hour at 10v and later an hour at 12.5 Vin that it doesn't effectively get above 99.5GH/s while pre-0.95 firmware can allow me >130GH/s but at a cost of 162watts more at the wall extra.  So, the 34GH/s more I expect to get will cost me an additional 114% at the wall.  Well, this would be the time to spend that power, maybe not next year when network hashrate will be so high.

Trying the 0.95 firmware.  Not enthused.  Started off with 4 cores 100% but that soon dropped due to the .7volt output of the vrms.  Pretty quickly 23.95% of my cores became disabled.  That's the bad news.  The good news is that my power at the wall dropped from 268watts to 142watts and with BertMod showing 89watts, my power supply efficiency is about the same, 62.6%.  I might be able to tweak by raising my PCIE voltage.  I wait and see how this settles out.

Nah, that can't be right as (4dies)(48cores)(6watts)=1152 watts.

So, at 100%, 180watts/(4dies)(48cores)=.9275watt/core.

When I fuss with my cardboard and fans, I sometimes get a reboot.  Since I run, at the present, without the top, center cardboard cooling the BBB, a 12v fan sitting inside blowing on the left side of the module, another 12v fan outside the case blowing on the right side of the 1 module (Mercury), I added another piece of cardboard to the right of the BBB, to the side and up to the module, taking the air pushed out the side and directing it to the module.  The miner white light came on and off as I moved the fans, perhaps a loose pin in an added fan connector, but it started again right away.  Put Bertmod back but earlier tried the 0.2.1 and found it works well with firmware 0.90, looked at my cores, which I could with the 0.2.1, and earlier their was a single core not up, but now there are four 100% cores and the BertMod says the power change from adding that one core on firmware 0.90 with ~0.9v to the 4 vmr's, was 174 watts with one core down and 180 watts with all cores running.

I suggest, if you're running with the top off, cut a piece of cardboard the width of a front fan, about 5.75" wide, and high enough to abut the front of a front or both front ASIC module(s) and reach under the lip of the top front of the miner, and put it aside.  When the hashrate crashes down, try putting the cardboard between the two front fans so the outside halves are pushing air into the box but the center halves are pushing air down onto the BBB.  I think it's the BBB heating that causes the drop after hours of otherwise good hashing.  If I'm right, when you put the cardboard in place, you can watch the first figure in the cgminer hashrate, that you can view ssh'ing in using putty, immediately rise up.  If I'm wrong it won't.

Yes, and the efficiency looks quite good.  

I see that using 0.90, which I believe uses the most energy and produces a high percentage of duplicate shares that count as rejects, this on a Mercury, using a cheap 12vdc switching supply (the output voltage of which I can adjust) and an inexpensive BBB supply, I'm drawing 259½ watts (174 watts on BertMod) at the wall so it's an efficiency of 67% so that's not great.  Of course the BBB draws and it's 1 BBB to 1 module while with a Saturn it's 1BBB to 2 modules.  

I may be able to increase my efficiency even more by dropping the ASIC PCIE voltage down.  The onboard vrms aren't completely efficient and lowering that voltage might find a sweeter spot.  That's the only advantage of this cheap supply designed for powering a huge load of LEDs, the output is adjustable.  That and its cost, $27.88 free shipping and a few bucks for tantalum capacitors I added.

Still, 600 watts on 2 Saturns, that's 150watts per.  

I'm getting 134GH/s as the final settling point on 0.90 at 174watts on BertMod.  If you're getting 150watts at the wall per then I suspect you aren't getting 134GH/s per avg.  Of course you could be if the efficiency of the later firmware versions is great but I've heard that's at a cost of hashrate.  Eliminating the duplicate shares would have gone a long way to increasing efficiency.  I'll know later today when I go to higher versions of the firmware until the duplicate shares stop.