esbeeb

Members
  • Content Count

    51
  • Joined

  • Last visited

About esbeeb

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As I rsync'd data around between the drives (all formatted with BTRFS), while doing no other disk operations to speak of, I would at first get 40MB/sec (shown with iotop), then after about 10 seconds, it would simmer down to 20MB/sec and stay there. So you can expect a solid 20MB/sec through those USB 2.0 cables (and the USB 3.0 cables were never any faster, even when no "UAS inflight" errors were getting generated), with quick initial surges of 40ish MB/sec. These speeds (when doing just one data transfer at a time) held true wether or not you wrote to SATA or a USB disk, and wether or not you used a spinning 3.5" drive, or an SSD. So in conclusion, IMHO, this rig was born to run OpenMediaVault (in a small office of a few people, where it's usually/often the case that only one user at a time is hitting this server), but not Nextcloud! And those users should probably use Filezilla to transfer files (not Windows Explorer, ie. SMB3), if they are transferring any more than about 300MB (at which time I say it's worth one's time to spend the 30 seconds or so starting Filezilla, and logging in, and navigating to the source/destination folders.) Furthermore, you get a very noticeable boost in file transfer speeds, if you are willing to use a Gigabit Ethernet dongle on your laptop, even a cheap one like I bought (see above), not wifi.
  2. Here's a picture of the NAS I've set up for our small office here: Inside the NAS kit aluminum case on the top is a 500GB SSD, and there are two more 3.5" drives on the bottom, in enclosures, attached with USB 2.0 cables. OpenMediaVault uses all 3 drives.
  3. Although these enclosures have a good controller chip, the USB3.0 cables provided suck. I would get UAS-related "inflight" error messages as seen above, when using them, for any prolonged period of time. These error messages went away when using plain old USB 2.0 USB-A-to-USB-B male-male cables (as in, USB "printer cables"), which had the same overall thickness of wire when you compared them side-to-side to the junky USB 3.0 cables, but the USB 2.0 cables have like half the metal wires inside them, which were probably much thicker guage than the junky USB 3.0 cables. Boo, Orico! Mr. Scissors was not impressed: We also bought a couple of USB 3.0 cables on AliExpress (don't ask which ones, one was 1.5m, one was 3m), and they too similarly sucked. If Mr. Scissors could speak, he would say, "Off with their heads!": PS: the reference to Mr. Scissors was a little shout out to Chris Barnatt of explainingcomputers.com.
  4. Thanks for that diagram. Oops, actually, I have the NanoPi Neo 2, not the NanoPI Neo Core 2 (and I've changed the title of this topic accordingly). And I downloaded the wrong thing (although it booted with no complaints!). I'll try again... BTW: I've been trying the OMV pre-built image (correctly for the NanoPi Neo 2, not Core 2), from here by tkaiser, where I had these glitches. In an attempt to get that USB port on the NAS kit board working more reliably, my plan now is to use the stock Armbian for the NanoPi Neo 2, then use the "softy" menu to install OMV. That way I'll get a newer kernel (which maybe will use that 2nd USB port, on the NAS kit board, more reliably). This will let me jump from an older kernel to a newer one: Current OMV 4.1 image pre-built by tkaiser: Linux hostname 4.14.70-sunxi64 #274 SMP Wed Sep 19 12:09:30 CEST 2018 aarch64 GNU/Linux Current stock Armbian: Linux hostname 4.14.78-sunxi64 #416 SMP Fri Oct 26 15:54:03 CEST 2018 aarch64 GNU/Linux I found the USB-related hardware problem, detailed here.
  5. Just to clarify. Drives connected to both the USB port on the NanoPi Neo 2, and the SATA port of the NAS kit work well. It's just a third drive hooked up to the USB port on the NAS kit accessory board where things get sketchy, for that that third drive only. Hindsight being 20/20, if you want to have a NAS with a backup disk, you would do best to get a NON-SSD 2.5" laptop hard drive (with the longest warranty you can find, like 3yr., and paying a little extra is worth it) to hook up to the NAS kit SATA port (where you'll get, say 4TB max these days), then hook up a 4ishTB 3.5" hard drive (in a good enclosure, like the one I linked to above, with a JMS578), to the USB port on the NanoPi Neo 2 mainboard, NOT the USB port on the NAS kit accessory board. Don't listen to advice about the importance of using an SSD (which is of course going to be way smaller in capacity due to far higher price-per-TB) to get the best random IO speed over UAS. It turns out to be no faster, even on tiny files. For this board, which only has USB 2, (not USB 3) that SSD-related advice is a red herring (when it comes to speed).
  6. Here's what I think the problem is. The USB port on the NanoPi Neo 2 mainboard itself works well with the default UAS driver from the kernel. But the second USB port, which seems to be an afterthought on the NAS kit accessory board, does NOT work well with the UAS driver from the kernel. Why would I conclude this? Because when I put the "problematic" (seeming) drive onto the other USB port (on the mainboard of the NanoPi) the problem went away. Edit: I found the fix I needed, detailed here.
  7. Aargh. Even after changing the USB cable, on the drive connected to the USB port of the NAS kit board, I'm getting UAS-related kernel error messages, when I download many small files over SMB: Dec 12 14:00:48 filesrv1 kernel: [ 5957.276611] sd 2:0:0:0: [sdb] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: IN Dec 12 14:00:48 filesrv1 kernel: [ 5957.276630] sd 2:0:0:0: [sdb] tag#1 CDB: opcode=0x88 88 00 00 00 00 00 00 11 b1 10 00 00 03 00 00 00 Dec 12 14:00:48 filesrv1 kernel: [ 5957.287599] scsi host2: uas_eh_device_reset_handler start Dec 12 14:00:48 filesrv1 kernel: [ 5957.401615] usb 3-1: reset high-speed USB device number 2 using ehci-platform Dec 12 14:00:48 filesrv1 kernel: [ 5957.608831] scsi host2: uas_eh_device_reset_handler success Dec 12 14:01:21 filesrv1 kernel: [ 5990.045561] sd 2:0:0:0: [sdb] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: IN Dec 12 14:01:21 filesrv1 kernel: [ 5990.045580] sd 2:0:0:0: [sdb] tag#1 CDB: opcode=0x88 88 00 00 00 00 00 00 11 84 c8 00 00 03 c0 00 00 Dec 12 14:01:21 filesrv1 kernel: [ 5990.056539] scsi host2: uas_eh_device_reset_handler start Dec 12 14:01:21 filesrv1 kernel: [ 5990.170553] usb 3-1: reset high-speed USB device number 2 using ehci-platform Dec 12 14:01:21 filesrv1 kernel: [ 5990.338706] scsi host2: uas_eh_device_reset_handler success Dec 12 14:01:55 filesrv1 kernel: [ 6024.350540] sd 2:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: IN Dec 12 14:01:55 filesrv1 kernel: [ 6024.350559] sd 2:0:0:0: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 92 88 ee b0 00 00 00 88 00 00 Dec 12 14:01:55 filesrv1 kernel: [ 6024.361523] scsi host2: uas_eh_device_reset_handler start Dec 12 14:01:55 filesrv1 kernel: [ 6024.475536] usb 3-1: reset high-speed USB device number 2 using ehci-platform Dec 12 14:01:55 filesrv1 kernel: [ 6024.604705] scsi host2: uas_eh_device_reset_handler success
  8. Here's what I bought: https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=180 I tell you solemnly, there's only one way to connect it to the Nas Kit board.
  9. I hooked a second external 3.5" Hitachi up to the additional USB port provided by the "NAS kit" add-on board. This one is a 6TB. I was wanting to set this up as a backupdrive of my other 2 drives, and serve it out read-only over the network with FTP and SMB. When I formatted it with BTRFS, I got error messages about failed checksums when I tried to FTP my sample 2GB of tiny files out of it! Kernel error messages began appearing during the FTP, such as the following: Dec 11 15:47:43 filesrv1 kernel: [ 1564.078380] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 41418752 csum 0x394f3c35 expected csum 0x9fc46317 mirror 1 Dec 11 15:47:43 filesrv1 kernel: [ 1564.152892] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 41746432 csum 0xf2ebac76 expected csum 0xa8e57e86 mirror 1 Dec 11 15:47:43 filesrv1 kernel: [ 1564.180123] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 42795008 csum 0x9b4b400b expected csum 0x3b97019a mirror 1 Dec 11 15:47:43 filesrv1 kernel: [ 1564.277908] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 41418752 csum 0x394f3c35 expected csum 0x9fc46317 mirror 1 So I reformatted the drive as EXT4 instead, then tried the same test again. No error messages that time. Strange... BTW: both BTRFS and EXT4 performed the same, when copying data into the drive, and the FTP download speed I achieved (once formatted with EXT4), was 37 MB/sec. Edit: I changed the USB 3.0 cable. I'm pretty sure the cable that came with the enclosure was flawed. No more error messages now, and the blue light on the enclosure no longer flashes in a warning-like way, when there's no disk activity (and I observed this warning-like flashing, as well as other kernel error messages, when I used a too-long 3-meter-long USB cable previously).
  10. I did an FTP upload test, using all-GbE (no wifi), comparing how the 4TB 3.5" Hitachi (in the JMS 578 enclosure) would compare to the SSD. The 3.5" Hitachi won, slightly: 32.8 MB/sec for the 2GB .zip file (compare to the SSD, which got 29.9 MB/sec), and 18.7 MB/sec for the 2GB worth of tiny files (compare to the SSD, which got the very same 18.7 MB/sec). Note: SSL was used for FTP. So FTP also kicks SMB1's butt for speed, even when used with SSL. OpenMediaVault made it easy to generate and then use a self-signed SSL cert (for use within my LAN).
  11. I wanted to get some speed tests over SMB (ver 3.11, the default in OMV) protocol, using OpenMediaVault. I used the pre-built image for this board available here. The quick summary is that FTP is way faster than SMB, like 50ish % faster. Here were some Samba speeds, uploading the same 2GB .zip file, then 2GB worth of tiny files, to the 2.5" Samsung SSD: Over all-GbE (as in, no wifi between my laptop and the wifi router), 18.3 MB/sec for the 2GB .zip file (would have been 29.9 MB/sec over FTP), and 11.9 MB/sec for the 2GB of tiny files (would have been 18.7 MB/sec over FTP). Over wifi (as in, there was wifi between my laptop and the wifi router), 14.0 MB/sec for the 2GB .zip file, and 7.8 MB/sec for the 2GB of tiny files. Here were some Samba speeds, uploading the same 2GB .zip file, then 2GB worth of tiny files, to an external 4TB 3.5" Hitachi hard drive, in a USB 3.0 enclosure which surely has a JMS 578 controller chip (connected to the USB port on the mainboard of the NanoPi, not the USB port on the NAS accesory board): Over all-GbE (as in, no wifi between my laptop and the wifi router), 18.7 MB/sec for the 2GB .zip file, and 12.1 MB/sec for the 2GB of tiny files. Over wifi (as in, there was wifi between my laptop and the wifi router), 13.4 MB/sec for the 2GB .zip file, and 8.0 MB/sec for the 2GB of tiny files. So a plain old 3.5" spinning hard drive, in a good USB enclosure, with a JMicron 578 controller chip, slightly beats an SSD!!
  12. esbeeb

    Recommended SBC below 20USD range.

    That's fair to point out. I've played with a Qnap TS-251A quite a lot, and the OS is a locked down, stripped down sort of distro, that's clumsy and hard to do anything useful with on the command line (if you're accustomed to Debian, which I am). If, OTOH, you like Qnap's web-based admin interfaces (good for average folk who are not Linux geeks), and accept that you should do virtually everything there (in the web GUI), and avoid the command line (where it's pretty much a nightmare compared to Debian/Armbian), then I say, yah, Qnaps are good. Having said that, it's not trivial to pare down all the gratuitous bells and whistles that Qnap enables by default. Qnap's default settings make it this sort of all-singing, all-dancing whore of pretty much all networking protocols. I dare you to do an nmap scan on a Qnap appliance (within the LAN) and count all the open ports, which are enabled by default. There are way, way too many open ports, IMHO, if you care about security. So all the paring-down efforts (where you really need to know what you're doing to tighten things up nicely, yet not damage the functionality you really need) seriously takes away from the Qnap's claim to being "easy." A Qnap is actually kind of hard to lock down decently. I've done it, and I could never quite get it the the way I wanted it. There were still open ports I didn't want, yet couldn't disable without also removing some other wanted port. Also note that Qnap has invented their own software packaging system called "qpkg". You can't "apt-get install" whatever you like, as is the case with Armbian (which is important to me).
  13. OK, I re-ran my Nextcloud tests, shown above, using all-Ethernet. When uploading the 2GB .zip file, the speed jumped from 10.9 MB/sec (with wifi-from-laptop) up to 17.2 MB/sec (all-ethernet), average. That's considerably closer to my FTP test (which I'm almost certain I did as all-Ethernet), which got me 29.9 MB/sec. @Igor, thanks so much for the great tip. When uploading the 2GB folder of many tiny files, the speed very slightly improved from 1.0 MB/sec (with wifi-from-laptop) up to 1.1 MB/sec (all-ethernet), average. That's still a far cry from the FTP test (which I'm almost certain I did as all-Ethernet), which got me 18.7 MB/sec: Note that I used BTRFS on the SSD being uploaded into, for both the FTP test, and the Nextcloud test.
  14. When I go all-Ethernet (and don't have wifi between my laptop, chicklet, and the wifi router), then iperf3 gets much better: root@chicklet:~# iperf3 -c nextcloudpi Connecting to host nextcloudpi, port 5201 [ 4] local 192.168.0.115 port 33706 connected to 192.168.0.137 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 0 307 KBytes [ 4] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 307 KBytes [ 4] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 0 324 KBytes [ 4] 3.00-4.00 sec 112 MBytes 939 Mbits/sec 0 348 KBytes [ 4] 4.00-5.00 sec 112 MBytes 942 Mbits/sec 0 348 KBytes [ 4] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 0 348 KBytes [ 4] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 348 KBytes [ 4] 7.00-8.00 sec 112 MBytes 940 Mbits/sec 0 348 KBytes [ 4] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 348 KBytes [ 4] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 0 348 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver iperf Done. Note: I'm using a lacklustre GbE dongle on my laptop, a TP-Link UE300 (which is better than jack squat, because it's supported in Linux whatsoever), and the fastest I've ever been able to get it to go is 40MB/sec, sustained (when connected do a different server, not this NanoPi). This dongle should be fast enough for my tests, as I've never hit that 40 MB/sec (and topped out).
  15. I changed the ethernet cable to a brand new, store-bought cable. But the iperf3 output didn't really improve: root@chicklet:~# iperf3 -c nextcloudpi Connecting to host nextcloudpi, port 5201 [ 4] local 192.168.0.129 port 44196 connected to 192.168.0.137 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 36.2 MBytes 303 Mbits/sec 69 317 KBytes [ 4] 1.00-2.00 sec 32.3 MBytes 271 Mbits/sec 7 288 KBytes [ 4] 2.00-3.00 sec 32.2 MBytes 270 Mbits/sec 9 272 KBytes [ 4] 3.00-4.00 sec 32.5 MBytes 273 Mbits/sec 2 264 KBytes [ 4] 4.00-5.00 sec 32.3 MBytes 270 Mbits/sec 1 255 KBytes [ 4] 5.00-6.00 sec 32.6 MBytes 274 Mbits/sec 0 338 KBytes [ 4] 6.00-7.00 sec 32.0 MBytes 268 Mbits/sec 4 259 KBytes [ 4] 7.00-8.00 sec 32.4 MBytes 272 Mbits/sec 1 255 KBytes [ 4] 8.00-9.00 sec 32.1 MBytes 269 Mbits/sec 2 243 KBytes [ 4] 9.00-10.00 sec 30.3 MBytes 254 Mbits/sec 13 260 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 325 MBytes 272 Mbits/sec 108 sender [ 4] 0.00-10.00 sec 322 MBytes 270 Mbits/sec receiver iperf Done. Furthermore, when I do an "ifconfig" both on my client and server machines (for iperf3), neither shows any dropped packets (Note the "errors 0 dropped 0" for both RX and TX in all cases): root@chicklet:~# /sbin/ifconfig lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 371 bytes 32291 (32.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 371 bytes 32291 (32.2 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.129 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::9ec0:39e5:56a0:9721 prefixlen 64 scopeid 0x20<link> ether f8:bb:aa:zz:yy:xx txqueuelen 1000 (Ethernet) RX packets 198902 bytes 18974787 (18.9 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 458133 bytes 701689760 (701.6 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 root@nextcloudpi:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.137 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::dcb7:78de:d32f:64c4 prefixlen 64 scopeid 0x20<link> ether 02:bb:aa:zz:yy:xx txqueuelen 1000 (Ethernet) RX packets 454893 bytes 688170496 (656.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 193446 bytes 12843866 (12.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 24 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Note that my client laptop, "chicklet", is connected over wifi to the router. So there's only one ethernet cable to possibly blame, here.