If you seperate results you can better decide where to focus effort if necessary.
(only mentioned as you posted combined results that average below 3.5)
Seperating down to the ASIC is highly subjective with currently available data.

It is best to tackle worst first and recalculate.
If you take an ASIC out of service for any reason can also measure HW error difference.

Regardless of local miner output, pool speed is final arbiter.


YMMV

3.45 to 3.55 is ~ 2%

2% of 1 day is 28.8 minutes.

If 28.8 minutes of downtime 'gross' 2% you come out even 'net' in a day or two.
(assume days are within same diff period)
From the break even point forward is free of downtime 2% gain.
This ALSO assumes you let the other 4 ASIC idle the whole time you mod.

So I guess it depends on if you need parts also and cost of parts.

Agree, no NEED for the extra 2%, just extend date of (possible?) ROI with 2% less GH/s in calcs.

PLEASE NOTE
You must first subtract percentage of non functioning core from 3.6 to know what is available.
Each 72 sleeping core is 1% off the top.
I have 16 sleepers so <0.25% or ~3.59 possible.
I have <0.7% HW so ~3.56 is expected.
I am within an "RCH" of expected.
From where I am NOW a few minutes of downtime may matter.
From where I WAS my downtime was worth it.

To ever go beyond 3.6 will require a larger percentage of the power budget.
Hot VRM are less efficient and overbuget already.
They are spending 'lifetime' for the interest on loan from 'current bank'.

You may have 10 days uptime on the BBB, I doubt you have 864,000 seconds uptime in cgminer.
You can easily check with
'api-cgminer devs'

Disclaimer:
Decimal points in examples do not indicate accuracy.
They just ballpark approximations.
I have been known to slip a bit here and there but usually round in direction of whatever is worst case.


YMMV

If anyone is interested,
I posted cgminer build instructions in the cgminer thread.
https://bitcointalk.org/index.php?topic=28402.msg7977952#msg7977952

No benefit right now to build yourself.
Only possible benifit is not waiting if KnCMiner updates code before a new FW release.
Unless you want to modify things

As usual

Your
Mileage
May
Vary

I am guilty of not reading 'every' post.
I missed where he got bowed up.
I doubt you would make that up so I'll take it at face value.

If he asked for it game on.


YMMV

I posted build instructions for cgminer on a Nep in the cgminer thread.
If things like that interest you...
https://bitcointalk.org/index.php?topic=28402.msg7977952#msg7977952


YMMV

Please forgive if this has been posted here before.
I admit it is a drive by post, I did not read the whole thread.
I did search, I know similar exists, I blunder on anyways!

How to build cgminer on a KnCMiner Neptune while it hashes

My directory tree is as follows

/config
/config/opkg.cache
/config/other
/config/other/cgminer
/config/other/jansson-2.5

If ya dosent likes it season to taste...

First you need a build environment.
I save the downloaded opkg files for faster reconfig.
(better ways exist but I have not implimented yet, I just wait for reinstall of opkg files)


At this point most compile stuff kinda works.
You can skip the symlinks if you want to modify every Makefile and ./config you will probably ever use
You may need more symlinks  to default program names for other build projects.

The following scripts do not assume symlinks exist

I struggled with errors compiling the jansson-2.5 that comes with the KnC cgminer git.
Operator error is suspected!
I forced my intentions

next need to grab bleeding edge cgminer code from KnC git

Skip this part if my jansson-2.5 challenge was operator error

finally try and build cgminer


If everything worked you should see new 'cgminer' and 'api-example' at the bottom of dir list.

You can run it in place or copy it over the original.
The following will preserve the original as /usr/bin/cgminer.orig and replace existing with new and run it.
This is also needed after reboot to run new cgminer

At this point IF IT WORKS it is running
wait a few for cgminer to start then ....

'screen -r'

same as always
N'Joy!

HUGE disclaimer, above scripts are from memory, cut, and paste.
There may exist errors, I am not gonna rerun it and see until I have too!

YMMV


EDIT
The build stuff is swiped from the README.ASIC in bfgminer.
I did not figure out any of it.

You can check each of the 6 PCIe wires for hot.
If you find one that is NOT hot when all others are it is the problem.
If you find one that is NOT hot when all others are it is the problem.
If you find one that is NOT hot when all others are it is the problem.

You need all 6 PCIe wires working for 'safe' operation.
They should all be same temperature.

Best to change the PCIe cable if you have ONE cool wire in a hot cable.
You could also inspect the cable and look for wires that are not pushed all the way into the plastic connector housing.
If it is a modular PSU look at PSU end also.
Be sure connectors are installed all the way.
PUSH on wires when connecting, PULL on plastic housing when disconnecting.

Most melted PCIe cables I have ever seen were caused by a failure in one of the 6 wires.
If you ever find only 2 melted it is because they did not survive doing work for bad wire.
They tried but failed.
...............................................................................

