Search the Community

Waiting for a Rock64 but the Z28 pro has been on my shopping list. Not sure as its the RK3328 that I think dictates boot from SD0 so not sure how the others are working. https://www.gearbest.com/tv-box-mini-pc/pp_640682.html?vip=2663187&gclid=EAIaIQobChMImaXhqt2r1gIVr7_tCh2_0QHUEAAYASAAEgL32fD_BwE is the 1 I have been eyeing up with 2gb 8gb rom. On the Rock64 if the eMMC isn't avail at sd0 then it will boot from the sd card at sd1 (I think) Not sure how you can maybe short out or disable the eMMC if you can then it will prob boot from SD card.

Guess question between Z28 or Z28 pro is Fast ethernet or Gig. If I was going armbian and tinkering then Z28 pro and presuming there is little difference between this and the Rock64? Kwiboo & Longchair have made great inroads with the rockchip VOP & MALI the LibreElec guys have almost got it cracked but they are aiming for Leia for completion but much is working already. https://forum.libreelec.tv/thread/4248-libreelec-krypton-leia-agile-build-for-odroid-c2-rock64-wetek-hub-wetek-play2/?pageNo=10 If you guys get armbian going on that for £26.25 wow that would be amazing bang for buck.

Sorry, I'm a nob, but maybe it's not so complicated to use the script from ayufan. I put it in the directory like in his github repo (/etc/network/if-up.d/rock64-offload) and made it executable. But it's not working on my rock64 (Version 2.0, 2 GB). Can anyone help me? Or is there a possibility to solve the ethernet problem with one of the next nightly builds. That woud be great :-)

Interesting. Are you able to repeat the test without the mSATA SSD being present (me assuming that then the JMS578 not tries to register itself on the USB bus and you being able to enjoy a working card reader)? Wrt JMS578 behaviour: On ODROID HC1 the JMS578 is always present on USB bus even when no SATA device is connected to it. With Pine's ROCK64 SATA cable and 'my' Xunlong NAS Expansion board it's different so I would assume that's configurable behaviour (maybe depending on JMS578 firmware or toggled by GPIO settings). Maybe this is also important. But I've not the slightest idea how to query the JMS578 for firmware version (in Hardkernel/ODROID forum they provided a firmware flashing tool a while ago but not from 'official' JMicron sources since they forbit providing end users with this stuff but from a server 'somewhere on the Internet')

Read that 4.14 will have additional ARM Board Support including some Banana Pi products .. Among the new ARM boards supported are for the Beaglebone X15 Rev C (TI AM57xx), Raspberry Pi Zero W, D-Link DIR-685 router (Gemini-based), Banana Pi R2 (MT7623), Cubietruck Plus, Banana Pi M3/M2M/M64, NanoPi A64, A64-OLinuXino, Pine64, Rockchip RK3328 Pine64/Rock64 support, ZTE ZX296718 PCBOX Board, and others. link: https://www.phoronix.com/scan.php?page=news_item&px=ARM-Hardware-Linux-4.14

And fixed image for Rock64 was just rebuilt. https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z

No, I didn't use a serial console. I use a hdmi screen and a usb keyboard. I boot the board, the login screen appears and I try to login. But the system doesn't accept "root" as user, the error message is "incorrect login", the "password" prompt doesn't appear. It's possible to tape "rock64", than the password prompt appears.

At least as long as the interface is not controlled by NM it works (tested 20 days ago when I benchmarked my first Armbian build on ROCK64). So we might add a NM hook too but since their way of doing things isn't that persistent a systemd service might be the better idea... What about this in the meantime? diff --git a/packages/bsp/common/etc/init.d/armhwinfo b/packages/bsp/common/etc/init.d/armhwinfo index 96345fa..1900085 100755 --- a/packages/bsp/common/etc/init.d/armhwinfo +++ b/packages/bsp/common/etc/init.d/armhwinfo @@ -253,6 +253,8 @@ prepare_board() { echo 7 >/sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 >/proc/sys/net/core/rps_sock_flow_entries echo 32768 >/sys/class/net/eth0/queues/rx-0/rps_flow_cnt + # preliminary rx/tx offloading workaround + /sbin/ethtool -K eth0 rx off tx off ;; nanopim3) # dw-mci on cpu1, USB host on cpu2, GbE on cpu3, USB OTG on cpu4, video-codec on cpu5 for i in $(awk -F':' '/dw-mci/{print $1}' </proc/interrupts | sed 's/\ //g'); do

