Ok, one more frustrating issue...
Though this is not an issue with AMT, but with the software being used for mining-control.
The issue:
The number on the screen "Estimated hash-rate", is completely inaccurate, on many levels.
1: Several times the machine is running, it has run with over 50% "device rejections". Screen still indicates hashing-rate as "380 GHs", though the output is obviously only "190 GHs", as seen in the pools. (This is "rejected shares due to invalid, rejected at the RasPi".)
2: Every time, I have "hardware errors". They grow in time... 2 - 7 - 14 - 24 - 36 - 48... Still, the screen shows hashing-rate as "380 GHs", though the output is obviously only about "290 GHs", as seen in the pools. (This is "failed hardware, not responding, not hashing.)
Worst is when I have 50% hardware rejected, and 48 hardware errors, which brings the output to "145 GHs", (290/2=145). Still the screen indicates a healthy "380 GHs". (Not sure if hardware errors are accumulative, or "total", but it seems like a "total", in the final output.)
I am not sure what it is using to get the GHs calculations, but it is not actually calculating them from the output of the machine. Seems it may be estimating based on "single best share", for whatever share is still being hashed. Thus, as long as one fraction of one chip was running, it would indicate "380 GHs", though the output may actually be only "2.3 GHs".
Seems each hardware error is roughly 2.3 GHs, in the state of the cards, which I have. While the device-rejected percent is just a percent of what is being delivered down the chain, from non-failing portions. So, I have to roughly subtract 2.3 GHs for each error, and then subtract the percentage of rejections from the Pi, and then subtract the small percentage of rejections from the pool-server. To determine the "actual estimated hashing rate".
Might be one reason why you guys are having a difficult time "detecting" the failing or failed boards... Prior to shipping. Because the software is essentially fudging the "output" or the "production". (Not sure if this was done on purpose, to thwart the introduction of THs machines into the market, but I suspect it was not done on accident. No-one can be that stupid to have overlooked that, when programming. It had to be purposely reprogrammed, because the program which they made this from, did formulate for all of that. Not AMT, the people who made this web-UI and the RasPi distro. The web-UI has access to that information, obviously, in the logs and output.)
If I had not checked it, I would have run for days, at less than 50%, thinking it was running 100%, as the screen and web-UI indicated.
Sample output from the "LOGS -> CgMiner" page... (Screens indicate "380 GHs". Pool indicates "145 GHs".)
Difficulty Accepted=>169984.0
Pool Rejected%=>1.3
Found Blocks=>0
Difficulty Rejected=>0.0
Device Rejected%=>54.8
Pool Stale%=>0.0
Work Utility=>16.48
Rejected=>0
Elapsed=>2418
Hardware Errors=>85
Accepted=>664
Network Blocks=>3
Local Work=>219307
Get Failures=>0
Difficulty Stale=>0.0
Total MH=>923765860.991
Device Hardware%=>11.3485
Discarded=>3708
Stale=>0
MHS av=>382077.53
Getworks=>64
MHS 5s=>388568.23
Best Share=>131249
Last getwork=>1393148966
Remote Failures=>0
Utility=>16.48
Device Hardware%=>11.3485
MHS av=>382077.53 
(Not even possible with 50% rejects, which should not be counted.)
MHS 5s=>388568.23
Remote Failures=>0
Suggestion...
In the Web-UI, Indicate the "Workload Output: 380 GHs", then the "Valid Output: 145 GHs". Also taking note of "Device rejected: 53%", and "Hardware Errors: 85"...
The screen on the machine should just read "Speed: 145 GHs", not "Speed: 380 Ghs", since that should indicate our "Valid production". Which, if low, we KNOW there is an issue, and can investigate further with the GUI, or reboot, or alert you of an issue before the issue becomes a major device failure. Since, seeming as if nothing was wrong, we would let it keep keep running, possibly burning up the device and causing more "expensive damage", which the MFG would be responsible for repairing. (Just trying to reduce your future potential losses here.)
At the moment, a simple reboot fixes this issue... for the "device rejected" errors. (That too, you could indicate on the miner screen and the web-UI, since you can detect that "error rate", easily.)
Works best if you shut it down and wait 30 seconds, to allow the unit to completely drain itself of power. Seems the caps hold a lot of power in the Pi, and some on the miner, causing it to linger in a low-power, half-alive, dysfunctional state. One which causes it to not boot correctly, if instantly turned off and back on, in a time-period below 20-seconds.
