Edited by tkaiser at Fri Nov 7, 2014 07:39 |
You should become a bit familiar with history/development of the linux-sunxi community (they are the people spending their spare time on your problems) and the history of the Allwinner SoCs (Android only in the beginning, their code known for many GPL violations in the past up until now, linux support started with Cubietech / Tom Cubie, a former Allwinner employee, if I'm not wrong). The Banana Pi is some sort of a late spin-off product of this process.
Regarding SATA speed I just said what you can expect today. If you would inform yourself a bit how the development process works regarding kernel/hardware stuff then you might consider asking politely the right questions in the right place and maybe donate some pieces of hardware so that volunteers have a suitable test setup when they work in their spare time on problems like this (maybe it's a simple driver issue, maybe not. The SATA section in the A20's officially released user manual contains just a few sentences). And you should consider telling kernel hackers how to measure storage correctly because these people tend to fail with such tasks (using dd or hdparm wrongly and therefore measuring always partially OS buffers/caches instead of storage devices).
Regarding ECC RAM it's a simple truth: If you don't have at least simple ECC memory (there exist 'advanced' ECC implementations for a reason: because simple ECC isn't enough since decades) you won't even be able to check whether you have faulty RAM or not (and if you have tons of servers and read out their ECC/EDAC error logs while running and check these machines with tools like memtest86 you will have to notice that there exist modules that survive 72 hours tortured with memtest86 without a single error and produce one correctable error every few weeks when in productive use. No ECC RAM --> no way to have a clue what's the health state of your memory )
With faulty RAM (non-ECC and ECC as well when we're speaking of 2-bit-errors) you might experience crashes (of programs or the whole system), you might experience silent data corruption (if this happens when writing file system structures then you might experience also huge data losses if your backup isn't existing) or you might not even notice anything because it either affects only data you will never access again (or where file formats are fault tolerant, interpolating missing pixels/frames) or everytime when these aforementioned things happen people want to believe it's just faulty software.
The reasons for bit flips do exist (even more in situations with unprotected boards like the Banana Pi -- compare with EMC), these sorts of problems increase with more and more electrons packed in fewer space (the LPDDR4 specs therefore optionally implement simple 'on die ECC' because these problems matter even on tablets/smartphones and the like), backups won't help that much because already faulty data will be backed up (this gets even worse with filesystems featuring end-to-end data integrity since in these situations you corrupt intact data on disk while scrubbing) but nobody likes to accept these facts