Hmm... and what about simply re-using what's known to work: https://github.com/ayufan-rock64/linux-build/blob/master/package/root/etc/network/if-up.d/rock64-offload?

Yes, ayufan said he had problems with Ethernet -- we talked today in #ROCK64 channel and I tested with 1GB production board (and offloading active): https://pastebin.com/aAzkEYEB (somewhat low performance in one direction but IMO not critical) and then next batch of boards got DRAM 'downgraded' which seems to cause problems for him. Anyway: I tested with production board and without tx/rx offloading fix/workaround Ethernet stopped to work after ~30 seconds as it's the case with the pre-production boards too.

Just got a rock64 board and tried the armbian testing image. Is ethernet working out-of-the-box with this image? My ethernet isn't working. Also the normal password didn't work (root / 1234). Would be nice to have some infos about that.

Nope, this shit https://forum.armbian.com/index.php?/topic/5098-mini-review-rock64-sata-cable/&tab=comments#comment-38798 happens way too often. An insanely shitty software called invision sitting in my browser and destroying things I want to share). That's it. As soon as the Armbian forum can be accessed without this interactive CRAP (using BBcode or $whatever sane option) I'm back. And no, I don't want to consult their sales clerks!

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere. TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too. Basics first: Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different! Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines. We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk. Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account: Pre-production board, 4GB, RTL8211E PHY: Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW Production board, 1GB, RTL8211F PHY: Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0). So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself. Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735 What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001 So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port. Nope, doesn't work any more, see below for details. How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago): The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s): USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s): USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111 I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts. Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened. So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise). When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters). The 5V power requirements for JMS578 + 3.5" HDD disk were as follows: USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

No time wasted! I thought today a little bit about why Armbian ships with such an anachronistic default configuration and whether it would be worth a try with more recent kernels to switch from swap to zram (and adjust vm swappiness since with vm.swappiness=0 most probably no one will ever see a difference). An interesting test would be sed -i 's/vm.swappiness=0/vm.swappiness=60/' /etc/sysctl.conf FILE=$(mktemp) wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb -qO $FILE && dpkg -i $FILE reboot But I've to admit that I don't know how to test whether something changes since I know swapping only as problem of the past. I've now 3 ROCK64 with different DRAM sizes. Maybe someone has an idea how a useful 'benchmark' could look like comparing different DRAM sizes?

The barrel jack on the Rock64 is tiny, I've not found one that size rated more than 1.5 Amps. (Not saying they don't exist, only that it is very small) I'll do some testing to see voltage drops/current consumption on mine and put it in the proper thread. I'm doing the same with "Le Potato", I may begin a matrix. Was the drive powering through the USB?