You might just have a ASIC that uses more power.

YMMV

If your speed is 3.56 just let it run!!!


or
Look on Advanced page for WHY.
If numbers for current(A or I) and power(Watt) go up,
adjust in other direction and retest.

You can also adjust and use temperature as decision variable.
(if that is what interests you)

All ASIC are different.
Some are power hungry.

You may also have PCIe cable that is different.
Did you try different PCIe cable?

YMMV

I adjust voltage in BOTH directions and compare results.
I seek lowest current.
I don't care what the voltage is if the ASIC works.
Lowest current for me is lower voltage.
Lower current is often also lower temperature on ASIC and VRM.
Some die are different.

Yours ASICs could be different.

YMMV


EDIT
lower voltage is more NEGATIVE number (notice the sign in front of the numbers)
Try -0.0439 and see if your ASIC is happy!

yes
I do

YMMV

My 'workshop' is just a wire rack in my kitchen.
I live in a small 2 room shoe.

My main design goal for first stage with the Nep cooling was remote heat exchange.
Another main factor was low downtime.
I built the loop and modded a cube at a time while the other 4 hashed away.

It is very much a temporary prototyping environment.
The Hoopiter had a similar long transition into a neat case.
If they runnin no hurry.

No nightmares. the Nep system is just over 3L of H2O.

YMMV

Just an FYI but It's _my_ credibility you have questioned.
I looked at the parts and reported here as asked.

I HAVE pics but will not provide to you.
Believe me or not, my day remains the same


YMMV

That looks to be a clone of the $300 part.

EDIT
the ebay link is the 'clone'
What you have pictured is more than a clone.
Yours can support newer 20pin JTAG connection standard for SoC devices.
The BBB has a place for the 20pin flavor of JTAG BTW.
It may have an adaptor for 10pin JTAG or just the first 1/2 of the 20 pin connector.
Some can put whatever you want on specific pins thru programming.
The 'standard' says what is needed not where it must be on a connector.
All the correct signals and more are on the 20pin versions.


If it has the correct values in the USB eeprom, Altera Quartus II software will play happily with it.

To use that on FPGA on Nep you need to solder on a 2x5 connector or wires to PCB.
I do not advocate others solder on their PCBs.
You risk possibly killing a Neptune.

I/we do not know if it will produce useful data.
It is merely one avenue  to look.
It could easily be a wild goose chase.

If you already had a program you wanted to load into the FPGA that is one possible tool for the job.
To snoop and see what that program does, depends on if they allow for that in the design.

I stated before it's a $17 fun gamble for me.
I LIKE to spend hours learning new toys and SW.
For others it could be very UNFUN and more expensive gamble.

YMMV

That might be a good thing, I'm playing with sharpened blunt objects.

I know you didn't ask but a twisted overview follows:

A JTAG port is a way of programming Field Programmable parts, testing same, and testing PCB designs.
The Altera Cyclone 4 FPGA on the KnC controller has one of theese.
There is an unpopulated place for the JTAG connector on the power input end of the PCB.

I'm poking around with that using a USB JTAG dongle thingy.
The BBB can also do what the dongle thingy does with a bit of code.
So far I have not looked at a Neptune controller FPGA with JTAG toy.
I have 2 Saturn that will become 1 Hoopiter.
This will leave me with a spare controller.

After I make backups of the Saturn filesystem I'll reflash it and have a spare Neptune controller.
Then I can experiment a bit more freely with lower downtime and slightly less risk.

So far every turn has required hours of research/reading to 'almost' get up to speed with the part, the tool and 'openocd' software.
I had hoped to use the precompiled software the part manufacturer supplies but it is picky about using THEIR $300 tool.
I'll have a $10 clone of that in a week or two.
For now I have a 'flexible' alternative that is not plug and play.
I'm in that rabbit hole still learning.

If this approach fails we can snoop the communications between controller and ASIC.
I figure if the FPGA can filter a request, another micro or FPGA could unfilter it.
We may need to do this anyways(snoop) to identify what in the FPGA needs changed.

I'd also guess there is some way to send a frequency command that is unfiltered.
This would resemble the early 28nm way of OC if it exists.

There is another approach someone can try.
Send a Very Very Very POLITE note to KnCMiner and ask if they would please bump up the speed a notch or two.

Plant a seed!

YMMV

The LM75 measures it own case temperature.
There _IS_ a die in there though.

The original statement may have originated by someone who was wordlexic.
Die(s)/PCB/cube whatever.

I don't rely on that temp for much of anything.
I ALWAYS use the hottest temp I can find for cooling decisions.

As I type...
67C on bottom of PCB directly below ASIC
61C reported by LM75

I IR gunned the PCB temp.
I could probbably find hotter but bottom of PCB's is inside my pentagon with trapped V8 bottle.
It's tight in there and the bottle is not a cooperative captive.
https://i.imgur.com/9T8lRc2.jpg


