So always check which SATA bridge chip is used inside an enclosure. Therefore accessing many small files in random fashion on a SSD A20 might be ten times faster than H3 (or even more depending on the USB-to-SATA bridge used between H3 and the disk in an USB disk enclosure).Īgain: this might change with mainline kernel and an UASP capable disk enclosure since then also random IO over USB gets way faster. Since with legacy kernel we can only use USB2.0 BOT mode (slower sequential transfer speeds and especially way slower when it's about random IO compared to UAS) while A20 here shows native SATA 2.0 capabilities (native command queueing and stuff like that). Let's have a look at random IO: here the current situation clearly sucks with H3 compared to A20. I always talked about sequential transfer speeds above (since that's the most important parameter for normal NAS useage). This works even with disks of different size since when partitioning intelligently (using stripes of a specific size and combining striping/mirroring) you get a fully redundant disk setup showing doubled performance and 50 percent of the added capacity of all individual disks - But that's stuff for another article I prepare for being released after the first H3 vanilla Armbian OS images Also with mainline kernel we can combine 3 USB disks in a way that sequential performance is twice the USB2 bandwidth while getting a fully redundant setup by combining RAID-0 with RAID-1 (mdraid + btrfs' own RAID implementation). With mainline kernel we can also use btrfs and transparent filesystem compression so files that are able to be compressed 1:2 will then be read/written with 78MB/s instead of 39MB/s. And when using UASP capable disk enclosures and mainline kernel RAID-0 performance will increase even more (+75 MB/s since single disk access gets close to 39MB/s). Now we're able to write/read to/from our H3 NAS already with ~60MB/s. I just created one on 3.4.112 without any tuning using 2 cheap crappy external 2.5" disks that also use crappy USB-to-SATA brudges, just by executing mdadm / mkfs.ext4 without using my brain: And if disk performance really is an issue RAID-0 could be an option. By switching to mainline kernel soon we're able to get close to 38/39 MB/s when UASP capable disk enclosures are used. With H3 single disk access over USB 2.0 is the bottleneck (accessing data on disk that is not already cached will be limited to ~32 MB/s NAS throughput with legacy kernel, write performance to the NAS depends mostly on available DRAM and buffer settings/useage of the filesharing daemon in question). NAS -> Client: slow GbE read performance is the bottleneck.Client -> NAS: slow SATA write performance is the bottleneck.The problem with A20 is that sequential SATA performance is still unbalanced (45/200 MB/s write/read under best conditions - read as overclocked CPU and DRAM), that the same applies to Gbit Ethernet performance (here the read performance sucks so unfortunately in this direction network is the bottleneck) so that we end up here with the following situation if we're talking about NAS:
![dockstar nas dockstar nas](https://i.ebayimg.com/images/g/9KAAAOSwzq5f1QEU/s-l300.jpg)
I still favour the A20 boards with there true sata interface Lowest fully-functional device speed is High Speed (480Mbps)
![dockstar nas dockstar nas](https://www.mydigitallife.net/wp-content/uploads/2010/03/freeagent-dockstar.jpg)
![dockstar nas dockstar nas](https://the-gadgeteer.com/wp-content/uploads/2009/12/freeagent-dockstar-fp.jpg)
#Dockstar nas full
Latency Tolerance Messages (LTM) Supportedĭevice can operate at Full Speed (12Mbps)ĭevice can operate at High Speed (480Mbps) IdVendor 0x0bda Realtek Semiconductor Corp.īInterfaceClass 255 Vendor Specific ClassīInterfaceSubClass 255 Vendor Specific Subclass Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.īDeviceClass 0 (Defined at Interface level)