Best cheap ARM board for Syncthing?

The speedup is caused by the new cryptography extensions that are part of ARMv8 (aarch64). When Syncthing is compiled for ARMv7 (armhf), they are not used.

Yeah, use the one actually compiled for your CPU. The openssl benchmark looks the same as ours, judging by ours being single thread (as mentioned) and openssl getting -multi 4.

@bizarre87 Do you have any actual performance numbers for the RK3328 when transferring files? I keep wondering how fast it is with a USB3 diskā€¦

I have tried plugging in both SSD via USB, WD RED 3TB drive and also WD My Book DUO RAID1. Using through Plugable USB 3.0 Hard Drive Dock. The maximum speed I have seen during transfer hovers around 15-28MBps with spinning drives and 40+ MBps with SSD. iMAC is a peer device, both running the latest versions of syncthing.

In comparison, AFP transfer between iMAC and rock64 reaches 920Mbps.

If there is a more scientific way to run transfer speed benchmarks, let me know.

Thanks a lot for sharing! That sounds pretty good. Just to not misunderstand anything, by MBps you mean MB/s, not Mbps, right?

Hiā€¦If a disk dies or a sector is fried you have can have holes in your files. Better create a snapshot, mount it, rsync it to another disk or physical location. Also RAID is not a backup, because when the controller dies or it is eating your data you may not notice. A RAID array is still vulnerable to power-surges.

Iā€™m having good results with a NanoPi Neo2, with the ā€œNAS Kitā€ Accessory board, allowing me to attach a 2.5" SATA SSD drive.

While this board might not be the absolute cheapest ARM board out there (I say itā€™s still darn cheap), the Armbian builds for it are ā€œSupportedā€ by Armbian, and fully stable-feeling. (BTW: I recommend spending the extra $10 and get the 1GB of RAM, not the default of 512MB RAM.)

If you are a conservative person, wanting a very stable board, with a single very stable SATA-attached SSD, then I recommend this arrangement. Almost all other SBCā€™s out there with some SATA connectors do not have the status of being officially ā€œSupportedā€ by Armbian (at least, not yet). Sure, the Helios 4 is fully ā€œSupportedā€ by Armbian, but is much more expensive than the NanoPi Neo2.

After some substantial testing, I was able to get sustained sync speeds of ~15-25MB/sec with syncthing, and this is almost exactly same speed as what youā€™d get if you ran a Samba server on this NanoPi.

Note: I had disk I/O troubles attaching larger-capacity 3.5" SATA drives in USB enclosures, mind you. See here for more on that. I only recommend one 2.5" SATA drive attached to the NAS-kit board. If you attach disks to the USB ports, you were warned. (Hint: watch /var/log/syslog for Disk I/O error messages). Having said this, perhaps it was the poor quality of my disk enclosures themselves which were to blame. I wasnā€™t able to nail down what was to blame. But I do totally trust the one SATA connector on the NAS kit board.

Call me paranoid, but Iā€™ve lost all trust in USB-attaching any storage for use in a file server. Iā€™ll only use at least SATA-attached storage now (or better, like M.2), and it had better be known to be a very stably-performing SATA, in the way of kernel support (as in, Armbian calls it ā€œSupportedā€, and ā€œStableā€).

1 Like

Just reviving the old topic, the Raspberry Pi 4 has been announced with a maximum of 4GB LPDDR4-2400 SDRAM, native Gigabit Ethernet and USB3 (2ports). Would be nice to see someone building a NAS with Syncthing on it, and should run smooth and lowpower.

https://www.raspberrypi.org/products/raspberry-pi-4-model-b/

3 Likes

Hiā€¦i use a Raspberry Pi 3 with an external drive. You can easily manipulate this setup into storing /home on the hard drive. In my setup I use BTRFS for the root filesystem and have added the hard drive as another device to the filesystem. I donā€™t intend on removing the hard drive from the system so it works for my uses. I store over 600GB this way.

My sense is that one had better use an SSD attached to a Raspberry Pi 4, because it will use much less power than a spinning-rust disk, for bulk storage.

There has been grumbling and warnings recently over properly supplying enough power to the RPi 4: youā€™ll want a damn good USB-C power supply, and damn good USB-C power cable (as in, the official ones from Raspberry Pi themselves).

And I still say, USB-attaching any mass storage is still asking for trouble for anyone setting one of these up in any business (i.e. non-home-usage, non-hobbyist) scenario.

My recommendation after a lot of testing on the NextcloudPi project, is for the Odroid HC1 (2.5" sata) and HC2 (3.5" sata) as both have 2gb ram and solid gigabit lan. They run around $55 each and are the best choice amongst arm boards for file sync solutions. Load up Armbian and you should be good to go. The case doubles as a heatsink and easily stack.

I run a file server on an odroid-xu3 for years and when I had trouble (and I had) then it was always the sata-usb3 bridge. I would go for an odroid-hc1 (or anything with a direct SATA connection). My rPi4 is nice, but some sata-usb3 bridges work (and some not, depends on controller chip).

I know, the discussion is about ARM. I also donā€™t know all Odroid or board computers, but I think to get the best combination of performance, compatibility and price, you can hardly avoid an ODROID-H2+. I donā€™t know of any board computer that has the same performance. Okay, have an Intel processor. If you build a NAS out of it or normal computer, you have some quiet for a while and that makes this alternative cheap for me again.

Great thread, deserves a bump.

With odroid hc1/hc2 (most recent recommended boards) been discontinued whatā€™s current best option you would recommend?

From expensive to cheap - all are good enough for this purpose. ZFS is easy to enable ā€¦

  • Odroid HC4 - dual sata via pci
  • NanoPi M4 v2 - pci nvme
  • OrangePi 3 LTS - usb3 storage

All those have stable Armbian support and should be possible to buy in 2022.

1 Like

I would recommend a board with an arm64 CPU.

Edit: weā€™re digging up old threads?