SBC for 2 x 2.5 HDD

[rosseba]

Hello,
I'm looking for a recommendation about a SBC capable of:

• manage 2 x HGST HTS721010A9E630 (HDD 2,5", 1 TB)
• offer Gigabit ethernet connection

 

I saw different threads where a mPCI SATA card is used (e.g. https://forum.armbian.com/topic/4845-marvell-based-4-ports-mpci-sata-30/), I don't know if there is a better option.

Thanks for any tip,
-f

[hjc]

I haven't tried myself, but maybe RockPro64 with a PCIe SATA adapter card and their metal case is suitable for you.

[tkaiser]

23 hours ago, rosseba said:

manage 2 x

 

Not the best description of your use case.  

 

We have servers based on Olimex Lime2 with one 2.5" disk connected to the SATA port and another connected to one USB2 port (and powered by both). The latter is the backup disk and since Olimex boards are designed well we can power it off completely when not used (using sunxi-pio utility)

 

USB3 attached SATA is often faster than 'native' SATA or even PCIe attached SATA: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350

 

An alternative to more than one SATA port can be port multipliers. Cheap SATA PMs like JMB321 have the disadvantage that they only support CBS but not FIS-based switching (slowing down concurrent accesses), better ones like JMB575 are usually pretty expensive. But if you search the forum for these two strings (JMB321/JMB575 you get some insights, interesting to combine those with EspressoBin).

 

And then there also exist such 2-port SATA PMs integrated in an UAS capable USB-to-SATA bridge, e.g. JMS561: https://forum.openmediavault.org/index.php/Thread/19871-Which-energy-efficient-ARM-platform-to-choose/?postID=169303#post169303

 

Such a thing attached to an USB3 port is fast enough for two 2.5" HDD but almost all SSDs will be bottlenecked.

 

Maybe you elaborate a bit on your use case first...

 

[rosseba]

29 minutes ago, tkaiser said:

 

Not the best description of your use case.

...

Maybe you elaborate a bit on your use case first...

 

 

Sorry you're right
Right now I'm using a Raspberry PI Model 3+ with 2 USB3 to SATA converter connected with 2 HGST HDD.
Disks are member of mdadm RAID1 array, array encrypted with LUKS2.
I tried to limit the RPI wellknown power issues with a powered Anker USB3 hub so everything now is working but with limited performances.
So I'm looking for a setup that can guarantee more stability and better performances.
There are no so many SBC with 2 SATA ports native so I asked if the main option is to add to a SBC an additional miniPCIe or M.2 adapter.

 

@hjc

thanks for tip about Pine64 stuff, I'll take a look!

Again thank you for any tip!
-f

[tkaiser]

1 hour ago, rosseba said:

I tried to limit the RPI wellknown power issues with a powered Anker USB3 hub

 

Usually you do not want an USB hub between host and disk, especially if disk accesses happen in parallel. Since all RPi just have one single USB2 port there's always one (internal) hub involved if you're not using an RPi Zero. The RPi Trading 'geniuses' when mixing ingredients for their latest update of the platform chose a combined Ethernet/hub thingy (LAN7515) that does not only suck when it's about networking but also contains not just one but two internal hubs in a cascaded fashion. So with your external hub you might already have 3 cascaded hubs between host port and disks. Terrible.

 

Also RPi 3 and 3+ are one of the few 64-bit capable SBC that do not implement ARMv8 Crypto Extensions and therefore suck horribly when it's about AES performance: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md

 

While I personally consider mdraid-1 just a weird waste of disks obviously you want to access your both disks concurrently and fast. As already mentioned: combining any cheap USB3 equipped SBC like Rock64 with the JMS561 thing will work fine with HDDs or you could use an EspressoBin with one disk connected to the SATA and the other to the USB3 port. Or using an PCIe attached SATA controller on those PCIe capable boards. Just a matter of money you want to spend on the setup.

 

Since all HDD suck horribly  at random IO I personally would also consider USB3 combined with good UAS capable SATA bridges since... fast enough. But USB3 when you have to use the USB3-A connector can be a real sh*t show since connection issues are quite common with this crappy connector.

 

There was a RK3399 board announced a while ago called Rock960 Pro with an JMS561 on the PCB providing 2 SATA ports suitable for HDDs but no idea what has happened (@hipboi asked me whether I want a developer sample some time ago but we did not succeed for whatever reasons)

[chwe]

2 hours ago, tkaiser said:

USB3 attached SATA is often faster than 'native' SATA or even PCIe attached SATA: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350

Did you ever got it throttling by high disc usage? MT7623 got quite hot with USB attached SSD, whereas on its ASM1061 connected SATA the board runs quite smooth. 

Cause the thermal management on mainline here seems to be 'at least' conservative (https://github.com/torvalds/linux/blob/2ad0d52699700a91660a406a4046017a2d7f246a/arch/arm/boot/dts/mt7623.dtsi#L148-L172) iozone on an USB attached SSD was enough to get it throttling..  

 

 

[hipboi]

@tkaiser I did not forget it. We update ficus to v1.1 adding some requests from customers and now it's out. We will send you the new boards soon after some testing.

[tkaiser]

6 hours ago, chwe said:

MT7623 got quite hot with USB attached SSD

 

Sorry, MT7623 is a bit off-topic here. And I really don't know whether you're talking about temperatures or silly DT settings (probably leftovers from here). Anyway: with USB attached SATA the amount of interrupts to be processed is higher compared to native or PCIe attached SATA with same performance. So CPU utilization is higher too. But when throttling occurs caused by a simple disk benchmark then there's something wrong (e.g. defining 47°C as first thermal trip point)

[chwe]

The thermals are conservative sure.. But if I had to decide between USB3 or a PCI solution I would tend to a PCI based solution due to this observations. Am I just wrong and this SoC combines a bad USB3 stack combined with conservative thermals or heat most SoCs generally a way more up with USB3 attached storage? In case it's the second I would prefer a PCI soluiton, especially cause those boards get cheaper and cheaper (e.g. RK3399 boards). The only 'cheap' board with native SATA (EspressoBin) seems to have several issues among RAM and CPU clockspeed which makes it not that easy to handle for beginners at the moment. 

My HC1 is also USB3 based and works just fine (but they really care about proper thermal management on the entry board). 

[tkaiser]

1 hour ago, chwe said:

But if I had to decide between USB3 or a PCI solution I would tend to a PCI based solution due to this observations.

 

Huh?

 

Your 'observations' are based on a SinoVoip product (a board maker giving a sh*t about heat dissipation and settings -- the 'start to throttle at 47"C settings' are not 'conservative' but simply silly or most probably as everything relating to this vendor 'copy&paste gone wrong'). Why should this be of any relevance for any other board around?

 

With USB (even with UAS) the amount of interrupts to be processed is higher compared to SATA, see my RK3399 tests with RK's 4.4 kernel some while ago: https://forum.armbian.com/topic/6496-odroid-n1-not-a-review-yet/?do=findComment&comment=49627

 

 

This results in slightly higher CPU utilization which results in slightly more heat generated. I tested with a fast SSD and here it's about boring/slow HDDs. Why should this little extra efforts with USB3 matter as long as there are no cable/connection issues?

 

Still I wonder why nobody is 'designing a RK3399 'NAS board' with a JMS561 attached to each USB3 port to provide 4 SATA ports for spinning rust and a M.2 key M slot for a fast NVMe SSD or alternatively something like this to provide another 4 SATA ports'

[chwe]

5 minutes ago, tkaiser said:

the 'start to throttle at 47"C settings' are not 'conservative' but simply silly or most probably as everything relating to this vendor 'copy&paste gone wrong').

at lest it would be peer reviewed copy paste gone wrong...  My question is, assuming you use some well designed boards with USB attached HDD/SSD whatever.. Will such a board perform well with multiple attached discs? Assuming others do better in terms of thermals will it be sufficient for multiple discs? When one disc under heavy usage can create so much heat what will 4 discs do (I simply don't know due to not dealing with such test setups often).. 

Side-note (off-topic): Patching thermals wouldn't be an issue at all but as long as the DSA driver sucks that hard, I don't see an reason to do that. I don't optimize thermals when I only get 50-70mbit out of iperf, that's 'verschwendete Liebe'..  

 

16 minutes ago, tkaiser said:

 

Still I wonder why nobody is 'designing a RK3399 'NAS board' with a JMS561 attached to each USB3 port to provide 4 SATA ports for spinning rust and a M.2 key M slot for a fast NVMe SSD or alternatively something like this to provide another 4 SATA ports'

Do you really think there's a market for such a board? Let's face it.. the majority goes for a synology NAS for such use cases. Otherwise boards like the Helios fits more or less well. Solid-runs upcoming ARMADA A8040 based boards might be worth to look at for those use-cases too. Seems that 'NAS' isn't the first thing boardmakers think when it comes to the RK3399.. More or less every bigger boardmaker has now a RK3399 board in their pipeline.. Not sure if they come up with a new one soon... 

[tkaiser]

14 hours ago, chwe said:

When one disc under heavy usage can create so much heat

 

What? The settings for your BPi R2 are BS. Why throttling at 47°C? Why not already at 25°C or '10 degree below ambient temperature'? All those variations make no sense at all.

 

And yes, I believe there is a market for an 'energy efficient but inexpensive NAS that can transcode videos on demand'.