elatllat wrote:tkaiser are you intentionally trolling?
Sure. Just another time:
1) SATA as any other somewhat decent protocol allows for dynamic link speed negotiation, enables some features dynamically (like NCQ for example) and provides a primitive CRC mechanism to avoid data corruption on the wire if cabling/contact problems are involved (pretty common issue BTW). Users and especially those that try to benchmark have to know that, they also need to know that
dmesg | egrep -i "ahci|sata| ata|scsi|ncq"
is needed to diagnose for problems and also for correct benchmark execution. If a SSD only negotiates 3Gbps or even just 1.5Gbps speeds then numbers are obviously affected. You're not testing N1 any more but your SATA cable.
To check for transmission errors one could look at the CRC error counter available with almost all disks as SMART attribute 199. It's mandatory prior to every benchmark run and afterwards to check dmesg output as above and to query SMART attribute 199 of the tested disk (unfortunately some disks do not update the value of this SMART attribute even if CRC errors and retransmits happened and some whole disk families suck due to starting to report CRC errors way too late: https://www.smartmontools.org/wiki/Attr ... rn-Digital
2) SATA vs. IDE:
tells you what's going on (again: if there's NCQ it can't be IDE),
tells you what's going on (check 'driver' used), the performance numbers tell you what's going on (the fastest IDE standard allows for 166MB/s as absolute maximum)
3) Testing the wrong things 1): Trying to eliminate side effects is a great idea while trying to use
to eliminate testing the filesystem is still wrong as already explained to one of your community members: his SSD with any filesystem applied will show +385 MB/s with a benchmark suitable to test for SATA bottlenecks while
without any filesystem overhead shows lower numbers. Only possible conclusion: the benchmark tool
fails and the already explained reason is simple: hdparm's benchmark mode since being invented 30 years ago uses a block size of just 128KB for its tests (active benchmarking: benchmark the benchmark with eg.
128KB when defined by hdparm devs last century was a really huge number when HDD capacities were measured in MB and maximum transfer speeds were below 20 or even 10 MB/s! But of course it's too small today and that's why the numbers generated are useless (if you want to check for interface bottlenecks without filesystem influences you need to grab hdparm sources and adjust the 128KB to 16MB -- but why? You need a filesystem anyway and if you did already some benchmarking you know that the filesystem doesn't matter for this sort of test, sequential performance with large blocksizes is the same with every common filesystem).
4) Testing the wrong things 2): Why should only sequential transfer speeds be relevant? The majority of use cases with SBC is about random IO. And this is the only area where SATA on N1 can outperform USB3/UAS and that only if PCIe power management is disabled. Testing with something as inappropriate as
won't be able to show this.
5) Testing the wrong things 3): When only testing for sequential performance why testing only read direction? It's well known that high-speed interface performance in the SBC world can be unbalanced and a real sh*t show, see ODROID-C1 Gigabit Ethernet performance viewtopic.php?f=135&t=20104#p136247
or Allwinner's native SATA implementation that performs somewhat ok-ish in read direction (+200 MB/s) but totally fails in write direction (limited to 45 MB/s max). If you limit your 'testing' to only reading tests you end up not noticing such problems. Testing only one direction is too limited especially when afterwards conclusions are drawn about 'high-speed interface in general'. And please don't think this doesn't apply to N1. One such issue just got fixed yesterday regarding USB3/UAS: https://github.com/hardkernel/linux/pull/343
-- how do you want to test for such issues on the SATA ports with an inappropriate tool like
6) Testing the wrong things 4): On SBC it's pretty easy to run into CPU bottlenecks so instead of benchmarking 'the SATA implementation' chances are great to partially test only a CPU bottleneck instead (one single threaded process maxing out one CPU core or similar issues related to memory bandwidth that's always important for such use cases!). This is especially important to take into account on big.LITTLE systems:
Code: Select all
root@odroid:~# taskset -c 0 hdparm -tT /dev/sda
Timing cached reads: 1498 MB in 2.00 seconds = 749.17 MB/sec
Timing buffered disk reads: 968 MB in 3.00 seconds = 322.53 MB/sec
root@odroid:~# taskset -c 5 hdparm -tT /dev/sda
Timing cached reads: 2882 MB in 2.00 seconds = 1441.80 MB/sec
Timing buffered disk reads: 1094 MB in 3.01 seconds = 364.05 MB/sec
Ignoring this will only result in generating numbers without meaning. If that's the goal, everything's fine! If it's about generating some insights how a new platform works and how we should develop for example IRQ/SMP/HMP affinity settings to get both top performance at lowest (idle) consumption levels at the same time it's important to care about such details and then collecting 'The only numbers that matter' as it's unfortunately done here is simply counterproductive.
7) It's important to do the math correctly (you need to divide KB/s through 1024 and not 1000 to get MB/s for example) and to have in mind how the devices and processes in question work internally (zone bit recording -- watching
will show that resync performance get slower and slower and slower and the performance itself depends greatly on the block size used when setting up the array)
I'm sorry to focus on the stuff that matters (e.g. exploring and also educating users about the importance of block sizes used when accessing the filesystem and storage layers) and as such seem not to be the appropriate person to join 'debug parties' like this, right?