HK's kernel is in sync since 10 hours: https://github.com/hardkernel/linux/commits/odroidxu4-4.9.y BTW: with my EVO840 I get 240MB/s write on both XU4 and HC1 (with an UAS capable USB-to-SATA bridge of course! JMS567, JMS578 and ASM1153 successfully tested). If performance is that low as the 120MB/s you reported I would check 'lsusb -t' output whether you're using UAS or not and I would also check dmesg output for underpowering symptoms. I prepared a test with the fastest USB3 thingie we currently support (ROCK64) where we usually get +380 MB/s with fast SSDs random random kB reclen write rewrite read reread read write 102400 4 698 2538 1457 1577 1052 30803 102400 16 2732 84156 2697 3284 74365 572 102400 512 255254 265324 270608 279494 271598 1382 102400 1024 274236 1377 288145 296826 285552 1387 102400 16384 298959 298371 318954 326778 326171 1000 My test setup was an external VIA812B hub with an integrated RTL8153 Ethernet chip, to one hub port a JMS578 with EVO840 connected to another port a JMS578 with a Transcend TS120GMTS420 connected) and when I started the usual iozone benchmark underpowering (this time I would suspect undercurrent and not undervoltage as it's usual with XU4) happened. Problems/benchmark started at '239.752135': http://sprunge.us/JOMC (these are no UAS problems but just the usual symptoms of underpowering with loaded uas driver)

Currently yes... there is a difference since the dedicated OMV images contain a lot more tweaks. But that's the reason why I spent some minutes to prepare https://pastebin.com/ctLWTq2Q for Igor (he only has to find a solution wrt log2ram vs folder2ram, the 1 minute cron job that improves IO snappiness especially on slow boards and the Cloudshell 2 support stuff from Hardkernel). And no... users won't complain since average users aren't able to realize the difference 20 MB/s more or less make or whether handling of small files improves or not. Surprisingly people buy slow boards like Banana Pis with pleasure since 'native SATA' (slow as hell) and try to avoid fast NAS boards like HC1, ROCK64 since 'USB but no native SATA'. Direct comparison: https://forum.armbian.com/index.php?/topic/5036-looking-for-board-for-nas/&do=findComment&comment=38363

And another update, this time on USB3 performance. Since today a small M.2 SSD arrived I immediately tested with native SATA on a Clearfog Pro and I also gave it a try in a tiny JMS578 enclosure now with ROCK64 (details for both SSD and enclosure). Storage performance measured with the usual iozone call with SATA (to show the SSD's performance) and then attached to ROCK64's USB3 port, first with BSP kernel (4.4.77), then mainline 4.13-rc1: TS120GMTS420 SATA Clearfog random random kB reclen write rewrite read reread read write 102400 4 86865 124684 140973 140224 32522 101844 102400 16 206105 251838 293776 282729 84623 202503 102400 512 363707 377155 409380 401946 358966 372971 102400 1024 364578 358095 402539 404249 387812 376067 102400 16384 310808 407947 500231 497107 470879 398703 3072000 16384 420958 403649 509368 507120 469027 405752 TS120GMTS420 JMS578 ROCK64 4.4.77 1296 MHz random random kB reclen write rewrite read reread read write 102400 4 25793 31181 36545 38058 19837 32840 102400 16 74689 87314 127011 127494 62706 88478 102400 512 298948 322459 323666 325943 304947 311285 102400 1024 333159 343551 348576 351217 329950 344678 102400 16384 369142 377884 377184 380461 362302 359235 3072000 16384 374446 380254 382541 381844 363431 379725 TS120GMTS420 JMS578 ROCK64 4.13.0-rc1 random random kB reclen write rewrite read reread read write 102400 4 18098 22215 22757 22750 17104 21932 102400 16 61487 73079 75408 75522 56182 73369 102400 512 287554 299840 281735 283843 283678 300074 102400 1024 299159 314982 295748 297612 297422 305827 102400 16384 249205 357761 341508 343535 343730 346455 3072000 16384 350303 346587 346114 346187 346233 341654 As expected USB3 performance numbers lower compared to native SATA on the Clearfog Pro. But why do the mainline kernel results look that bad? Since no cpufreq scaling is working here and we're running the SoC with just 600 MHz set by u-boot. Now let's test again with BSP kernel limiting here cpufreq also to 600 MHz instead of 1296 MHz: TS120GMTS420 JMS578 ROCK64 4.4.77 600 MHz random random kB reclen write rewrite read reread read write 102400 4 15937 21334 25571 25576 17430 21122 102400 16 53353 65892 86114 85993 50773 65037 102400 512 273837 288669 276365 278220 261956 290194 102400 1024 296038 321502 309817 311969 293723 321893 102400 16384 363437 374665 344870 350489 345225 372353 3072000 16384 357195 367268 364944 365021 344555 367027 Now the above 4.13 numbers look a lot better!

It would be helpful if you stated why do you want to change or upgrade your current setup (i.e. are you looking for better performance or not) and what is "cheap" for you. Also don't know why are you looking for a credit card format board because it will limit your options. I would recommend looking at least at these 3 options: NanoPi NEO + NAS kit v1.2 Odroid HC1 Rock64 + any good USB3-SATA adapter

The used SBC has an influence since it bottlenecks the tests by card interface and maybe also CPU. The used OS has an influence since it bottlenecks the tests by default cpufreq scaling settings. That's the reason the numbers on page 1 were all done with the same device and same settings (performance governor, everything explained in the 1st post in 'Preparations' section at the top). Most SBC (all Allwinner based) show a transfer speed limitation due to SDIO interface between SoC and card (so sequential transfer speeds are limited to ~23MB/s anyway and this same limitation also bottlenecks random performance number of very fast cards). But since most SBC are bottlenecked by this interface limitation numbers are also quite realistic. The exceptions to this rule are Raspberries (where you can 'overclock' the SD card interface if you hate your data), the Tinkerboard, almost all ODROIDs and in general most newer boards like ROCK64. But as usual settings matter a lot, see this example here with different minimum cpufreq settings (affecting cpufreq scaling latency to reach higher clockspeeds which are needed for good IO performance): https://tinkerboarding.co.uk/forum/thread-310.html In other words: Most user contributed numbers here are for the bin if they're not accompanied by a clearly documented test procedure (which board, which kernel variant, which cpufreq governor -- everything else than performance and the numbers don't tell anything about the SD card or eMMC any more -- and which cpufreq scaling limits)

I repeated this test yesterday after I found why my H5 openssl benchmark scores were that low: since I was testing there with an armhf userland and not an arm64 one (32-bit vs. 64-bit but in this case more importantly: compiler switches forbid the use of ARMv8 crypto extensions when building armhf binaries). I also set up my 'monitoring PSU' stuff (letting a Banana Pro provide power to ROCK64 to be able to measure consumption without PSU being involved) and get the following consumption/performance numbers (on a 4GB pre-production sample -- there are some significant changes on production boards so idle / Ethernet consumption might differ!): idle @ 408 MHz / legacy kernel: 1450 mW When switching GbE to Fast Ethernet: 1100 mW (the usual 350mW drop) after poweroff: 580 mW (so there's currently some stuff missing and the board does not really power off cleanly) Testing with armhf userland walking through 408, 816 and 1200 MHz DVFS operating points: armhf 408 MHz: 52,000k / 1360mW --> 260 mW armhf 816 MHz: 104,000k / 1710mW --> 610 mW armhf 1200 MHz: 153,000k / 2790mW --> 1690 mW Now with arm64 (and Debian Stretch and different idle consumption since Gigabit is enabled): arm64 408 MHz: 730,000k / 1730mW --> 280 mW arm64 816 MHz: 1,508,000k / 2170mW --> 720 mW arm64 1200 MHz: 2,200,000k / 3340mW --> 1890 mW With ARMv8 crypto extensions active we see a slight increase in consumption (and temperature -- with armhf temp maxed out at 76"C at 1200 MHz while the arm64 tests triggered some throttling after 6 minutes since no heatsink applied to RK3328 and SoC temp exceeded 80°C at an ambient temp of 26°C). But the performance increase is massive (14 times faster).

Another small update on why settings/details matter. FriendlyELEC's NanoPi M3 isn't the best choice for a NAS since while featuring Gigabit Ethernet (+940 Mbits/sec possible) it has only USB2/Hi-Speed as potential storage interface and all USB2 receptacles are behind an internal USB hub (and have to share bandwidth therefore). So we're talking about 37MB/s max anyway with the MassStorage/BOT protocol and maybe up to 42-43 MB/s if USB Attached SCSI (UAS) would be available. I tested a bit around with NanoPi M3 last year but since storage performance was already way too low (26.5/31 MB/s write/read) I didn't test NAS performance. Since we're in the meantime able to run this board with mainline kernel I gave it a try again: https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=38120 Now we get a nice performance increase when testing storage locally: 26.5/31 MB/s write/read back then, now 35/37.5 MB/s (or 8.5/6.5 MB/s more). I had to make a minor correction to our build system to get decent storage performance with our chosen ondemand cpufreq governor too and the other important difference compared to situation with M3's 3.4 kernel is that with the old kernel IRQs are processed on all CPU cores in parallel while we can now choose fixed IRQ affinity (letting interrupts for various stuff be always processed on the same CPU core): https://github.com/armbian/build/blob/4f08c97d745892b6d664b96f8a4f84f48ee1f53f/packages/bsp/common/etc/init.d/armhwinfo#L255-L267 Without that fix it would look like this since all IRQs are processed on cpu0: After fixing IRQ affinity and with the ondemand tweaks active (to get the CPU cores clocking up from 400 MHz to 1400 MHz instantly as soon as IO activity is happening) we're talking about: This is not that impressive as with ROCK64 above where we get 15-20 MB/s more just by taking care of settings but it's a nice little performance boost we get for free (just by taking time and care of settings). What's missing is UAS support, given the Nexell SoC's USB IP can be UAS enabled (requires most probably changes to the USB host controller driver) we would get an additional ~5 MB/s in both directions. Then we would talk about 20/25 MB/s NAS throughput with the old kernel (and active IRQ balancing and inappopriate settings) vs. 38/39 (or even 39/40) MB/s with mainline kernel, fixed/optimized IRQ affinity and UAS. Settings matter

A noob question. Rock64 has a usb3 port, and there is possibility to attach a SATA-USB adapter there, like that one, Pine64 sells in their store. Hardkernel has added such a bridge right into the board with their new HC1. I am wondering (since I have no possibility to check this directly), how these bridges represent themselves to the host - more specifically - do they expose themselves as AHCI/SATA controllers, the same way as their x86 brothers sitting on PCIe do? Everybody is talking about UAS here, so probably they don't expose their SATA nature (more then that SAT thing), but I am a total ignorant with respect to USB internals yet, so I might be wrong presuming that if they exposed themselves as SATA controllers sitting on a USB bus, there were no need in UAS with them. If they don't act as pci-ide, ahci x86 counterparts, then why? why a SATA controller put on the SoC interconnect or PCIe bus can be a "native SATA", but not when put on USB?

Well, https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37015 (though using ARM crypto extensions is the better option of course). And the smaller memory footprint might have a huge performance impact once the system is running out of physical memory and has to use zram/swap instead.

That was just doing the math given that I knew A64 was clocked with 1152 MHz and then calculating clockspeed based on values for Pinebook and OPi PC 2 --> 815. So I assumed PC2 is running with 816 MHz. In the meantime I tested with my only H5 board (OPi Zero Plus 2 H5): openssl speed -elapsed -evp aes-256-cbc --> 26782.38k (Huh? What's going on here? Debug output). I again did some math (running sysbench on OPi PC2 and ROCK64, took both execution times, naively assuming PC2 running at 816 MHz again and then 'echo '11.2318 / 7.1657 * 816' | bc -l' --> 1279.03049248503286489152 (1296 MHz ROCK64 was running at). Why are my AES scores that low? Edit: Found a bug in armhwinfo. New armbianmonitor -u output here: http://sprunge.us/MdKL Since I found a spare SD card I couldn't resist to test with ROCK64 again (my first board with 2GB and an el cheapo heatsink applied). Debian Stretch, 'OpenSSL 1.1.0f 25 May 2017', same numbers as with Jessie when running single threaded. When testing AES256 with 4 threads it starts at almost 2,400,000k and after some time throttles down to 2,100,000k (it was even even below 2,050,000 but that was due to 'rock64_health.sh -w' running in parallel which is way too resource hungry in this mode updating every 0.5s): https://pastebin.com/Ck15UQv4