Search the Community

Showing results for tags 'review'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues / peer to peer technical support
    • Reviews, Tutorials, Hardware hacks
    • Help wanted
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker - supported boards and images only
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner A64, H5 and H6
    • Armada A388, A3700
    • Amlogic S905(x), S922X
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Rockchip 3399
    • Other supported boards
  • Development
    • Development
  • TV Boxes's General Chat
  • TV Boxes's Reviews/Tutorials
  • TV Boxes's FAQ
  • TV Boxes's TV Boxes running Armbian
  • TV Boxes's Rockchip CPU Boxes
  • TV Boxes's Amlogic CPU Boxes
  • TV Boxes's Allwinner CPU Boxes
  • Android fanboys's Forums
  • Gaming on ARM's Reviews
  • Gaming on ARM's Issues
  • Kobol Forum's Helios4
  • Kobol Forum's Helios64

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP


Skype


Github


Location


Interests

  1. Hi al. I've finished my review of the PineBook Pro. I just love this thing. Runs great with Armbian. Here my video. Here all my gathered information:
  2. Hi all. I again had the pleasure of working with an amazing server. This time the AMD Threadripper 3990X, 64-cores and 128 threads. After last week working on a 32-core ARM server I thought I had seen performance. This is again not comparable with anything before. I again got private SSH access. So I opened 3 terminals. One with HTop, another to check sensors. And the 3th to execute my benchmarks. First thing I saw were the 128-threads. Being used to seeing 6, this was almost unbelievable. With light loads it turbo's up to 4.3Ghz. All cores maxed out @ 3Ghz while consuming 400W. Reaching a single core 7zip decompression score of 4545MIPS @ 4.3Ghz. The Ampere 32-core ARM server at 3.3Ghz reached 2763. This again shows the Ampere server doesn't use high performance cores. It doesn't perform great per clock. Coming soon is a benchmark of an AWS server. This uses high performance cores based on the ARM N1 cores. A derivative of the A76. This reaches 3393. This clocked at only 2.5Ghz. So this does perform better per clock. Do know this is comparing peers with bananas(don't want to confuse with apples). And scoring 391809MIPS with 7zip multi-core decompression with default settings. Then with an overclock to 3.9Ghz all cores it consumed +600W. With a 7zip decompression score of 433702MIPS This is again so many levels better than the Ampere 32-core ARM server which got 85975MIPS. 32-cores of the AWS graviton2 does 110628. So this AMD server is up to 5 x more powerful when overclocked, than the Ampere 32-core server. Consuming 6 x as much. With normal configuration they both perform almost as well in performance/watt. In idle the Threadripper sonsumed 100W, what is a lot for doing nothing. The 32-core ARM server only consumed a bit more than 100W maxed out. And about 20W in idle. The BMW Blender benchmark, which takes 29m23s on the fastest ARM SBC the Odroid N2+. The Ampere ARM server did it in 8m27s. For the Threadripper this was a way too light load, it did it in 30s. Even when doing this render 10 x after each other it didn't raise the temperatures much. The maximum I've seen was 50C. To try a heavier load I downloaded the Barber Shop Blender render. This was 6912 tiles to render. But again the Threadripper wasn't impressed by this load. 2m18s79. The AWS with 32-cores (of 64) done this in 8m28s. So this ARM server does compete well per clock for a floating point task with TR. ARM may be great, but AMD is mighty. Intel does not have anything to compete with this. Certainly not performance/watt. It was a pleasure benchmarking this server. I learned a lot, like that I need to find better tools for these amazing machines. The specs of this monster : ASRock Rack TRX40D8-2N2T AMD Ryzen Threadripper 3990x 256GB memory (8 x 32Gb) ECC 2 x 1TB PCI 4.0 Nvme SSD Water Cooling The specs of the Threadripper 3990x 64-cores 128-threads AMD64 Zen2 Matisse 2.9Ghz - 4.3Ghz 4-channel DDR4-3200 MHz 256GB RAM 88 lanes PCIe4 TSMC's 7nm process node 280W - +400W 32 KB L1 per core (64x) 64 x 512 KB L2 256 MB L3 cache shared You can see my full review video here, greetings. NicoD
  3. Hi all. I recently bought the Odroid Go Super. It is a great handheld for emulation gaming. But that isn't the main reason why I bought it. It can also run Linux, tho not Armbian. In this video I show how I use Debian Buster from Meveric on the Odroid Go Super and I also review the hardware. Greetings.
  4. Hi all. I've finished my review video about the NVIDIA Jetson Nano. I kept it simple, more videos to come on gameplay and neural network self learning. Here's the review video. I like it a lot. Does Blender great, and works well as light desktop. Loving the graphics drivers and hoping soon the other SBC's can have simular good drivers. It is close to being my favorite. If only the cpu had more power... Here my gathered data.
  5. This little and inexpensive ($35) board is fully compatible to discontinued NanoPi M3. From a software point of view both boards are identical (though Wi-Fi is missing on the Fire3) and as such identical OS images can be used for both boards. The good news: compared to the last time I looked at the M3 kernel support has improved a lot. Back then we had to run a smelly 3.4.39 (32-bit only) while we can now run mainline on it. I gave it a try using our Armbian Stretch nightly running with 4.14.40 (full armbianmonitor -u output) and did a couple of tests. The Samsung/Nexell S5P6818 SoC consists of 8 A53 cores running at up to 1.4GHz with default settings (can be slightly overclocked up to 1.6 GHz according to Willy Tarreau -- see the reviews at the product page). All cores behave like one big cluster (so adjusting /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq affects all 8 CPU cores at once, this is no artificial pseudo big.LITTLE as Amlogic does it with their S912). Now with a recent 64-bit kernel with the CPU cores brought up in ARMv8 mode we can also make use of ARMv8 Crypto Extensions making the S5P6818 to one of the most powerful boards when it's about AES crypto and stuff can run on all 8 cores in parallel (33 times faster than a RPi 3 and still 28 times faster than a RPi 3+). While the octa-core config sounds interesting for CPU intensive workloads one should keep in mind that this board has only 1 GB DRAM which is simply not enough for many such workloads (or you would need to make massive use of zram instead which performs better than swap on slow storage but of course bottlenecks a lot). Talking about a somewhat powerful CPU we also have to talk about temperatures and consumption. The board is always part of a kit so FriendlyELEC sells it together with a heatsink and a high quality Micro USB cable that solves a lot of the Micro USB related powering problems. In idle I measured 2.6W with Armbian (PSU included at the wall) while Willy Tarreau reported 'It consumes 400mA/5V in idle, and 1.2A/5V under openssl RSA with 8 cores at 1.6 GHz' (most probably using FriendlyELEC's OS image). So I tested for consumption with worst case workloads and used cpuburn-a53 for this. Since I knew from last time when I tested that the board deadlocks when starting cpuburn-a53 at 1.4 GHz I increased max cpufreq in steps (consumption always with PSU included): 1000 MHz: 9.3W 1100 MHz: 10.7W 1200 MHz: 12.2W 1300 MHz: 13.8W 1400 MHz: 14.7W After a short time with cpuburn-a53 running at 1.4 GHz the board deadlocked again which is not a surprise since my PSU is rated for 2A (10W) and Micro USB itself is only rated for 1.8A (9W). As usual with FriendlyELEC boards there's a 4 pin header for serial debug console that can also be used to power the board more reliably so even demanding tasks that increase consumption to 15W are possible when powering through the header. Talking about temperatures: After applying the heatsink I did a simple compile test (Arm Compute Library) with -j8 and after a minute the board did an emergency shutdown since CPU temperature reached 100°C. So all following tests were done with a huge fan blowing air over the heatsink laterally. IMO for demanding tasks improved airflow / heat dissipation is a must and the small heatsink simply not sufficient. What other hardware is there? The usual 40 pin GPIO header, Gigabit Ethernet (with Armbian's settings and mainline kernel we're talking about iperf3 numbers of ~925 Mbits/sec in both directions), a mini HDMI port (most probably supported by Armbian), a camera and a LCD port (both not supported by Armbian as far as I know), the Micro USB OTG port and a single USB2 type A port. USB Attached SCSI (UAS) is yet not available with mainline kernel so storage performance is a little lower as it could be. This is a Samsung EVO840 in an ASM1153 enclosure connected to the USB2 port: random random kB reclen write rewrite read reread read write 102400 4 7544 9889 10098 10117 7996 9770 102400 16 16143 20165 20365 20260 19858 20172 102400 512 33138 33659 33120 33373 33417 33321 102400 1024 33511 33663 33429 34020 34119 33521 102400 16384 32731 34012 36483 36750 36674 34291 I also did a quick test as NAS and got numbers as expected: everything a little bit slower compared to those USB2 platforms that can make use of UAS -- so if NAS is the use case some of the cheaper Allwinner boards with Gigabit Ethernet are a better idea. As usual FriendlyELEC did a great job documenting the board: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Fire3 -- they also provide OS images that make full use of all hardware features (camera, LCD displays auto-detected by u-boot, GPU/VPU acceleration, HDMI resolution switching in Linux sounds a bit like PITA though). Still not sure for which use cases this board applies. The octa-core CPU would better be accompanied by more DRAM (though then you need to get the NanoPC-T3 Plus -- same SoC but 2 GB DRAM) and I fear making use of the processor power almost always requires a fan blowing in addition to the heatsink (without a fan I measured in idle always +60°C after a few minutes)
  6. https://zuckerbude.org/the-pinebook-pro/
  7. Hi all. I've just finished a new video where I review an Amazon AWS Graviton2 arm64 server. This is a monster with 64 high-performance N1 cores. It isn't clocked that high at 2.5Ghz, but it performs amazing for that clockspeed. Here is my video. Here all the info I've gathered. AWS Server 32-cores 128GB ------------------------- NEOVERSE N1 64-core AWS Graviton2 ARMv8.2 aarch64 Arm’s Neoverse N1 cores -> based on A76 -> almost identical to Arm’s 64-core reference N1 platform -> CPU cores are clocked a bit lower 2.5GHz and only 32MB instead of 64MB of L3 cache Max speed 2500Mhz 8-channel DDR-3200 128GB ram 64 PCIe4 lanes TSMC’s 7nm process node ~1W per core at the 2.5GHz frequency between 80W as a low estimate to around 110W estimation. This info is not disclosed by AWS 7z single core Ampere 32-core : 2763 AWS 32-core : 3393 Threadripper 3990x : 4545 7z quad core : Raspberry Pi 4 @ 1.5Ghz : 6307 Odroid N2+ 4xA73@2.4Ghz : 9900 Ampere 32-core : 11145 AWS 32-core : 13733 Threadripper 3990x : 18060 7z all cores : Ampere 32-core : 85975 AWS 32-core : 110628 Threadripper 3990x : 391809 433702 OC Blender BMW CPU Odroid N2+ : 30m Ampere 32-core : 8m27s AWS Server 32-core : 2m08s ThreadRipper 3990x : 30s Blender Barber shop CPU AWS Server 32-core : 8m28s Threadripper 3990x : 2m18s79 CPU Miner Odroid N2+ : 14 Ampere 32-core : 87 AWS Server 32-core : 154.20 ThreadRipper 3990x : 1310 SBC bench : http://ix.io/2FrG Internet speed test between 1500 Mbit/s and 2000 Mbit/s both up- and download (up to 250MB/s) I had 32-cores of the 64-cores. It is expected to perform a bit worse per core with 64-cores vs 32-cores since less cache available per core. There's a newer Ampere 80-core N1 at 3Ghz SoC. https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/6 Thank you to @lanefu for giving me access to this.
  8. Hi all. Here my newest video about old boards that still do their job well. OrangePi+ and OPi+2. My favorite NAS. Here all my gathered data. Greetings, NicoD
  9. Today I had the pleasure of benchmarking an ARM64 server. This server has been made available for Armbian to test native ARM64 image building. I knew nothing about the server. Nobody told me any details. So everything was an adventure for me to find out. I got SSH access, so my research began. A lscpu informed me it had 32-cores all clocked at 3.3Ghz. cat /proc/cpuinfo confirmed these 32-cores Checking on what kernel we're on. Ubuntu Focal 5.4.0-52-generic. And how much memory. 128GB RAM. So first thing I wanted to know, how does one core perform with 7-zip benchmark? The record I had seen until now was from the A73 cores from the Odroid N2+ clocked at 2.4Ghz. 2504MIPS decompression. So : taskset -c 31 7z b This beats the Odroid N2+ its A73 cores clocked at 2.4Ghz. 2763 vs 2504MIPS decompression. This also tells me these cores do not perform as good per clock as a high performance core. While doing the single core benchmark I checked the sensors to know the wattage and temperature. CPU power is about 20W for a single core tasks. Without a load the CPU consumes between 10W-15W. So in total it consumes a bit more than 20W in idle. Temperature never went under 49C even after +5 minutes in idle. Of course, the next thing to do is an all-core 7zip benchmark. This gives an amazing result. Way higher than anything I had ever seen on ARM. 85975MIPS decompression. This is amazing. Best I had seen was 11000MIPS of the Odroid N2+. So this server does 8 x better than the N2+. Tho, I must say. 7zip does bad with unequal clusers. The N2+ has a great difference in cluster frequencies. So it performs worse then expected here. The wattage went a lot higher, up to 110W. And the temperature rose quickly up to 75C in seconds. To test the internet connection I downloaded an Armbian image multiple times. Sometimes it was as low as 3MB/s. Highest average speed I've seen was 12.5MB/s Next test. BMW Blender render benchmark. Here the fastest I had ever seen was by the Khadas VIM3. That did it in 42m51s. I haven't done this yet with the N2+ in Armbian. In Odroid's Ubuntu it was a little slower. I expect it to be a little faster than the VIM3 in Armbian Bionic. This is a tile based test. So every core gets its own task, until all tiles are done. Well, this ARM64 server did this in 8m27s. 5 x faster compared to the Khadas VIM3. For this the wattage didn't go over 85W. But the temperature did rise to 83C. So it started to throttle. @lanefu already had done SBC-Bench on it when it was free. So this I didn't have to do myself. http://ix.io/2Dcc Here we see a lot. For example the CPUMiner did : 81.0kH/s The Odroid N2+ : 14 kH/s 5.7 x less RK3399 does a maximum of : 10.23kH/s 8 x less Odroid C2 clocked at 1.75Ghz : 4.65kH/s 17 x less So this server clearly can move a lot of bits around. Now, what is this server? Ask google if nobody else tells me. "32 core ARM server 3.3Ghz" First answer : https://www.theregister.com/2018/09/18/ampere_shipping/ That looks like it is this CPU. But still I can't find the exact name. 2nd answer : https://www.servethehome.com/ampere-32-core-64-bit-arm-chip-x-gene-3-ip/ So this is the Ampere 32-core 64-bit from X-Gene 3 IP. Here the wikichip : https://en.wikichip.org/wiki/apm/x-gene/apm883832-x3?fbclid=IwAR0ljCQ61DY8Zwh_VyZd0fQH43dmPUTJA-CGLiQKYqU2fWwszFm1CPjH6Zo This supports up to 1TB RAM. 8 channels @ 2666Mhz. With a maximum memory bandwidth of 158.95 GiB/s. 42 lanes of PCIe Gen 3, with 8 controllers – x16 or two x8/x4 – x16 or two x8/x4 – x8 or two x4 – Two x1 4 x SATA Gen 3 ports, 2 x USB2. And a TDP of 125W TDP. For me this is just an awesome thing to behold. I use ARM for almost everything. The NanoPi M4V2 is my main desktop computer. It isn't as powerful as my PC, but does the task for 10 x less power consumption, while being completely silent. But when I need a big CPU, it isn't enough. Even the more powerful Odroid N2+ isn't powerful enough to render long, +20minutes 1440p video's for example for my Youtube channel. So then i need to use my x86/amd64 PC. Today I have seen and tasted the future. While this doesn't use the most modern Cortex/clusters. And it is only 16nm. So there is still a lot of room for improvements in performance and lower power consumption. ARM for desktop is possible, and ARM servers for big datacenters is possible(AWS). I have seen the future, I loved every second of it. Here benchmarks compared to my SBCs Greetings, NicoD
  10. Hi all. I've just finished a long video special where I talk about all my SBCs. In the order how I got them. I show the specs of all of them. Say what I like, what's bad about them. What I use them for. What SBC is best for your goal. Here's my video, I hope you enjoy it. Greetings, NicoD. P.S. : Pictures of anyone else their collection? Mine are not all on this pic, no room for them all.
  11. Overview (Disclaimer: The following is for techies only that like to dig a bit deeper. And if you're not interested in energy-efficient servers then probably this is just a waste of time ) EDIT: Half a year after this poorly designed SBC has been released just one of the many design flaws has been fixed: Micro USB for DC-IN has been replaced by the barrel jack that was present on the pre-production batches. If you were unfortunate to get a Micro USB equipped M3 please have a look here how to fix this. Apart from that check the Banana forums what to expect regarding software/support first since this is your only source) SinoVoip sent me a review sample of the recently shipped so called "Banana Pi M3" yesterday. It's a SBC sharing name and form factor of older "Banana Pi" models but is of course completely incompatible to them due to a different SoC, an A83T (octa-core Cortex-A7 combined with a PowerVR SGX544 GPU). For detailed and up-to-date informations please always refer to the linux-sunxi wiki. This new model distinguishes itself from the Banana Pi M2 with twice as much CPU cores and DRAM (LPDDR3), 8 GB eMMC onboard and BT4.0. And compared to the "M1" (the original Banana Pi) it features also 802.11 b/g/n Wi-Fi. Unlike the M2 the M3 is advertised as being SATA capable. But that's not true, it's just an onboard GL830 USB-to-SATA bridge responsible for horribly slow disk access. Unfortunately the GL830 and both externally available USB ports are behind an internal USB hub therefore all ports have to share bandwidth this way and use just one single USB connection to the SoC. Since my use cases for ARM boards are rather limited you won't find a single word about GPIO stuff (should work if pin mappings are defined correctly), GPU performance, BT, Wi-Fi or Android. Simply because I don't care Getting Started: The board arrived without additional peripherals (no PSU) therefore you need an USB cable using a Micro-USB connector to power the board. Both DC-IN and USB-OTG feature an Micro-USB connector which is bad news since pre-production samples had a real DC-In connector (4.0mm/1.7mm barrel plug, centre positive like the M2). I suffered from several sudden shutdowns under slight load until I realized that I used a crappy cable. Many (most?) USB cables lead to voltage drops and when the board demands more power it gets in an undervoltage situation and the PMU shuts off. Same will happen to you unless you can verify that you've a good cable. I did not succeed querying the M3's powermanagement unit (PMU) regarding available voltage (/sys/devices/platform/axp81x_board/axp81x-supplyer.47/power_supply/ac/voltage_now shows always 0). This was a lot easier with the older Banana Pi M1: Here you can watch my cable being responsible for voltage drops under high load (I accidentally used this again with the M3). To avoid the crappy Micro-USB connector (limited to 1.8A maximum by specs and tiny contacts) you can desolder it and solder a cable or a barrel plug -- the PCB is already prepared for the latter. Or ask SinoVoip if they can fix this mistake with the next batch of PCBs. On the bottom side of the PCB there are also solder pads for a Li-Ion battery. It has to be confirmed whether the AXP813 PMU can also be fed with 5V through the Li-Ion connector since this is the preferred way to fix the faulty power design other SinoVoip products show. One final word regarding power: It seems currently something's wrong with power initialisation in the early boot stages (u-boot). With a connected bus-powered USB disk the board won't start or immediately shut down when the disk is connected within the first 10 seconds. I didn't verify when exactly because if you've a look at SinoVoip's commit log it seems they began to fix many obvious bugs just right now after they already started shipping the board (we've seen that with the M2 also). First Showstoppers: Since the board came with an unpopulated eMMC (why the heck?) I had to try out the available OS images from the banana-pi.org download site. Unlike everyone else on this planet they don't provide MD5/SHA1 checksums to be able to check integrity of downloads and even if you tell them that they've uploaded corrupted images they don't care. From 4 OS images 3 are corrupted (according to unzip) and all failed soon after boot with kernel panics. I tried the Android image to verify FEL mode works. But since Android is of zero use for me, I decided to build an own OS image from an Ubuntu distro running on the Orange Pi where I had the SD-card inserted. Since details are boring just as a reference. From then on I used this Ubuntu image and exchanged only the freshly built stuff from SinoVoip's BSP Github repo (3.4.39 kernel, modules, bootloader and also simple things like hardware initialisation since kernel/u-boot they prefer does NOT support script.bin) First Impressions: Heat (dissipation): The A83T needs a heatsink otherwise you won't be able to benefit from its performance. Allwinner's 3.4.39 kernel provides 'budget cooling' using 2 techniques: thermal throttling and shutting down CPU cores. You can define this 'thermal configuration' in sysconfig.fex and have to take care that you understand what you're doing since if throttling doesn't help your CPU cores will be deactivated and you have to can't bring them back online manually the usual way since Allwinner's kernel doesn't allow so: echo 1 >/sys/devices/system/cpu/cpuX/online Therefore it's better to stay with the thermal defaults to allow throttling and improve heat dissipation instead. I used a $0.5 heatsink that performs ok. Without heatsink when running CPU intensive jobs throttling limited clockspeed to 1.2 GHz but with the heatsink I was able to run most of the times at ~1.6Ghz under full load. With heatsink and an annoying fan I managed to let the SoC run constantly at 1.8GHz and achieved a 7-zip score close to 6000 and finished "sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8" in less than 53 seconds. This is an example for wrong throttling values (too high) so that the kernel driver does not limit clockspeeds but starts to drop CPU cores instead: CPU performance: Since the H3 (used on the more recent Orange Pis) and the A83T seem to use much of the same kernel sources (especially the 'thermal stuff') I did a few short tests. When running with identical clockspeed and the same amount of cores they perform identical (that means they're slower than older Cortex-A7 SoCs like eg. the A20 when running at identical clockspeed -- a bit strange). Obviously the difference between H3 and A83T is the process. Both already made in 28nm but the A83T as 'tablet SoC' in the more energy efficient HPC process allowing less voltage and higher clockspeeds. According to sysconfig.fex the SoC should be able to clock above 2.1 GHz but since exceeding 1.6 Ghz already needs a fan this is pretty useless on a SBC (might be different inside a tablet where the back cover could be used as a large heatsink). Network throughput: I used my usual set of iperf testings and tried GBit Ethernet performance (with and without network tunables it remains the same -- reason below): BPi-M3 --> Client: [ 4] 0.0-10.0 sec 671 MBytes 563 Mbits/sec [ 4] 0.0-10.0 sec 673 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 870 MBytes 729 Mbits/sec [ 4] 0.0-10.0 sec 672 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 675 MBytes 566 Mbits/sec Client --> BPi-M3: [ 4] 0.0-10.0 sec 714 MBytes 599 Mbits/sec [ 5] 0.0-10.0 sec 876 MBytes 734 Mbits/sec [ 4] 0.0-10.0 sec 598 MBytes 501 Mbits/sec [ 5] 0.0-10.0 sec 690 MBytes 578 Mbits/sec [ 4] 0.0-10.0 sec 604 MBytes 506 Mbits/sec When I used longer test periods (-t 120) then the "Client --> BPi-M3" performance increased up to the theoretical limit: 940 Mbits/s. Then a second iperf thread jumped in, both utilising a single CPU core fully. And that's the problem: Networking is CPU bound, a single client-server connection will not exceed 500-600 Mbits/sec as it was the case when I started with A20 based boards 2 years ago. Since all we have now with the A83T is an outdated 3.4.39 kernel and since I/O bandwidth on the M3 is so low, I stopped here since it's way too boring to try to improve network throughput and also useless (disk access is so slow that it simply doesn't matter when Ethernet is limited to half of the theoretical GBit Ethernet speed... at least for me ) Accessing disks: Since there's a SATA connector on the board I gave it a try. Important: the SATA-power connector uses the same polarity as older Banana Pis and Orange Pis (keep that in mind since combined SATA data/power cables from LinkSprite and Cubietech that share exactly the same connector use inverted polarity!). I started with the Samsung EVO I always use for tests (but due to the old 3.4 kernel using ext4 instead of btrfs) and was shocked: 13.5/23 MB/s is the worst result I ever measured. I then realised that I limited maximum cpufreq to 480 MHz and tried with 1800 MHz again. A bit better but far away from acceptable: GL830 USB-to-SATA performance: 480 MHz: kB reclen write rewrite read reread 4096000 4 13529 13466 22393 22516 4096000 1024 13588 13411 22717 26115 1.8 GHz: 4096000 4 15090 15082 30968 30316 4096000 1024 15174 15131 30858 29441 I disconnected the SSD from the 'SATA port' and put it in an enclosure with a JMicron JMS567 USB-to-SATA bridge and measured again: Now sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s. The GL830 is responsible for low throughput -- especially writes are slow as hell. I made then a RAID-1 through mdadm consisting of an external 3TB HDD (good news: the GL830 can deal with partitions larger than 2 TB) and the SSD. First test with the HDD connected to the M3's GL830 bridge (GL) and the SSD connected to the JMS567 (JM). Then I disconnected the HDD from the GL830 and put it in another external enclosure with an ASMedia 1053 (ASM). Obviously SinoVoip's decision to use an internal USB hub and only one host port of the SoC leads in both situations to limited (shared) bandwidth. But in case the internal USB-to-SATA bridge is involved performance is even worse: GL/JM: kB reclen write rewrite read reread 4096000 4 17800 17140 14382 16807 4096000 1024 17741 17258 14493 14368 JM/ASM: 4096000 4 19307 18458 22855 26241 4096000 1024 19231 18518 21995 22362 If SinoVoip would've saved the GL830 USB-to-SATA bridge and wired both SoC's host ports to the 2 type-A USB ports directly without the internal hub in between overall performance would be twice as good. And obviously the M3's 'SATA port' is the worst choice to connect a disk to. Any dirt-cheap external USB enclosure will perform better. SD-card and eMMC: Just a quick check with the usual iozone settings running @ 1.8 GHz: kB reclen write rewrite read reread eMMC: 4096000 4 26572 27014 59187 59239 4096000 1024 25875 26614 56587 56667 SD-card: 4096000 4 20483 20855 22473 22892 4096000 1024 20526 19948 22285 22660 LOL, eMMC twice as fast as 'SATA'. The performance numbers of the SD-card (SanDisk "Extreme Pro") are irrelevant since I can not provide performance numbers from a known fast reference implementation. But since I might be able to provide this the next few days, I decided to give it a try. On older Allwinner SoCs there's a hard limitation regarding SDIO/SD-card speed. Maybe this applies here too. EDIT: Yes, it's a board/SoC limitation. When reading/writing the SD-card on a MacBook Pro I achieve ~80 MB/s. It seems SDIO on A83T is limited to ~20MB/s Other issues: If you want to try out the M3 you'll have to stay on the bleeding edge. Don't expect that any of the available OS images are close to useable. They just recently started to fix a lot of essential bugs in code and hardware initialisation. If you want to test the M3 be prepared to compile the BSP daily and exchange the bootloader/kernel/initialisation stuff on your SD-card/eMMC Currently average load is always 1 or above. When we started over 2 years ago with Cubieboards (and an outdated kernel 3.4.x) there was a similar issue. Maybe it's related. I just opened a Github issue Mainline kernel support in very early stage. Don't count on this that soon (situation with Banana Pi M2 was a bit different. All the OS images from SinoVoip based on kernel 3.3 weren't useable but the community provided working distros backed by the work of the linux-sunxi community and existing mainline kernel support for the M2's A31s) Always keep in mind that hardware without appropriate software is somewhat useless. SinoVoip has a long history of providing essential parts of software way too late or not at all (still applies to the M2 -- before you buy any SinoVoip product better have a look into their forums to get the idea which level of support you can expect: zero). Even worse: For the M2 and its A31s SoC there exists mainline kernel support (everything developed by the community while the vendor held back necessary informations). This does not apply to the A83T used on the M3. At the moment you're somewhat lost since you've to rely on the manufacturer's OS images (all of them currently being broken) Conclusion: Still no idea what to do with such a device. Integer performance is great when you use a heatsink and even greater with an annoying fan. But where's the use case? If I would use the M3 with Android then everything that's relevant for performance does not depend on CPU (but instead CedarX for HW accelerated video decoding and GPU for 2D/3D acceleration -- BTW: the A83T is said to contain only a single core SGX544MP1 but the fex file's contents let me believe it's a faster MP2 instead). Due to limited I/O and network bandwidth the integer performance is also irrelevant for nearly all kinds of server tasks. If it's just about 'SBC stuff' why wasting so much money? Triggering GPIO pins works also with cheap H3 based boards like Orange Pi PC or Orange Pi One that also have 4 times more I/O bandwidth compared to the M3 (due to 4 available USB ports instead of one). And if I would really need a performant ARM SoC then I would buy such a thing and not an outdated Cortex-A7 design. I still have no idea what the M3 is made for. Except of selling something under the "Banana" brand to clueless people. Don't know. For my use cases the Banana Pi M1 outperforms the M3 easily -- both regarding price and performance (sufficient CPU power, 3 x USB and real SATA not 'worst USB-to-SATA implementation ever'). As usual: YMMV Maybe the worst design decision (next to choosing the crappy Micro-USB connector for DC-IN) on the M3 is the 'SATA port'. If they would've saved both internal USB hub and GL830 and instead use the two available USB host ports then achievable I/O bandwidth would be way higher. Now both USB ports and the 'SATA port' have to share the bandwidth of a single USB 2.0 connection. Almost as bad as with the Raspberry Pis. But most importantly: Check software und support situation first and don't rely on 'hardware features'. Remember: SinoVoip shipped the M2 with OS images where not a single GPIO pin was defined and Ethernet worked only with 100Mb/s since they 'forgot' to define GMAC pins. They fixed that months later but still not for every OS image (the Android image they provide is corrupted since months but they don't care even if users complain several times). Visit their forums first to get an idea what to expect. It's important! Armbian support: Not to be expected soon. It's worthless when having to rely on Allwinner's old 3.4.39 kernel. I combined loboris' H3 Debian image with kernel/bootloader stuff for the A83T and it worked as expected (even my RPi-Monitor setup matched almost perfectly). Unless the linux-sunxi community improves mainline support for the A83T this situation won't change. But maybe someone interested in M3 (definitely not me) teaches SinoVoip how to escape from u-boot/kernel without support for script.bin in the meantime. Would be a first step.
  12. Hi all. I just finished my review video about the Tanix TX6. Here it is. Greetings, NicoD
  13. 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.
  14. - H6 - 1GB - gigabit - 26pin - powering only via DC input - PMU AXP805 - 1 x USB2.0 host and 1 x micro USB 2.0 - size: 69x47mm - weight: 50g - price USD20-25
  15. Hi all. I've finished my review video of the NanoPi M4V2. Here is it. Special thanks to @JMCC @balbes150 @pask and @martinayotte. Cheers all.
  16. Hi all. I've made a new video where I compare the above boards. I show specs, performance and transfer speeds of everything. Here's the video. Here my gathered data. Benchmarks ---------- Khadas VIM3 | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench | glmark2 Ubuntu Bionic 1.80Ghz 2.21Ghz 13m22s 1582 2322 192FPS 12.90 http://ix.io/1P6F Ubuntu XFCE 1.80Ghz 2.21Ghz 12m43s 1586 2316 355FPS 12.90 http://ix.io/1PhE Armbian Bionic 1.80Ghz 2.11Ghz 11m48s 1610 2244 495FPS Armbian Bionic 1.80Ghz 2.21Ghz 11m28s 1613 2348 510FPS 12.85 http://ix.io/1PD2 Armbian Disco 1.80Ghz 2.21Ghz 11m11s http://ix.io/1PDR Armbian Buster 1.80Ghz 2.21Ghz 11m21s 1644 2374 590FPS 12.80 http://ix.io/1PEm RockPi 4B | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Debian Stretch64 1.51Ghz 2.02Ghz 21m44s 1340 1988 90FPS 8.79 http://ix.io/1Rrl Debian Stretch64 1.42Ghz 1.80Ghz 23m34s 1260 1789 90FPS 8.07 http://ix.io/1RrE 50 Armbian Disco 1.42Ghz 1.80Ghz 21m38s 1246 1811 254FPS 9.90 Armbian Bionic 1.42Ghz 1.80Ghz 22m19s 1247 1809 255FPS 9.55 http://ix.io/1Rz3 Armbian Bionic5.4.0RC4 75 NanoPi M4 | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Armbian Bionic 1.42Ghz 1.80Ghz 22m18s 1249 1813 250FPS 9.50 http://ix.io/1ORz Armbian Stretch 1.42Ghz 1.80Ghz 23m48s 1269 1789 7.97 http://ix.io/1ORY Armbian Buster 1.42Ghz 1.80Ghz 21m23s 1277 1816 290FPS 10.07 http://ix.io/1P6X Armbian Disco 1.42Ghz 1.80Ghz 20m34s 1252 1823 260FPS 9.95 http://ix.io/1PbD Odroid N2 | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Armbian Bionic 1.9Ghz 1.8Ghz 14m29s 1629 1891 Atomic Pi | Clock S/C | B/C | Blender | 7z S/C | 7Z B/C | glxgears | CPUMiner | SBCBench Ubuntu Disco 1.67Ghz 27m58s 1441 60FPS Storage ------- NanoPi M4 | Read | Write 32GB eMMC 180MB/s Samsung EVO SD-cardreader 68.1MB/s 20.6MB/s USB3-Sata 395.5MB/s 411.5MB/s Odroid N2 | Read | Write 32GB eMMV 151.4MB/s Samsung EVO SD-cardreader 61.9MB/s 14.2MB/s USB3-SATA 228.5MB/s 239.6MB/s Khadas VIM3 | Read | Write eMMC 16GB 165.9MB/s 60 MB/s SSD over USB3 286.1 MB/s 380.3 MB/s write SSD over USB2 : 40.2 MB/s Samsung EVO plus with on-board sd-reader : 10.2MB/s write 22.1MB/s read with USB3 sd-reader : 31.7MB/s write 88.6MB/s read RockPi4B | Read | Write On-board sd 23.9 MB/s 14.3 MB/s ssd over USB3 402.7 MB/s 406.2 MB/s write NVMe 730 MB/s 745.0 MB/s write 1GB 10GB 432MB/s
  17. Hi all. I've just finished reviewing the Khadas VIM3. It's an amazing SBC with unmatched performance. It's got the Amlogic A311D SoC. Comparable with the S922X of the Odroid N2. But the 4x A73 cores are clocked at 2.2Ghz and the 2 x A53 cores to 1.8Ghz. So it performs a lot better. It also comes with an NPU, MIPI-DSI and MIPI-CSI. And can be powered with USB type-c from 5V up to 20V. Here my review video. Here all my gathered information. Khadas VIM3 ----------- Ubuntu server - fan over fins ----------------------------- Blender BMW no fan thermal pad : 59m with copper shim : 58m18s with 5V fan : 45m01s with 5V fan over CPU : 43m28s Ubuntu XFCE - fan over CPU, not over fins ----------------------------------------- Blender no fan : 55m22s Blender 3V fan : 43m03s Blender 5V fan : 42m51s Blender with fan : 48m45s Armbian Bionic Small cores @1.9Ghz Big cores @1.7Ghz Blender with fan : 46m29s Armbian Disco Small cores @1.9Ghz Big cores @1.7Ghz Blender with fan : 46m56s Armbian Buster Small cores @1.9Ghz Big cores @1.7Ghz Kdenlive 16m bench 3V lxde : 1h09m (using 1GB zram + 4GB swap file. Not enough ram with 2GB) Video playback -------------- Ubuntu ------ Up to 4K 30fps with MPV. Very slight screen tearing. Anything lower is perfect Youtube playback with Firefox up to 1440p 30fps perfect KODI doesn't work (yet) No VPU acceleration for now. All done by CPU. LibreElec --------- Up to 4K 30fps with MPV. Very slight screen tearing. Anything lower is perfect Wifi doesn't work. power consumption ----------------- Idle no fan : 0.27A 5V (governor set to interactive) Maxed out with fan : 1.4A 5V (fan is 0.15A) Temperatures (fan over CPU, not over fins) ------------------------------------------ Idle No fan : 44°C Maxed out No fan : 75°C heavy throttling. 1Ghz small cores / 1.8Ghz big cores Idle 3V fan : 34°C Maxed out 3V fan : 73°C very light throttle. Takes 5min to reach 70°c. +10min to start throttling Idle 5V fan : 32°C Maxed 5V : 70°C no throttling Transfer speeds --------------- eMMC 16GB : 60 MB/s write : 165.9 MB/s read SSD over USB3 : 380.3 MB/s write : 286.1 MB/s read SSD over USB2 : 40.2 MB/s Samsung EVO plus with on-board sd-reader : 10.2MB/s write 22.1MB/s read with USB3 sd-reader : 31.7MB/s write 88.6MB/s read Ethernet internet speed : 53.9 Mbps 11.5 Mbps Wifi internet speed : 43.7 Mbps 11.2 Mbps Issue's ------- When using a 2.4Ghz dongle for mouse in the right USB3 port, wifi connection is slow. When using a USB3 device in the USB3 port wifi stops working. Use left USB2 port for those. Ubuntu server boots/shuts down slower than XFCE version. Shut down stop job for ifup for eth0 (not in use) 1m30s Boot hangs a while. Can't find the reason. After -> Scanning for Btrfs filesystems. Done. about 30s Can't install Tensorflow khadas@Khadas:~/tensorflow$ pip3 install tensorflow-1.8.0-cp35-none-linux_aarch64.whl tensorflow-1.8.0-cp35-none-linux_aarch64.whl is not a supported wheel on this platform. Android : Can't connect wifi. I can type wifi password, but can't go further. No connect button. Tips ---- Use interactive governor for better thermals and power consumption with low use/idle. Plus/Minus ---------- + Best single core performance + best multi-core performance for an ARM SBC + Nice case + PSU + USB-c cable included + remote + eMMC + Amazing low power consumption / best performance per watt + Can be powered with 5V up to 20V + NPU - Wifi issue with USB3/No 5Ghz wifi. Could have solved the USB3 interference - Placing of the buttons would be better on the back. They often get pressed when plugging a USB device. You do get used to it. - No VPU and X11 drivers (yet) - Slow On-board SD-card reader Greetings, NicoD
  18. Hi all. I've made a new review video about the Odroid N2. It an amzaing beast of an SBC. But it ain't perfect for everyone. Geetings, NicoD. https://www.youtube.com/watch?v=dylc0GjeyM8 @balbes150 Tanks for the great image.
  19. Hi all. Here my review video of the new Pine H64 model B. I also compare it with the Orange Pi 3, and it's older brother the Rock64. I hope you'll like it. Thank you. Greetings, NicoD
  20. Hi all. I've made a new review video about the Orange Pi 3 with Linux. I've used Armbian Stretch for this video. Here is my video. Here you can find all the data I've gathered. Greetings, NicoD
  21. Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case. This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC. Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together. This allows some freedom on the location of the SoC relative to the lid. First off, same nice packaging the Tinker owners are familiar with: The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production The reason for the weight becomes immediately obvious when pulling the two halves apart: All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless. The extrusion is very thick, over 8mm in places. Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately. Something important to notice in this picture: The Tinker sits on aluminum studs, and does not bolt down. The heat sink block holds it in place. I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter: https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/ I can't verify (no hardware), but the holes are 85mm apart and threaded. Board fits nicely: Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem. This would be my only feedback where I think a different option would have been better: The thumbscrew is located at a position so as to be on center with the SoC. This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around. Not a problem for 90% of people, to be honest. In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled. Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet. My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins. Aesthetically it is a very nice looking product, of course I'd say that should be expected. I'll follow with something a bit more empirical later on.
  22. The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM). I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive) Low end 3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo): http://www.ebay.com/itm/141821170951 They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb: Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction). Power requirements when adding Ethernet using this dongle: Plugging in the dongle without network cable attached: +700mW Connecting network cable to USB dongle (GbE!): another +400mW GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection) I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks): Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination High end Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here). You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less) What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days) Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time. And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer. Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.
  23. 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)
  24. Latest RK3399 arrival in the lab. For now just some q&d photographs: @wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here! A quick preliminary specifications list: RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed