hjc

Members
  • Content Count

    92
  • Joined

  • Last visited


Reputation Activity

  1. Like
    hjc reacted to JMCC in [Development] RK3399 media script   
    So finally we have the first version of:
    The UN-official, UN-supported, etc...
    RK3399 MEDIA TESTING SCRIPT
     
    This is the first release of the RK3399 media testing script. The script provides a functionality similar to its RK3288 equivalent:
    Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 3.2 / OpenCL 1.2 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple). A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with:  Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
    Here is a more thorough documentation:
     
    >>> DOWNLOAD LINK <<<
     
    Prerequisites:
    You need a fresh Armbian Bionic desktop image with default kernel installed. IMPORTANT NOTE: For Kodi to work, you need to use a nightly kernel for most RK3399 boards. Otherwise, it will crash the system. I'm not sure about RockPro64, it will probably work with the stable image. Please test and let me know, I don't have the board.  
    Instructions:
    Download the file above Untar it: tar xvf media-rk3399_*.txz cd media-script ./media-rk3399.sh  
    Notes:
    This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
    Enjoy!
  2. Like
    hjc got a reaction from NicoD in NanoPI M4   
    I replaced the cable with a 0.25m USB Type-A to Type-C cable (a really cheap one), and it turns out that the voltage is much more stable. At full load+2*RTL8153, it's still up at ~4.97V, and multiple RTL8153 works like a charm now.
     
    However it seems that multiple RTL8153 behind a hub has some limitations. On the switch I can see traffic coming out on both USB attached ports, but they're only ~1.3Gbps total. When doing all port test (internal GbE+2 RTL8153, peer is 6*82583v configured with LACP), CPU0 is 100% and CPU2 is near 100%. I guess the A53 cores are not capable of handling such load. Anyway, currently the best choice seems to be attaching one additional RTL8153 for networking. It handles 2Gbps traffic in both directions simultaneously.
  3. Like
    hjc got a reaction from NicoD in NanoPI M4   
    So it's not a defect of the board, right? That's good news. I'd get some shorter cable w/ lower resistance and try to test 2*RTL8153 again.
  4. Like
    hjc got a reaction from NicoD in NanoPI M4   
    I can confirm that my M4 also has the voltage drop issue.
    1 RTL8153 connected, system idle: 4.9V Running iperf3 and generate 2Gbps traffic: 4.7V Running iperf3 with 6x cpuburn: 4.5V On NanoPC T4 the voltage is always 5.0V no matter what workload I run.
  5. Like
    hjc got a reaction from Faber in Freedombox on an Armbian supported SBC -- possible?   
    Stock Debian can install and boot on Firefly RK3399, however these new RK3399 boards' dts files are not mainlined yet, so it requires kernel/bootloader package modifications, and adding a board entry to flash-install db, or flash-install will fail.
     
    BTW: Stock Debian does not contain any of the armbian optimizations, so nothing will be as smooth as armbian runs.
  6. Like
    hjc got a reaction from SMburn in NanoPC T4   
    The M.2 connector on T4 does not support SATA, so you should get an NVMe SSD.
  7. Like
    hjc got a reaction from NicoD in NanoPi M4 performance and consumption review   
    I've been doing some tests with NanoPi M4 these days. While I'm not a professional board reviewer, here I can share some early performance numbers to you. Beware that none of these tests fit into real world use cases, they are just provided as-is. Besides, Armbian development on RK3399 boards are still at a very early stage, so any of these numbers may change in the future, due to software changes.
    Unless mentioned, all tests are done using Armbian nightly image, FriendlyARM 4.4 kernel, CPU clocked at 2.0/1.5GHz
     
    Powering
    NanoPi M4 is my first board powered by USB-C, while RK3399 is not power-hungry under normal load, I do doubt if 5V/3A power supply is sufficient when the CPU load goes higher, or when a lot of USB devices are connected. So I went a series of power measurement, with this tool

    That is to measure the power consumption on the USB side, excluding the consumption of PSU.
    The board is powered by the USB-C charger that came with my Huawei MateBook E, which supports 5V/2A, 9V/2A, and 12V/2A, so theoretically it is insufficient to power the NanoPi M4 board. Unfortunately I can't find a USB-C charger capable of 5V/3A output, and I have to do such test with it.
    What if I connected a lot of USB 3.0 device and exceeded the 5V/2A limit? Well, I did try that (connect 4 USB HDD and run cpuburn, or even connect 2 SBCs to the USB), and the answer is simple: the board crashed. But normally the board's consumption will not exceed 10W, so the charger works just fine.
     
    Test setup
    1) Idle consumption
    This is the typical consumption when you use it as an headless server.
     
    2) Idle consumption with HDMI display output (console tty interface, no Desktop/X11/GPU stuff)
    Testing with Dell P2415Q 4k 60Hz display. HDMI connected, with 2560*1440 60Hz video output. Also connect the USB 3.0 hub to
     
    3) Display connected, 802.11ac WiFi with iperf sending
    With HDMI display connected (same as (2)), and WiFi connected to 802.11ac 5GHz AP in another room, run the following command:
    iperf3 -c 10.24.0.1 -t 60 The WiFi throughput is around 110Mbps
     
    4) Display connected, running cpuburn
    With HDMI display connected (same as (2)), run cpuburn on all 6 cores
     
    5) Idle consumption of 4.19-rc1 mainline kernel
    Same as (1), but running mainline kernel.
     
    Test results

     
    The idle consumption is 1.79W, and it might need some tuning to reduce the consumption. When WiFi and display are connected, it goes higher to 2.87W.
    With an active WiFi networking, the board consumes 4.67W, and with all CPU cores active, it consumes 9.86W.
    Mainline kernel has a higher idle consumption, the reason might be DDR dvfs and/or devfreq are not implemented yet.
    Based on these results, it seems that 5V/2A power is okay if no peripheral devices are connected. However if you connect any USB devices, it may easily exceed the 2A limit when CPU load goes higher.
     
    CPU/RAM and IO Performance
    While RK3399 is not a super fast chip, its performance fits into its position. To reveal the full potential of the board, I'm posting some visualized sbc-bench results taken from mainline 4.19-rc1 kernel here. This is because there might be some DRAM performance issues on RK3399 with 4.4 kernel.. For comparison, I'm also posting the results of Firefly-RK3399 (2.2/1.8GHz overclock, tested by myself), Raspberry Pi 3 B+, ROCK64 and RockPro64 (taken from existing sbc-bench results)
     
    You can see the full sbc-bench log here.
     
    Memory

     
    7-zip

     
    cpuminer

     
    For IO performance, I use iozone to measure the performance of SD card, eMMC and USB SSD. NanoPC T4's NVMe SSD results are added as a reference.
    SSD performance are measured by command "iozone -e -I -a -s 1G -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2", SD card and eMMC are using 100M instead of 1G size.

     
    Networking
    NanoPi M4 comes with a 1Gbps ethernet port and a 802.11ac 2x2 MIMO WiFi module, and I tested both with iperf3.
    GbE iperf3 full duplex test:
    hjc@nanopim4:~$ iperf3 -c 10.20.0.1 & iperf3 -Rc 10.20.0.1 -p 5202 [1] 27486 Connecting to host 10.20.0.1, port 5201 Connecting to host 10.20.0.1, port 5202 Reverse mode, remote host 10.20.0.1 is sending [ 4] local 10.20.0.2 port 43782 connected to 10.20.0.1 port 5201 [ 4] local 10.20.0.2 port 45102 connected to 10.20.0.1 port 5202 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 64.6 MBytes 542 Mbits/sec [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 95.1 MBytes 798 Mbits/sec 0 314 KBytes [ 4] 1.00-2.00 sec 110 MBytes 919 Mbits/sec [ 4] 1.00-2.00 sec 94.5 MBytes 793 Mbits/sec 0 320 KBytes [ 4] 2.00-3.00 sec 110 MBytes 920 Mbits/sec [ 4] 2.00-3.00 sec 95.8 MBytes 803 Mbits/sec 0 317 KBytes [ 4] 3.00-4.00 sec 110 MBytes 920 Mbits/sec [ 4] 3.00-4.00 sec 94.5 MBytes 792 Mbits/sec 0 317 KBytes [ 4] 4.00-5.00 sec 110 MBytes 920 Mbits/sec [ 4] 4.00-5.00 sec 94.6 MBytes 794 Mbits/sec 0 314 KBytes [ 4] 5.00-6.00 sec 110 MBytes 919 Mbits/sec [ 4] 5.00-6.00 sec 95.7 MBytes 803 Mbits/sec 0 314 KBytes [ 4] 6.00-7.00 sec 110 MBytes 919 Mbits/sec [ 4] 6.00-7.00 sec 95.5 MBytes 801 Mbits/sec 0 317 KBytes [ 4] 7.00-8.00 sec 110 MBytes 920 Mbits/sec [ 4] 7.00-8.00 sec 94.8 MBytes 795 Mbits/sec 0 314 KBytes [ 4] 8.00-9.00 sec 110 MBytes 920 Mbits/sec [ 4] 8.00-9.00 sec 94.5 MBytes 792 Mbits/sec 0 314 KBytes [ 4] 9.00-10.00 sec 97.2 MBytes 816 Mbits/sec 0 320 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 952 MBytes 799 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 949 MBytes 796 Mbits/sec receiver [ 4] 9.00-10.00 sec 110 MBytes 921 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr iperf Done. [ 4] 0.00-10.00 sec 1.03 GBytes 884 Mbits/sec 9 sender [ 4] 0.00-10.00 sec 1.03 GBytes 882 Mbits/sec receiver iperf Done. [1] + 27486 done iperf3 -c 10.20.0.1  
    Wireless
    hjc@nanopim4:~$ iperf3 -c 10.24.0.1 Connecting to host 10.24.0.1, port 5201 [ 4] local 10.23.4.116 port 39730 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 13.0 MBytes 109 Mbits/sec 13 1.21 MBytes [ 4] 1.00-2.01 sec 12.9 MBytes 107 Mbits/sec 5 618 KBytes [ 4] 2.01-3.00 sec 12.6 MBytes 106 Mbits/sec 0 618 KBytes [ 4] 3.00-4.00 sec 9.35 MBytes 78.7 Mbits/sec 4 329 KBytes [ 4] 4.00-5.00 sec 11.1 MBytes 92.9 Mbits/sec 0 348 KBytes [ 4] 5.00-6.00 sec 10.2 MBytes 85.5 Mbits/sec 0 363 KBytes [ 4] 6.00-7.00 sec 9.37 MBytes 78.6 Mbits/sec 0 387 KBytes [ 4] 7.00-8.00 sec 10.9 MBytes 91.5 Mbits/sec 0 409 KBytes [ 4] 8.00-9.00 sec 13.6 MBytes 114 Mbits/sec 0 409 KBytes [ 4] 9.00-10.00 sec 13.8 MBytes 116 Mbits/sec 0 410 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 117 MBytes 98.0 Mbits/sec 22 sender [ 4] 0.00-10.00 sec 116 MBytes 97.0 Mbits/sec receiver iperf Done. hjc@nanopim4:~$ iperf3 -c 10.24.0.1 -R Connecting to host 10.24.0.1, port 5201 Reverse mode, remote host 10.24.0.1 is sending [ 4] local 10.23.4.116 port 39734 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 10.6 MBytes 88.8 Mbits/sec [ 4] 1.00-2.00 sec 10.9 MBytes 91.5 Mbits/sec [ 4] 2.00-3.00 sec 4.41 MBytes 37.0 Mbits/sec [ 4] 3.00-4.00 sec 2.07 MBytes 17.3 Mbits/sec [ 4] 4.00-5.00 sec 1018 KBytes 8.34 Mbits/sec [ 4] 5.00-6.00 sec 1.29 MBytes 10.8 Mbits/sec [ 4] 6.00-7.00 sec 6.48 MBytes 54.4 Mbits/sec [ 4] 7.00-8.00 sec 10.8 MBytes 91.0 Mbits/sec [ 4] 8.00-9.00 sec 10.7 MBytes 89.9 Mbits/sec [ 4] 9.00-10.00 sec 10.7 MBytes 89.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 70.1 MBytes 58.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 69.1 MBytes 58.0 Mbits/sec receiver iperf Done. It's too complicated to analyze the performance of a WiFi connection, but so far I've never seen more than 200Mbps throughput on AP6356S.
  8. Like
    hjc got a reaction from tkaiser in NanoPi NEO4   
    Actually USB was never a good choice for networking especially when using behind a hub. I tested various setups and the only one that could actually work stably is with (only) one RTL8153 connected. If I connect 2 or more, as soon as I start stress testing (full duplex iperf on all connected NIC), the whole internal hub goes down in a few seconds (dmesg shows the internal hub is disconnected, lsusb -t only shows the root hub) and I have to do a USB reset or reboot the device to get that back again. I'm powering the board with official 5V/4A PSU so the board itself should be fine, but there still seems to be a current limit on the internal USB hub.
     
    One RTL8153 combined with the internal GbE, however, works smoothly. I even tried to configure LACP with my CRS326 switch.

    bonding1=ether1+ether2 (NanoPi M4)
    bonding2=ether5+ether6+ether7 (NanoPC T4)
    tested with iperf3 -P 2. With layer3+4 hash, two connections can easily use up to 2Gbps bandwidth between two devices.
     
    PCIe cards would definitely be better, though I don't know how many people seriously want to use RK3399 devices as a router.
     
  9. Like
    hjc got a reaction from 5kft in NanoPi NEO4   
    Now FriendlyARM has a wiki page for NEO4.
  10. Like
    hjc got a reaction from TonyMac32 in NanoPi NEO4   
    Now FriendlyARM has a wiki page for NEO4.
  11. Like
    hjc got a reaction from gounthar in NanoPi NEO4   
    Now FriendlyARM has a wiki page for NEO4.
  12. Like
    hjc got a reaction from tkaiser in NanoPi NEO4   
    Now FriendlyARM has a wiki page for NEO4.
  13. Like
    hjc reacted to mindee in NanoPi M4 performance and consumption review   
    Thanks for your suggestion, we made a SATA HAT prototype for NanoPi M4, it can connect  with 4x 3.5inch hard drive and work well.
     
     
  14. Like
    hjc got a reaction from gounthar in (Serial) console access via 'USB-UART/Gadget mode' on Linux/Windows/OSX   
    It works great on Windows Server 2016 (so probably Windows 10, too). Now I'm playing with my NanoPi on the desktop workstation in my office.
     

     
    It's easy to use, run devmgmt.msc, find the serial device, then go with putty.
  15. Like
    hjc got a reaction from tkaiser in (Serial) console access via 'USB-UART/Gadget mode' on Linux/Windows/OSX   
    It works great on Windows Server 2016 (so probably Windows 10, too). Now I'm playing with my NanoPi on the desktop workstation in my office.
     

     
    It's easy to use, run devmgmt.msc, find the serial device, then go with putty.
  16. Like
    hjc got a reaction from botfap in Banana PI BPI-W2   
    You're not alone, many board makers have to sign NDA with chip vendors. For example, when Dragonboard 820c was under development, they signed NDA with Qualcomm, and they must get approval before releasing Qualcomm kernel/bootloader sources.
    However before they got the approval to release kernel/bootloader source code, they didn't even release the board, nor any GPL-licensed binaries. You should follow the rules, too.
  17. Like
    hjc got a reaction from esbeeb in Have "Supported" boards been "Torture-Tested" for storage/disk-IO?   
    Actually the 4.4 kernel is quite stable, however Armbian development on this board is still in early stages, so it's marked as WIP. It means many optimizations may have not been applied yet (e.g. interrupts), and many configurations may be changed later (e.g. board family change requires a manual upgrade). If you are an experienced Linux user, this may not be a problem.
     
    There are a few other boards with fast native SATA or capable of PCIe SATA supported by Armbian, e.g. Helios4, EspressoBin, Clearfog Pro.
  18. Like
    hjc got a reaction from tkaiser in NanoPi M4 performance and consumption review   
    Not yet, recently I'm trying to use M4 (with mainline kernel) as a network router & gateway (connect 2-3 RTL8153, set up VLAN, routing, NAT, and site to site VPN), and still trying to resolve some USB related issues. Currently with mainline kernel the USB hub must be manually reset (USBDEVFS_RESET) after reboot, or it wouldn't be usable.
  19. Like
    hjc got a reaction from Lion Wang in Banana PI BPI-W2   
    You're not alone, many board makers have to sign NDA with chip vendors. For example, when Dragonboard 820c was under development, they signed NDA with Qualcomm, and they must get approval before releasing Qualcomm kernel/bootloader sources.
    However before they got the approval to release kernel/bootloader source code, they didn't even release the board, nor any GPL-licensed binaries. You should follow the rules, too.
  20. Like
    hjc reacted to tkaiser in NanoPi M4 performance and consumption review   
    I'm now also testing IO performance on NanoPi M4 to get an idea how much influence the integrated VIA VL817 USB3 hub has. The following test command is used since I test with an el cheapo Samsung EVO 840 (known to exceed 500 MB/s on a SATA port but low capacity and implementing TurboWrite)
    taskset -c 4 iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 sleep 300 taskset -c 4 iozone -e -I -a -s 2000M -r 16384k -i 0 -i 1 -i 2 Why do I test first with 100 MB, then wait 5 minutes and test again with 2 GB?
    Tests with 100 MB to keep results comparable with my previous collection An additional test with 2 GB since we found that with fast USB3 implementations and fast SSDs the maximum throughput isn't reported when testing with low test sizes. 1GB or better 2GB seem like a reasonable additional test to look for real maximum bandwidth possible Why waiting for 5 minutes (sleep 300) in between? Since my 128GB EVO840 implements TurboWrite and therefore is only capable to write data at maximum speed until the TurboWrite buffer is full. So if I would've tested all block sizes with 1GB test data size the EVO itself would've turned into a bottleneck after approx. 2.5GB data written Why 'taskset -c 4' (executing the test on a big core)? Since we're looking for maximum performance here Raw results as follows
    random random kB reclen write rewrite read reread read write 102400 4 25559 28658 21964 22012 21957 28183 102400 16 84846 94435 80322 80926 81083 92975 102400 512 325556 326434 289616 292997 294076 322974 102400 1024 347800 362005 324009 327371 329460 352963 102400 16384 381091 386458 370522 373441 373337 378399 2048000 16384 401465 402916 375361 375457 375509 398665 In other words: Even with an USB3 hub in between storage performance is excellent as long as only one disk is connected (with more than one disk and accesses in parallel performance will of course drop since then bus contention issues might occur and bandwidth has to be shared). But with HDDs this is no issue at all since they're too slow anyway.
     
    Storage performance summary: I've had some fear that the internal USB3 hub will trash storage performance but that's not true (at least when only one disk is connected). As a reference numbers generated with same SSD, same settings and same test methodology on discontinued ODROID-N1 (as an example for RK3399 USB3 without hub and also with same SSD connected to a cheap PCIe SATA controller):
    Random IO in IOPS Sequential IO in MB/sec 4K read/write 1M read/write ODROID-N1 5994/6308 330 / 340 NanoPi M4 5489/7045 330 / 355 ASM1061 powersave 6010/7900 320 / 325 ASM1061 performance 9820/16230 330 / 330 The ASM1061 numbers are especially dedicated to all those SBC users believing into 'native SATA'. Sequential storage performance with a good UAS capable USB3-to-SATA bridge is higher compared to cheap PCIe SATA controllers. 'Native' SATA does not exist with RK3399 anyway and for really high SATA storage performance more expensive SATA controllers making use of more than 1 PCIe lane are necessary. But with just an ASM1061 the only two real benefits of PCIe attached SATA over USB3 attached SATA are
    higher random IO performance less IRQs to process which results in less CPU utilization (see ODROID-N1 link above) But to attach one or two USB3 HDDs and share them at maximum speed (~100 MB/s through network) the NanoPi M4 is perfectly fine.
     
    Edit: Debug output here. We can see the usual 'ERROR Transfer event for disabled endpoint or incorrect stream ring' XHCI error when connecting an USB3 disk enclosure the first time (known problem but doesn't cause any harm) and amount of DRAM is reported differently since I swapped the SD card between my two NanoPi M4
  21. Like
    hjc got a reaction from codnoscope in ROC-RK3399-PC (Renegade Elite)   
    That might be true, since there's already an RK3399Pkg (haven't tried myself), but I'd still recommend u-boot, unless you are interested in one of the following use cases:
    1. CentOS/Fedora/openSUSE, based on UEFI and grub on ARM64. These distros are mostly made for servers, instead of IoT stuff, so if you want something like KVM on ARM64, you could try to use them. But I doubt RK3399's 4G RAM could ever handle virtual machines. If you really want an ARM64 server, I recommend more serious solutions like Qualcomm centriq or Cavium ThunderX. If you just want to isolate your own code into different environments, use lxc/lxd or docker on (u-boot based) Armbian.
    2. Windows on ARM64, requires UEFI and ACPI. I'd admit it's quite attractive lightweight desktop solution, and it can even handle simple x86 programs as well. There's already someone made this for Raspberry Pi 3, but just forget it, that's definitely unusable, considering the horribly slow IO of RPi and the crazy (heavily IO bounded) background tasks of the most bloated desktop OS on the earth. On RK3399, yes, I think it is possible to handle Windows' crazy background IO with a USB or SATA or even NVMe SSD (actually a good eMMC could handle that as well), but you'll need to write a lot of Windows drivers to bring up a new platform, including SDIO, eMMC, USB, GMAC, PCIe, and the most difficult part, display drivers (like Rockchip DRM on Linux) on your own or you have to use the (probably slow as hell) UEFI GOP for display. GPU is actually not needed to run Windows desktop, and probably not possible unless you are an employee of ARM Holdings and has the source code of the Mali GPU Windows drivers which has never been released before but actually does exist. The assumptions above are all based on the fact that ACPI was implemented properly, and I don't think this would be true. You can implement ACPI on your own, though.
     
    I don't have any other idea to convince myself that UEFI would be useful on this platform. What's the exact use case you're expecting to do with UEFI?
     
    IMO The biggest and only problem so far for all RK3399 boards is pricing. And this was the reason that I was excited about NanoPi M4, since it had a much lower price while keeping the essential components on board (like WiFi/BT). Unfortunately, people around me still think $65 is a little too high for an SBC when I recommend the board to them. For most people, purchasing a $99 (or higher) SBC is really a crazy idea, even if Armbian has great support for it.
     
  22. Like
    hjc got a reaction from gounthar in ROC-RK3399-PC (Renegade Elite)   
    That might be true, since there's already an RK3399Pkg (haven't tried myself), but I'd still recommend u-boot, unless you are interested in one of the following use cases:
    1. CentOS/Fedora/openSUSE, based on UEFI and grub on ARM64. These distros are mostly made for servers, instead of IoT stuff, so if you want something like KVM on ARM64, you could try to use them. But I doubt RK3399's 4G RAM could ever handle virtual machines. If you really want an ARM64 server, I recommend more serious solutions like Qualcomm centriq or Cavium ThunderX. If you just want to isolate your own code into different environments, use lxc/lxd or docker on (u-boot based) Armbian.
    2. Windows on ARM64, requires UEFI and ACPI. I'd admit it's quite attractive lightweight desktop solution, and it can even handle simple x86 programs as well. There's already someone made this for Raspberry Pi 3, but just forget it, that's definitely unusable, considering the horribly slow IO of RPi and the crazy (heavily IO bounded) background tasks of the most bloated desktop OS on the earth. On RK3399, yes, I think it is possible to handle Windows' crazy background IO with a USB or SATA or even NVMe SSD (actually a good eMMC could handle that as well), but you'll need to write a lot of Windows drivers to bring up a new platform, including SDIO, eMMC, USB, GMAC, PCIe, and the most difficult part, display drivers (like Rockchip DRM on Linux) on your own or you have to use the (probably slow as hell) UEFI GOP for display. GPU is actually not needed to run Windows desktop, and probably not possible unless you are an employee of ARM Holdings and has the source code of the Mali GPU Windows drivers which has never been released before but actually does exist. The assumptions above are all based on the fact that ACPI was implemented properly, and I don't think this would be true. You can implement ACPI on your own, though.
     
    I don't have any other idea to convince myself that UEFI would be useful on this platform. What's the exact use case you're expecting to do with UEFI?
     
    IMO The biggest and only problem so far for all RK3399 boards is pricing. And this was the reason that I was excited about NanoPi M4, since it had a much lower price while keeping the essential components on board (like WiFi/BT). Unfortunately, people around me still think $65 is a little too high for an SBC when I recommend the board to them. For most people, purchasing a $99 (or higher) SBC is really a crazy idea, even if Armbian has great support for it.
     
  23. Like
    hjc got a reaction from tkaiser in ROC-RK3399-PC (Renegade Elite)   
    That might be true, since there's already an RK3399Pkg (haven't tried myself), but I'd still recommend u-boot, unless you are interested in one of the following use cases:
    1. CentOS/Fedora/openSUSE, based on UEFI and grub on ARM64. These distros are mostly made for servers, instead of IoT stuff, so if you want something like KVM on ARM64, you could try to use them. But I doubt RK3399's 4G RAM could ever handle virtual machines. If you really want an ARM64 server, I recommend more serious solutions like Qualcomm centriq or Cavium ThunderX. If you just want to isolate your own code into different environments, use lxc/lxd or docker on (u-boot based) Armbian.
    2. Windows on ARM64, requires UEFI and ACPI. I'd admit it's quite attractive lightweight desktop solution, and it can even handle simple x86 programs as well. There's already someone made this for Raspberry Pi 3, but just forget it, that's definitely unusable, considering the horribly slow IO of RPi and the crazy (heavily IO bounded) background tasks of the most bloated desktop OS on the earth. On RK3399, yes, I think it is possible to handle Windows' crazy background IO with a USB or SATA or even NVMe SSD (actually a good eMMC could handle that as well), but you'll need to write a lot of Windows drivers to bring up a new platform, including SDIO, eMMC, USB, GMAC, PCIe, and the most difficult part, display drivers (like Rockchip DRM on Linux) on your own or you have to use the (probably slow as hell) UEFI GOP for display. GPU is actually not needed to run Windows desktop, and probably not possible unless you are an employee of ARM Holdings and has the source code of the Mali GPU Windows drivers which has never been released before but actually does exist. The assumptions above are all based on the fact that ACPI was implemented properly, and I don't think this would be true. You can implement ACPI on your own, though.
     
    I don't have any other idea to convince myself that UEFI would be useful on this platform. What's the exact use case you're expecting to do with UEFI?
     
    IMO The biggest and only problem so far for all RK3399 boards is pricing. And this was the reason that I was excited about NanoPi M4, since it had a much lower price while keeping the essential components on board (like WiFi/BT). Unfortunately, people around me still think $65 is a little too high for an SBC when I recommend the board to them. For most people, purchasing a $99 (or higher) SBC is really a crazy idea, even if Armbian has great support for it.
     
  24. Like
    hjc got a reaction from gounthar in NanoPi M4 performance and consumption review   
    I've been doing some tests with NanoPi M4 these days. While I'm not a professional board reviewer, here I can share some early performance numbers to you. Beware that none of these tests fit into real world use cases, they are just provided as-is. Besides, Armbian development on RK3399 boards are still at a very early stage, so any of these numbers may change in the future, due to software changes.
    Unless mentioned, all tests are done using Armbian nightly image, FriendlyARM 4.4 kernel, CPU clocked at 2.0/1.5GHz
     
    Powering
    NanoPi M4 is my first board powered by USB-C, while RK3399 is not power-hungry under normal load, I do doubt if 5V/3A power supply is sufficient when the CPU load goes higher, or when a lot of USB devices are connected. So I went a series of power measurement, with this tool

    That is to measure the power consumption on the USB side, excluding the consumption of PSU.
    The board is powered by the USB-C charger that came with my Huawei MateBook E, which supports 5V/2A, 9V/2A, and 12V/2A, so theoretically it is insufficient to power the NanoPi M4 board. Unfortunately I can't find a USB-C charger capable of 5V/3A output, and I have to do such test with it.
    What if I connected a lot of USB 3.0 device and exceeded the 5V/2A limit? Well, I did try that (connect 4 USB HDD and run cpuburn, or even connect 2 SBCs to the USB), and the answer is simple: the board crashed. But normally the board's consumption will not exceed 10W, so the charger works just fine.
     
    Test setup
    1) Idle consumption
    This is the typical consumption when you use it as an headless server.
     
    2) Idle consumption with HDMI display output (console tty interface, no Desktop/X11/GPU stuff)
    Testing with Dell P2415Q 4k 60Hz display. HDMI connected, with 2560*1440 60Hz video output. Also connect the USB 3.0 hub to
     
    3) Display connected, 802.11ac WiFi with iperf sending
    With HDMI display connected (same as (2)), and WiFi connected to 802.11ac 5GHz AP in another room, run the following command:
    iperf3 -c 10.24.0.1 -t 60 The WiFi throughput is around 110Mbps
     
    4) Display connected, running cpuburn
    With HDMI display connected (same as (2)), run cpuburn on all 6 cores
     
    5) Idle consumption of 4.19-rc1 mainline kernel
    Same as (1), but running mainline kernel.
     
    Test results

     
    The idle consumption is 1.79W, and it might need some tuning to reduce the consumption. When WiFi and display are connected, it goes higher to 2.87W.
    With an active WiFi networking, the board consumes 4.67W, and with all CPU cores active, it consumes 9.86W.
    Mainline kernel has a higher idle consumption, the reason might be DDR dvfs and/or devfreq are not implemented yet.
    Based on these results, it seems that 5V/2A power is okay if no peripheral devices are connected. However if you connect any USB devices, it may easily exceed the 2A limit when CPU load goes higher.
     
    CPU/RAM and IO Performance
    While RK3399 is not a super fast chip, its performance fits into its position. To reveal the full potential of the board, I'm posting some visualized sbc-bench results taken from mainline 4.19-rc1 kernel here. This is because there might be some DRAM performance issues on RK3399 with 4.4 kernel.. For comparison, I'm also posting the results of Firefly-RK3399 (2.2/1.8GHz overclock, tested by myself), Raspberry Pi 3 B+, ROCK64 and RockPro64 (taken from existing sbc-bench results)
     
    You can see the full sbc-bench log here.
     
    Memory

     
    7-zip

     
    cpuminer

     
    For IO performance, I use iozone to measure the performance of SD card, eMMC and USB SSD. NanoPC T4's NVMe SSD results are added as a reference.
    SSD performance are measured by command "iozone -e -I -a -s 1G -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2", SD card and eMMC are using 100M instead of 1G size.

     
    Networking
    NanoPi M4 comes with a 1Gbps ethernet port and a 802.11ac 2x2 MIMO WiFi module, and I tested both with iperf3.
    GbE iperf3 full duplex test:
    hjc@nanopim4:~$ iperf3 -c 10.20.0.1 & iperf3 -Rc 10.20.0.1 -p 5202 [1] 27486 Connecting to host 10.20.0.1, port 5201 Connecting to host 10.20.0.1, port 5202 Reverse mode, remote host 10.20.0.1 is sending [ 4] local 10.20.0.2 port 43782 connected to 10.20.0.1 port 5201 [ 4] local 10.20.0.2 port 45102 connected to 10.20.0.1 port 5202 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 64.6 MBytes 542 Mbits/sec [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 95.1 MBytes 798 Mbits/sec 0 314 KBytes [ 4] 1.00-2.00 sec 110 MBytes 919 Mbits/sec [ 4] 1.00-2.00 sec 94.5 MBytes 793 Mbits/sec 0 320 KBytes [ 4] 2.00-3.00 sec 110 MBytes 920 Mbits/sec [ 4] 2.00-3.00 sec 95.8 MBytes 803 Mbits/sec 0 317 KBytes [ 4] 3.00-4.00 sec 110 MBytes 920 Mbits/sec [ 4] 3.00-4.00 sec 94.5 MBytes 792 Mbits/sec 0 317 KBytes [ 4] 4.00-5.00 sec 110 MBytes 920 Mbits/sec [ 4] 4.00-5.00 sec 94.6 MBytes 794 Mbits/sec 0 314 KBytes [ 4] 5.00-6.00 sec 110 MBytes 919 Mbits/sec [ 4] 5.00-6.00 sec 95.7 MBytes 803 Mbits/sec 0 314 KBytes [ 4] 6.00-7.00 sec 110 MBytes 919 Mbits/sec [ 4] 6.00-7.00 sec 95.5 MBytes 801 Mbits/sec 0 317 KBytes [ 4] 7.00-8.00 sec 110 MBytes 920 Mbits/sec [ 4] 7.00-8.00 sec 94.8 MBytes 795 Mbits/sec 0 314 KBytes [ 4] 8.00-9.00 sec 110 MBytes 920 Mbits/sec [ 4] 8.00-9.00 sec 94.5 MBytes 792 Mbits/sec 0 314 KBytes [ 4] 9.00-10.00 sec 97.2 MBytes 816 Mbits/sec 0 320 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 952 MBytes 799 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 949 MBytes 796 Mbits/sec receiver [ 4] 9.00-10.00 sec 110 MBytes 921 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr iperf Done. [ 4] 0.00-10.00 sec 1.03 GBytes 884 Mbits/sec 9 sender [ 4] 0.00-10.00 sec 1.03 GBytes 882 Mbits/sec receiver iperf Done. [1] + 27486 done iperf3 -c 10.20.0.1  
    Wireless
    hjc@nanopim4:~$ iperf3 -c 10.24.0.1 Connecting to host 10.24.0.1, port 5201 [ 4] local 10.23.4.116 port 39730 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 13.0 MBytes 109 Mbits/sec 13 1.21 MBytes [ 4] 1.00-2.01 sec 12.9 MBytes 107 Mbits/sec 5 618 KBytes [ 4] 2.01-3.00 sec 12.6 MBytes 106 Mbits/sec 0 618 KBytes [ 4] 3.00-4.00 sec 9.35 MBytes 78.7 Mbits/sec 4 329 KBytes [ 4] 4.00-5.00 sec 11.1 MBytes 92.9 Mbits/sec 0 348 KBytes [ 4] 5.00-6.00 sec 10.2 MBytes 85.5 Mbits/sec 0 363 KBytes [ 4] 6.00-7.00 sec 9.37 MBytes 78.6 Mbits/sec 0 387 KBytes [ 4] 7.00-8.00 sec 10.9 MBytes 91.5 Mbits/sec 0 409 KBytes [ 4] 8.00-9.00 sec 13.6 MBytes 114 Mbits/sec 0 409 KBytes [ 4] 9.00-10.00 sec 13.8 MBytes 116 Mbits/sec 0 410 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 117 MBytes 98.0 Mbits/sec 22 sender [ 4] 0.00-10.00 sec 116 MBytes 97.0 Mbits/sec receiver iperf Done. hjc@nanopim4:~$ iperf3 -c 10.24.0.1 -R Connecting to host 10.24.0.1, port 5201 Reverse mode, remote host 10.24.0.1 is sending [ 4] local 10.23.4.116 port 39734 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 10.6 MBytes 88.8 Mbits/sec [ 4] 1.00-2.00 sec 10.9 MBytes 91.5 Mbits/sec [ 4] 2.00-3.00 sec 4.41 MBytes 37.0 Mbits/sec [ 4] 3.00-4.00 sec 2.07 MBytes 17.3 Mbits/sec [ 4] 4.00-5.00 sec 1018 KBytes 8.34 Mbits/sec [ 4] 5.00-6.00 sec 1.29 MBytes 10.8 Mbits/sec [ 4] 6.00-7.00 sec 6.48 MBytes 54.4 Mbits/sec [ 4] 7.00-8.00 sec 10.8 MBytes 91.0 Mbits/sec [ 4] 8.00-9.00 sec 10.7 MBytes 89.9 Mbits/sec [ 4] 9.00-10.00 sec 10.7 MBytes 89.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 70.1 MBytes 58.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 69.1 MBytes 58.0 Mbits/sec receiver iperf Done. It's too complicated to analyze the performance of a WiFi connection, but so far I've never seen more than 200Mbps throughput on AP6356S.
  25. Like
    hjc reacted to Igor in Firefly RK3399 support efforts (potential csc board?)   
    Don't have this board. Untested.
    https://dl.armbian.com/firefly-rk3399/