03-24-2016, 02:05 AM
Two last remarks:
1) how to interpret these two results?
Are these two different cards? Nope, same card tested with a few seconds in between. Only difference: While the first 'benchmark' ran in another shell I copied a large amount of data to the SD card. Simple conclusion: Writing to the same media affects read speed, 'benchmarks' that run just 3-4 seconds can not be used reliably and their results should not be collected in spreadsheets but thrown away. Seriously, the ext4 default commit interval is 5 seconds so the chance that your 3 second benchmark will be influenced by a write commit is greater than 50%. Using single hdparm runs is therefore meaningless (as it is written in hdparm's manual page but who reads documentation?).
2) Here you can find q&d collected performance results for the 8, 16 (estimated) and 32GB eMMC modules the ODROID-C2 can be used with: http://forum.armbian.com/index.php/topic...c2/?p=6783
Not only sequential transfer speeds are up to 5 times higher than the maximum we get with Pine64's SD card implementation but more importantly the random I/O results are superiour. And that's what matters especially when you want to use a Linux desktop distribution. High CPU performance is nice, being able to use HW acceleration for certain aspects is essential but using an SD card that shows slow random I/O performance vs. using an eMMC module like the aforementioned makes the whole user experience when doing desktop stuff feel as different as day and night.
So if it's about Linux desktop usage either get the fastest SD card available today or think about moving rootfs and especially user homedirs to an USB connected storage device (preferably an SSD in an enclosure that is UASP capable since sooner or later UASP will be either backported or is already available when mainlining efforts for A64 made some progress -- I would suspect A64's USB implementation is the same as H3's so by using kernel 4.x alone sequential transfer speeds will increase by 5MB/s and random I/O might explode if used with a fast SSD in an UASP capable USB enclosure since this is where UASP is way more efficient compared to USB's bulk transfer mode we now have to use)
I made yesterday a quick test with an old 64GB mSATA SSD lying around in this enclosure and moved everything except of the bootloader to it (easy with Armbian). Even without being able to benefit from UASP it's unbelievable how different desktop usage feels.
1) how to interpret these two results?
Code:
root@pine64plus:/# hdparm -t /dev/mmcblk0
/dev/mmcblk0:
Timing buffered disk reads: 18 MB in 3.33 seconds = 5.40 MB/sec
root@pine64plus:/# hdparm -t /dev/mmcblk0
/dev/mmcblk0:
Timing buffered disk reads: 62 MB in 3.08 seconds = 20.14 MB/secAre these two different cards? Nope, same card tested with a few seconds in between. Only difference: While the first 'benchmark' ran in another shell I copied a large amount of data to the SD card. Simple conclusion: Writing to the same media affects read speed, 'benchmarks' that run just 3-4 seconds can not be used reliably and their results should not be collected in spreadsheets but thrown away. Seriously, the ext4 default commit interval is 5 seconds so the chance that your 3 second benchmark will be influenced by a write commit is greater than 50%. Using single hdparm runs is therefore meaningless (as it is written in hdparm's manual page but who reads documentation?).
2) Here you can find q&d collected performance results for the 8, 16 (estimated) and 32GB eMMC modules the ODROID-C2 can be used with: http://forum.armbian.com/index.php/topic...c2/?p=6783
Not only sequential transfer speeds are up to 5 times higher than the maximum we get with Pine64's SD card implementation but more importantly the random I/O results are superiour. And that's what matters especially when you want to use a Linux desktop distribution. High CPU performance is nice, being able to use HW acceleration for certain aspects is essential but using an SD card that shows slow random I/O performance vs. using an eMMC module like the aforementioned makes the whole user experience when doing desktop stuff feel as different as day and night.
So if it's about Linux desktop usage either get the fastest SD card available today or think about moving rootfs and especially user homedirs to an USB connected storage device (preferably an SSD in an enclosure that is UASP capable since sooner or later UASP will be either backported or is already available when mainlining efforts for A64 made some progress -- I would suspect A64's USB implementation is the same as H3's so by using kernel 4.x alone sequential transfer speeds will increase by 5MB/s and random I/O might explode if used with a fast SSD in an UASP capable USB enclosure since this is where UASP is way more efficient compared to USB's bulk transfer mode we now have to use)
I made yesterday a quick test with an old 64GB mSATA SSD lying around in this enclosure and moved everything except of the bootloader to it (easy with Armbian). Even without being able to benefit from UASP it's unbelievable how different desktop usage feels.