YMMV

Please forgive me for just answering the fucking question that was asked.

One is an 
LM75
(closer to PCIe)

other is
24C32WP
k348k

It's the i2c EEprom

YMMV

My master plan has been thwarted once again

An AVR Dragon JTAG programmer can program Altera parts.
Programming a part is less complicated than debugging a running part in circuit.

It is _NOT_ recognised by the Altera software that I was going to use to try and snoop.

I threw $17.00 to the wind,
I ordered a clone of the Altera cable.
In ~20 days I'll know if that was wise or not.

The real deal 'cable' is $300 USD. What I want to try may need the real deal.

The whole snooping the FPGA is highly dependent on if they set it up that way.
I gambled $17 that early FW has access for KnC debugging.


Other clock related data.
The oscillator on the ASIC PCB that(I think) the ASIC uses as input reference for it's PLL is 25MHz.
The 28nm has 4 oscillators @ 25 or 250MHz.
I cross-referenced to 250 back when, but now have doubts seeing the 25MHz part on the 20nm PCB.

For the very bold, can try a slightly different osc.
Ideally a freq synthesizer instead of osc. to explore.
One might expect terrible results down that rabbit hole.
If it is the input clock for the ASIC, it's part of a tuned system on the ASIC.

Additionally,
I think the r/c components for the on die PLL are on the bottom of ASIC PCB.
If you examine bottom of PCB closely can see 2 very tiny parts(per die) that do not fit pattern of filter caps.
Again someone very bold can try the 'pencil trick' on the PLL resistors, if that is what they are.
Will need a microscope, VERY SHARP PENCIL, and very steady hand.
(assumes can tell which is cap and which is resistor)

The 'pencil trick' is just using graphite from a pencil to lower resistance on a SMD resistor.
You literally draw across top of resistor with pencil.
Lowering resistance of an r/c circuit speeds it up at a cost of more current.
Slight changes can be too much, it depends on design.
DIfferent hardness pencil can have different result.
It is often easily reversable with spit and finger.

Stalled clocks can be a bad thing!
I DO NOT ADVOCATE changing parts on the PCB!!!
Food for thought though.

YMMV


EDIT:
temporarily unthwarted, got a gizmo that kinda works on the Altera JTAG.
(but not with the Altera Quartus IDE yet)
Must forge some 'USB identification papers' for the thing I think.
Using openocd at the moment. (built in pun in the name!)
Also discovered that KnC made it trivial to do JTAG interfaces WITH the BBB.
('might only' require a cable from one end of PCB to other)

Thx KnCMiner!

The bar is kinda high for my skillset but I blunder on!
Prolly another instance of,
'tolip opens mouth, changes feet'

Another clue emerges!

With the build environ sleepers keep sleeping and monitordcdc ignores them.

I had about 40 hours of uninterrupted goodness from cgminer.
I did find 2 VRM sleeping today and did the stop, waas, restart thing.
cgminer was hashing away and log file nuthin but 'Start'

monitordcdc restarting cgminer is preferred to sleeping die requiring manual intervention.
Provided it brings them all back into production.

YMMV

I have never dealt with a sleeping die. <-(HUGE DISCLAIMER)

If it is VRM related,
AND
the VRM can be awakened,

This might work
------------------------
Stop cgminer.

'/etc/init.d/cgminer.sh stop'

WAIT 20 seconds.

'waas'

WAIT 10-20 seconds AFTER it finishes

'/etc/init.d/cgminer.sh restart'

Give cgminer a minute to get going,
then look for results.

'waas -g all-asic-info | grep I'
--------------------------------------------
look for 2 low current VRM at sleeping die position in resulting list.
It might take 2-3 tries to get all VRM awake.
Supposedly there is a way that the VRM sleeps that needs power cycle to cure.
If this is true and it applies to you get an RMA ASAP!!!
I have never seen it, I have not power cycled in days.
I regularly sleep and awaken VRM with method above.

The above procedure is also needed if you apply changes to freq from Advanced page with FW 1.0.
It often results in sleeping VRM.

As usual
YMMV

nope, no OC by me yet.

If one of my JTAG interfaces is compatable with Altera parts,,,
I'm going to try snooping the FPGA memory thru the JTAG interface.
Low probability of success but interesting.

There may be a way to get past the freq filtr in the FPGA with a raw ASIC request also.
Possibly with a corrctly crafted 'i2cset' command.

If you are just sitting waiting for others to do it,
assume it will not happen.

YMMV


EDIT
MY AVR Dragon (for OC of BFL) and Altera Byte Blaster are compatable with each other.
All I need to do is solder on a 2x5 connector to controller (Jp6).
Here is to hoping the JTAG is still enabled on FW 1.0.
Would not be my first dead end!