tkaiser

Sorry, 'recipes are just an inspiration'   I only follow them when it's about making dough. And then I totally lack English kitchen vocabulary (only fluent in German, Italian and a bit French in this area) and it won't get better than http://kaiser-edv.de/tmp/senigallia/Sabato.html anyway...

Just had a look when I did Knöpfle the last time: over 11 years ago. Delicious taste, bad 'look&feel'. Never did them again
 

 
 
 

Current proposal?
 
the FAT32 config partition is at the end of the disk image firstrun applies configuration changes config file is scrubbed via shred for security purposes fat32 part is destroyed rootfs expansion step proceeds as normal

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.

Absolutely support this. But IMO discussion should be moved out of this thread in an own thread over at https://forum.armbian.com/forum/12-armbian-build-framework/
 
@Igor can you please move last two posts to something like an 'Initial easy setup proposal' thread? I think a lot of users might benefit from a way to easily adjust the settings @botfap talked about prior to first boot.

Yesterday 2 sets of NanoPi M4 arrived (one 2GB and 4GB) which will make it convenient to test for stuff like heat dissipation in less time (I use one time the supplied thermal pad with the large heatsink, on the 2nd board I replaced the thermal pad with a 20x20mm copper shim of 1mm height I took away from my RockPro64).
 
But now talking just about USB-C: NanoPi M4 while using an USB-C connector to be powered is obviously not USB PD compliant but simply uses the USB-C connector to be combined with a 'dumb' PSU that provides the necessary amount of current without any negotiation. FriendlyELEC shipped a new 5V/4A PSU with USB-A receptacle combined with a very short USB-C cable. Since the PSU is not EU style and I miss the necessary adapter I currently use my standard 'dumb'  5V/2A USB PSU which works fine for the tests I currently do.
 
Not being compliant to USB PD specs (or USB-C powering specifications) means two things: Pro: no expensive USB-C charger needed (check the funny discussion in Khadas forum and there the link to tested USB-C chargers and their prices). A dumb 5V PSU that can deliver the needed amount of current at a stable voltage will be sufficient
 
Cons:
possible voltage drop N° 1: at 5V with higher currents the majority of cheap PSUs won't deliver. They can do either 5V or 4A but not both at the same time (this issue can be studied around ODROID boards that are also designed with 5V/4A in mind) possible voltage drop N° 2: the cable quality and length between board and PSU becomes an issue since here an additional voltage drop happens. The longer the cable and the thinner the wires the less the voltage available to the board (symptoms as above: especially USB disks or peripherals in general will be affected) possible undercurrent: I don't know yet but in case the NanoPi M4 really does no USB PD power signalling at all stuff like with Khadas Vim2 might happen Not possible to use 'real' or standards compliant USB-C PSUs since not providing enough current since the powered device is not able to negotiate higher current demand  
Edit: tested with my MacBook Pro USB-C charger not exceeding 500mA with 'dumb' consumers on the other end of the USB-C cable: endless boot/crash cycle. So be prepared to run into troubles combining NanoPi M4 with a real USB-C charger compliant to specs. This didn't work with the Vim2 and it also does not work with NanoPi M4. @hjc: seems you can consider yourself lucky that your USB-C charger is outputting more than 500/900 mA when feeding 'dumb' consumers.

Dear @Nora Lee,
 
since you're the BPi product manager I guess by not answering my question above but spamming other forums with irrelevant links you confirm that you're not able to provide bootloader and kernel sources for your W2 'closed source router', true? 

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

Advertised as Android 7 capable so it must be running with Allwinner's 4.4 kernel which is bad news since not supporting voltage regulation any more (same with Libre Computer Tritium boards): https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/issues/1 -- be prepared that maximum cpufreq is lower than any of the older H3 boards.
 
Device tree settings from this Allwinner BSP kernel (and most probably u-boot too) are incompatible with mainline stuff so good luck with extracting settings and transforming them into something suitable for Linux (applies also to DRAM timings). How fast is the 16 GB eMMC? Which wireless chip?
 
In the past with Allwinner H3 based TV boxes it was rather easy to get them supported in Armbian since it was reading out the proprietary fex stuff and then adjusting few bits. Could be done for the legacy Allwinner kernel even without having the device in front of you (see Sunvell R69) but the situation with boards based on the new BSP is entirely different.
 
And I don't know who is still interested in Allwinner H3 here (at least me definitely not  )

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.
 

Did some quick research after noticing your edit and wanting to verify my vector instruction suspicions. Neither lzo or lz4 use neon vector instructions on Arm7 or 8 which is very far from ideal and explains why the performance of lzo and lz4 is much better on Intel than on Arm
 
 

I did just that:
 

 
The thick thermal pad has been removed and replaced with a 15x15mm copper shim (0.8mm height). The grey stuff around the SoC are leftovers from another thermal pad (came with RockPro64) just to prevent shorting things with the heatsink.
 
I tried to use sbc-bench in thermal testing mode. NanoPi Fire is in upright position (so convection might help a little bit) in a room with 24°C ambient temperature.
sbc-bench.sh -T 80 ; sbc-bench.sh -t 60 Problem N° 1: with stock thermal pad I would have to wait endlessly for the SoC to cool down below 60°C (that what 'sbc-bench.sh -t 60' is supposed to do). The board once hot remained at 62°C to 63°C. I had to temporarely switch cpufreq governor to let the CPU cores clock down from 1400 to 400 MHz to get an idle temperature below 60°C again.
 
Then numbers were as follows:
1400 MHz: 146.17 sec 1300 MHz: 148.42 sec 1200 MHz: 0 sec 1100 MHz: 0 sec 1000 MHz: 0 sec 900 MHz: 0 sec 800 MHz: 0 sec 700 MHz: 0 sec 600 MHz: 0 sec 500 MHz: 0 sec 400 MHz: 5.80 sec (the 6 seconds on 400 MHz are not result of throttling but me manually switching back to performance cpufreq governor once the real benchmark run started). Full output where you can see how long it took to cool down from 80°C to 60°C: https://pastebin.com/raw/1DDt8yGk
 
Now with copper shim instead of thermal pad.
 
Problem N° 2: now it's impossible for the 'pre-heat' run to get above 80°C. I would have to wait endlessly for this so I stopped and ran 'sbc-bench.sh -T 78 ; sbc-bench.sh -t 60' instead to only wait until temperature exceeds 78°C. Full output: https://pastebin.com/raw/a0vmQJ0b
 
No throttling happened and temperature remained below 80°C. Again it's obvious that thermal pads simply suck when it's about efficient heat dissipation. But I've to admit that I've no idea whether the contact area now with my copper shim is sufficient or thermal pads are the recommended way since with my copper shim now only the very small die area and the copper shim have contact while the area around not.
 
@mindee can you please shed some light?
 
Edit: haha, today I realized that I ran with just 4 CPU cores active yesterday when I made my tests due to 'maxcpus=4' set in /boot/armbianEnv.txt (to test for swap efficiency of various approaches). Doesn't change anything wrt thermal conductivity but of course now with all 8 CPU cores active NanoPi Fire3 starts to throttle severely when running heavy stuff but at least with copper shim clockspeeds are much higher compared to thermal pad.

Honestly: if I have a RK3399 device and want 128 GB storage I choose something different. I ordered a cheap DRAM less NVMe SSD for 40€ (VAT/shipping included),  inserted it into the M.2 slot, transferred the rootfs as easy as always with nand-sata-install and now my NanoPC-T4 runs directly off the NVMe SSD.
 
I've no doubt that the eMMC performs nicely. But I doubt it's as fast as an NVMe SSD and what I like the most with SSDs: the good ones tell you when they start to wear out:
root@nanopct4:/home/tk# smartctl -x /dev/nvme0n1 smartctl 6.6 2016-05-31 r4324 [aarch64-linux-4.4.153-rk3399] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Number: TS128GMTE110S Serial Number: AC2153AAE531202E0165 Firmware Version: R0515A0 PCI Vendor/Subsystem ID: 0x126f IEEE OUI Identifier: 0x000000 Controller ID: 1 Number of Namespaces: 1 Namespace 1 Size/Capacity: 128,035,676,160 [128 GB] Namespace 1 Formatted LBA Size: 512 Local Time is: Mon Sep 10 18:38:24 2018 UTC Firmware Updates (0x14): 2 Slots, no Reset required Optional Admin Commands (0x0006): Format Frmw_DL Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat *Other* Maximum Data Transfer Size: 64 Pages Warning Comp. Temp. Threshold: 70 Celsius Critical Comp. Temp. Threshold: 80 Celsius Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 9.00W - - 0 0 0 0 0 0 Supported LBA Sizes (NSID 0x1) Id Fmt Data Metadt Rel_Perf 0 + 512 0 0 === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02, NSID 0x1) Critical Warning: 0x00 Temperature: 28 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 0% Data Units Read: 110,342 [56.4 GB] Data Units Written: 289,050 [147 GB] Host Read Commands: 11,897,227 Host Write Commands: 22,892,268 Controller Busy Time: 126 Power Cycles: 10 Power On Hours: 1 Unsafe Shutdowns: 4 Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0  
The 'Percentage Used' line is the important one. As long as this is below 90 everything's fine. An eMMC will die suddenly without any prior warning...

Just a thought. Over half of the boards we support feature a 26 or 40 RPi compatible GPIO header and all the other boards expose various protocols and GPIO on various pins and headers.
 
Users coming from Raspbian and trying out any of our boards expect that basics work the same. While it's both impossible and not desirable to be 100% compatible with Raspbian a few things would make transition from Raspbian to Armbian for IoT folks more easy.
 
Simple example: Default user pi in Raspbian has access to GPIO pins -- on Armbian it's currently root only. How's that done? A group called gpio exists in Raspbian, pi is added to it and /etc/udev/rules.d/99-com.rules does all the magic:
 
 
 
So adding a detection in automatic user creation (we don't want to ship with pre-defined users ) to check for pi as name we could add this in Armbian too.
 
Another area are the various WiringPi library variants that exist for different SoCs that partially need adjusted settings since pin mappings differ (see example for BPi M2+). AFAIK the knowledge which lib has to be used on which SoC is present here but scattered all over the place. Wouldn't it be cool if people experienced with this stuff start to collect information (as a first step as part of our documentation, later maybe providing own variants of these libs for our most popular SoC variants)?
 
Disclaimer: me is the wrong person for this stuff since I'm still an absolute IoT NOOB and always have a hard time trying out GPIO stuff
 
So this thread is meant to collect ideas and opinions on this.

*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards.  The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor***
 
A lot of boards from various vendors inevitably have some difficulties with electrical signalling.  You see it in delay values, phase correction in software, etc.  The general prevailing theory is almost always "get it close and fix it in software".  But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way.  Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC.
 
This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor.
 
GPIO's on SoC's have, typically, current limiting on each pin or bank of pins.  For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings.  This includes the SD card bus, clock, output, etc.  These current limits are exactly that, limits.  If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting.  if it needs more, however, it will only get what the drive setting allows.
 
SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them.  Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz.  Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208).  The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions.
 
The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card.  I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard.
 
I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance.  In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior.  This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability.  In this circuit the LimiterDiode does exactly that, it limits current.
 

 
With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable.  Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result.
 

 
The board will crash if it attempts this.  Now, you might say, what if the board is extremely well made and the capacitance is lower?
 
Well, it looks like this (assuming 20 pF, which may not really be possible):
 

 
Still, no hope of operating properly.  Dropping to 25 MHz has roughly the same effect.  As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA.  I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin.  Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down.
 
On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA.  I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant
 

 
At 25 MHz, however, 8 mA is far more reasonable:

 
Now to the big reason for 1.8 V signalling:

 
50 MHz, 1.8V, 40 pF, 8 mA drive.
 
Assumptions:  source/sink values both controlled.  It's possible this is not the case.  If there is no "sink" limit, or if you assume 20 mA sink limit:
 
 
3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink:

 
Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V:

 
So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time)  Needless to say, a lot more than 4.
 
This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's.  50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves.  RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode.  Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.
 

The Orange Pi One is the most recent SBC from Xunlong. It's clearly the Orange Pi PC's little sibling. In case you haven't read the PC's review already maybe it's time to do it now since here only important differences will be shown.
 
Since it's based on an Allwinner SoC (system on chip) please keep in mind that you will always find the most comprehensive and up-to-date information in the linux-sunxi wiki: http://linux-sunxi.org/Orange_Pi_One
 
The most important differences between One and PC as follows:
Smaller size: the PC used the RPi form factor (85mm x 55mm) while the One is just 69mm x 48mm in size 512MiB instead of 1GiB DRAM (still two DDR3L modules making use of the full 32 bit memory bandwidth) 2 USB host ports less (available through solder points) IR receiver, microphone and TRRS jack for Audio/CVBS video also missing (available through solder points) GPIO header rotated by 180° A different method to regulate the SoC's core voltage (VDD-CPUX) responsible for a few issues currently The One costs $10 whereas the PC is been sold at $15. Since you don't get large volume discounts on shipping you should better compare prices with shipping included and end up now with $13.63 vs. $18.69 if you order directly in Xunlong's aliexpress store.
 
So you get less for less money but should keep in mind that the size reduction has one serious drawback: Due to the height of USB and Ethernet jacks Xunlong chose to rotate the 40 pin GPIO header and now Add-On boards (RPi HATs) project over the board. And while you can combine for example an Orange Pi PC with a 3.2" Touchscreen LCD to a compact package this isn't possible with the One any longer.
 
The Orange Pi PC fits exactly:
 

 
And that's how it looks with the One:
 

 
You should also take care of the header's orientation when trying out GPIO/1-Wire/I2C stuff and especially when you try to power the board through GPIO pins 2/4/6. They are not where you would expect them like on any other board using the RPi connector (except of Lamobo R1) but on the other side of the header (180° rotation).
 
Different voltage regulator and the consequences:
 
Now to the most important change: the different method to switch the SoC's core voltage. What is this switching for? This thing is called dynamic voltage frequency scaling (dvfs) and the idea behind is to keep the voltage of the SoC's core components as low as possible unless needed. If you want to clock the CPU/GPU cores higher you need more voltage to let them work reliably. On the other hand higher voltage negatively affects temperature, consumption and maybe also longevity.
 
Here the combination of cpufreq scaling and dvfs jumps in. When the CPUs are clocked lower also less voltage is used to feed them. And when they're clocked higher the voltage rises automatically to ensure reliable operation. With dvfs a few operating points are defined that specify at which cpufreq traversal which voltage should be used. This looks then like this example for Orange Pi PC.
 
On the Orange Pi PC a voltage regulator called SY8106A adjustable through I2C is used and it's easy to define up to 16 dvfs operating points. On the Orange Pi One this is different and a more simple voltage regulator has been used (according to schematic the SY8113B should be used but users spotted that on their boards in reality the rather similar AX3833 is used). This voltage regulator supports only two states and according to the Orange Pi forums this should be used to switch the voltage between 1.1V at the lowest CPU clockspeed and 1.3V with the higher clockspeeds (confirmed in the meantime to work on at least one board).
 
Fex/script.bin fixes necessary when using OS images for PC:
 
When you're using OS images for Orange Pi PC on the One then due to the different voltage regulator the log gets filled with countless messages like this:
[ARISC ERROR] :message process error [ARISC ERROR] :message addr : f004b840 [ARISC ERROR] :message state : 5 [ARISC ERROR] :message attr : 2 [ARISC ERROR] :message type : 30 [ARISC ERROR] :message result : ff [ARISC WARING] :callback not install [cpu_freq] ERR:set cpu frequency to 1008MHz failed! Therefore it's necessary to fix this by tweaking the so called fex file when using OS images that still rely on kernel 3.4.x (applies to all currently). It's necessary to exchange the pmuic_type (2 is I2C, 1 is GPIO) and to define at which clockspeed the regulator should switch between its two states. So the most easy solution seems to define 2 operating points as outlined in the sunxi wiki: http://linux-sunxi.org/Orange_Pi_One#Normal_dvfs_settings
 
At least on one board the real voltages used aren't 1.1V and 1.3V but significantly higher instead. My assumption is based on thermal behaviour: the main heat source is the core voltage (VDD-CPUX). Unfortunately my Multimeter died so we're waiting for others to investigate further by checking the 1V2C and VDD_CPUFB test points on the PCB. There is an active discussion in our developer section regarding this at the moment.
 
So there is at least one board where voltages are significantly higher then they should be (leading to overvolted/overheating behaviour without adjusted fex settings) and there is at least another where everything works as expected (and which runs into stability issues when preventing to switch to the higher voltage). Now it's time to collect feedback from users how many are affected by wrong voltage values.
 
How does voltage switching works on the One?
 
So let's have a closer look how the switch between the two voltages works (regardless of the real voltages used -- they have to be confirmed by measuring the 1V2C and TP1 test points on the PCB). In the fex file after changing the pmuic_type to 1 you can define two voltage values and the switch state:
pmu_level0 = 11300 pmu_level1 = 1100 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 648000000 LV2_volt = 1100 This reads like 648MHz @ 1100mV and 1200MHz @ 1300mV. But you could also write the following into and it would work exactly the same:
pmu_level0 = 15000 pmu_level1 = 1500 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 1500 Now it reads 648MHz @ 1500mV and 1200MHz @ 5000mV (clearly exceeding the max. 1400mV allowed for the H3) but it doesn't matter since this just triggers at which cpufreq change the voltage should be switched between the lower and the higher value. So to stay always on the lower voltage you could use
pmu_level0 = 5000 pmu_level1 = 5000 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 5000 And to always use the higher voltage (necessary in case some users are really affected by undervoltage when using the lower available) it could read:
pmu_level0 = 11000 pmu_level1 = 11000 LV1_freq = 1200000000 LV1_volt = 1000 LV2_freq = 648000000 LV2_volt = 1000 This will prevent using the higher voltage in the former case even if there 5000mV are written to the fex and will force the higher in the 2nd example regardless of the voltage value (1000mV). Only the first bit set or not defined in pmu_level0/pmu_level1 is important.
 
Unless this issue is resolved I would stay away from the device. And if you're already an owner of the Orange Pi One you should check whether you're affected by undervoltage/overvoltage issues.
 
Final chapter: Software support for the Orange Pi One:
 
First of all you could use any of the available OS images for Orange Pi PC but would've to adjust the voltage regulator stuff in script.bin/fex. I already updated my fix-thermal-problems.sh script known from the Orange Pi forums to fix overvolted settings for the older Orange Pis to be useable with Orange Pi One/Lite too.
 
In the meantime Armbian started to support all available H3 Orange Pi boards just recently: http://www.armbian.com/download/ (please don't expect yet too much, we're moving fast but it's still a bit early and a lot of work in progress!)
 
Jernej's OpenELEC port also progresses nicely and fully supports Orange Pi One in the meantime (in fact he helped us a lot to improve Armbian support for the One)
 
It can be expected that a lot of improvements for sun7i (A20 SoC used on Cubieboards, the original Bananas and a few more) will be ported over to sun8i/H3 in the next time.
 
And then mainlining effort for the H3 is still improving more and more. I'm using one Orange Pi PC since weeks as NAS with mainline kernel (4.5) and an USB-to-Ethernet dongle since native Ethernet is still not supported. Same applies to display stuff. You can inform yourself about the status always here: http://linux-sunxi.org/Mainlining_Effort#Work_In_Progress
 
Using Orange Pi One with the most recent kernel is already possible combining a few patches and I would suspect that it's just a few weeks until Ethernet and display is working.
 
EDIT: In the meantime enclosures are available (a bit problematic since OPi One suffers from heat issues more than its bigger siblings): laser cut DIY made of 3 mm crystal-clear acrylic and one on Aliexpress.

-

-

Another look at another SBC: The Orange Pi PC from Shenzen based Xunlong.
  The company claims to have done the original ODM work for Banana Pi as Foxconn contractor and started with 2 'Orange Pi' models based on the same A20 SoC shortly thereafter: 'Orange Pi' and 'Orange Pi Mini' -- both supported by Armbian from the beginning.   Then they released the 'Orange Pi Plus' based on a newer Allwinner SoC: the H3 (quad-core Cortex-A7 running at 1.2GHz). This SoC is intended for dirt-cheap OTT boxes, is equipped with 4 independent USB 2.0 PHYs and also an integrated 100 Mbits/sec Ethernet PHY (but can still provide GBit Ethernet using an external PHY like RTL8211 as Xunlong implemented it on the 'Plus').   The 'Orange Pi 2 [Plus]' followed, then the $15 'Orange Pi PC' was released and a new 'Orange Pi One' has been recently announced to be available for less than $10. CNX provided a nice comparison table here (but keep in mind that "SATA" means not SATA but an ultra-slow GL830 USB-to-SATA bridge and that "4 USB ports" means "slow due to shared bandwidth and internal USB hub")   In my opinion the only H3 based Orange Pis worth a look are the 'PC' and the upcoming 'One' since the H3's feature set is quite unimpressive but its design makes it possible to produce really cheap boxes/boards without that much additional components on the PCB (no PMU needed and already containing an internal Ethernet PHY and 4 USB PHYs).   The H3 SoC has been blamed for overheating way too much but fortunately this is just the result of Xunlong trying to advertise their H3 based SBCs as being able to run at "up to 1.6 GHz" and community members providing OS images with overclocking in mind. They did a really bad job modifying both dvfs and thermal settings and therefore their forums are full of complaints that CPU cores are shut down due to overheating or that you would need large heatsinks and also a fan to be able to use the H3 reliably.   Fortunately these issues have been resolved in the meantime, the linux-sunxi community moves forward really fast with u-boot/kernel mainlining efforts for the H3 and real OSHW designs will also follow soon (Olimex plans to release two SBC based on H3). So I believe we will be ready with Armbian support for Olimex' and Xunlong's boards as soon as mainline kernel will be ready for H3. Igor started already to support the H3 based Orange Pis in Armbian-- see below.   Let's have a look at existing hardware: The $15 Orange Pi PC. For latest informations always rely on the linux-sunxi wiki.   Getting started   To power the board you've to provide 5V through the power barrel connector or GPIO pins 2/4/6 (2/4 are connected to the DC-IN test point and 6 to GND). You can not power the board through micro USB since unlike other sunxi devices the H3 comes without PMIC/PMU (therefore also no support for a battery)   In case no SD card is inserted the SoC tries FEL boot mode through the micro USB port. OS images for the H3 can be found on the orangepi.org web site. As usual the manufacturer supplied images are broken more or less so better start with the ones from community member loboris (if you use them don't forget to donate!)   Unfortunately these intensified Xunlong's overvolting/overclocking attempts and increased a few values even more. But fixing is easy: I created a simple script (for Debian based distros only) that temporarely converts script.bin and replaces the wrong values with the linux-sunxi ones (should work with other H3 based Orange Pis as well)   On the left loboris' overvolted dvfs table while idling through all available cpufreqs and on the right after repair:     If you repaired dvfs/thermal settings you'll be surprised that you neither need a fan nor heatsink -- the H3 idles at 1.5W and exceeds ambient temperatures only by 20°C without a heatsink. But be prepared that thermal throttling might occur under high load if you safe the heatsink. You'll find a few comparisons with and without heatsink here: http://linux-sunxi.org/User:Tkaiser#Tests_with_just_a_heatsink   Since we want to use the OPi PC as cheap home automation controllers we evaluated the possible input voltage range. Good news: DC-IN voltage can vary between 4.5V - 5.5V when you neither need USB nor HDMI (DC-IN will be directly routed to the power pins of USB/HDMI).    Also the cheap camera module Xunlong sells for the different H3 models works flawlessly with just 4.5V. This makes it possible to power the board through 'el cheapo' passive PoE using the 2 unused cable pairs in Cat 5/6/7 cables. Real PoE works with 48V to avoid voltage drops over longer distances and it's a bit crazy to try PoE with just 5V. But when you use similar distances between PoE injector and devices and inject for example ~6V then the voltage range of 4.5V-5.5V will be fine. I suggested to Xunlong's Steven Zhao already to adopt passive PoE on the next Orange Pi One directly -- but he didn't get back to me.   I also developed a heavily undervolted dvfs table for headless useage (won't work with a connected HDMI display since the Vcore voltage seems too low for the display engine) that works here with 2 OPi PC without problems (tested under full load up to 1.2 GHz): http://linux-sunxi.org/User:Tkaiser#Headless_without_connected_USB_peripherals_and_4.5V_DC-IN ( don't think about adopting these settings unless you're willing to verify they work!)   Consumption/temperatures in headless mode:   The OPi PC idles at 240-600MHz: 1.5W, 20°C above ambient temperature. All thermal values being read-out internally using RPi-Monitor -- see below. I used also the H3 without heatsink so be prepared that temperatures are way lower if you attach a heatsink to the SoC.   Full load (cpuburn-a7 and sysbench running in parallel) on all 4 CPU cores:   240 MHz: not exceeding 2.0W, 25°C above ambient temperature 600 MHz: not exceeding 2.5W, 32°C above ambient temperature 1200 MHz: not exceeding 3.3W, 50°C above ambient temperature   2 CPU cores deactivated and testing again:   240 MHz: not exceeding 1.9W, 23°C above ambient temperature 600 MHz: not exceeding 2.1W, 29°C above ambient temperature 1200 MHz: not exceeding 2.8W, 40°C above ambient temperature   The multithreaded performance of 4 x 600 MHz and 2 x 1200 MHz is identical but when running at 600 MHz on all 4 cores the H3 already outperforms older dual-core Allwinner SoCs like the A20 easily. And since the lower the clockspeeds the less the Vcore voltage the SoC stays cooler and consumes less. Using a quad-core SoC for IoT stuff seems like overkill but if you clock the SoC down the 4 cores make perfectly sense.   Therefore we go with the following settings for 'IoT controllers' to ensure they don't exceed 2.5W consumption even under full load: echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq   With 8 OPi PC and a passive PoE injector like this one with these settings you're able to power the whole setup with a regulated 6V/4A PSU easily. And you still have the ability to double the performance of any device temporarely through echoing 1200000 to scaling_max_freq when needed.   Who would've thought that you can use H3 based Orange Pis as energy efficient IoT devices consuming between 1.5W and 2.5W without a heatsink since common knowledge was 'you need a fan!' just a few weeks ago.   Camera module   Xunlong sells also a cheap $6 camera module for the H3 based Orange Pi models based on GalaxyCore's GC2035 2MP sensor. When you want to use it with the OPi PC you'll also need an expansion board. When you order you've to tell Xunlong that you're using the OPi PC and they send the board together with the module:     The image quality is really horrible but at least you're able to use it with fswebcam or motion. I prefer the lowest resolution possible (640x480 pixels after applying these patches) because it makes no sense to store images with higher resolutions. At least motion works with the 2 fps settings currently possible and you might use OPi PC + camera module for surveillance purposes to detect motion.   Regarding consumption/temperatures: when running motion together with the camera continuously consumption increases by 500-600 mW and SoC temperatures by 2-3°C (clocked at 240-600 MHz)   For our use cases the H3 matches perfectly. If you fix the overvoltage/overclocking problems Xunlong introduced then you get a device that consumes between 1.5W and 2.5W and being already more performant when running at 600 MHz than older dual-core Allwinner SoCs. Using a quad-core SoC for IoT things makes sense since the SoC can run at very low core voltages which really helps with saving energy.   Other use cases   Regarding I/O bandwidth the H3 provides 4 independant USB ports that might be able to benefit from UASP with mainline kernel soon. So any H3 device with GBit Ethernet would make a nice NAS device. But since the older A20 features native SATA a better solution for building a NAS would be to get a pcDuino 3 Nano Lite for the same price. Some background infos as usual in the wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS   At the moment some people are trying hard to get OpenELEC running on the H3 and also progress is made to use HW accelerated video decoding. Since this stuff is WiP you should monitor these threads closely:   OpenELEC HW accelerated video decoding   RPi-Monitor   I adjusted RPi-Monitor templates for the H3 and also wrote a small daemon to be able to monitor temperature/consumption related to Vcore settings (using the dvfs table settings in script.bin). Please refer to the thread in the Orange Pi forums.   All you've to do is to install RPi-Monitor in the usual way, stop it and then do the following (depending on your distro being wheezy/jessie based) followed by a reboot:  cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 systemctl enable rpimonitor-helper systemctl start rpimonitor-helper Update: In the meantime this has become a simple one-liner confirmed to work an all Debian based OS images for H3 boards. And in case you're running Armbian then it's just a a simple 'sudo armbianmonitor -r' call that installs/adjusts everything needed on any H3 board.

Oh, there's something we also need to take care of with upgrades: the existing 128MB swap file on SD card present in /etc/fstab:
total used free shared buff/cache available Mem: 494M 66M 269M 2.7M 158M 415M Swap: 375M 0B 375M NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 50M 11.1M 2.9M 3.3M 4 /var/log /dev/zram1 lz4 61.8M 4K 63B 4K 4 [SWAP] /dev/zram2 lz4 61.8M 4K 63B 4K 4 [SWAP] /dev/zram3 lz4 61.8M 4K 63B 4K 4 [SWAP] /dev/zram4 lz4 61.8M 4K 63B 4K 4 [SWAP] With vm.swappiness=100 now it might be possible that the system decides to start to swap to SD card even if swap priority is pretty low. @Igor what do you think? Checking size of swap file and if it's 'our' 128MB file then removing fstab entry and swap file on upgrade?

-

Review available: 
 

I had the SSH session window still open and collected the relevant logging portions from 'iostat 1800' while running the test with USB3, USB2 and then again zram/lzo (which also surprisingly again outperformed lz4):
USB3: %user %nice %system %iowait %steal %idle 82.31 0.00 12.56 4.68 0.00 0.45 74.77 0.00 16.80 8.25 0.00 0.18 55.24 0.00 19.84 24.44 0.00 0.48 72.22 0.00 16.94 10.43 0.00 0.41 50.96 0.00 22.24 26.09 0.00 0.71 USB2: %user %nice %system %iowait %steal %idle 81.77 0.00 11.95 5.30 0.00 0.99 75.99 0.00 16.95 6.71 0.00 0.35 66.50 0.00 19.19 13.81 0.00 0.49 77.64 0.00 18.31 3.97 0.00 0.08 44.17 0.00 12.99 13.09 0.00 29.74 zram/lzo: %user %nice %system %iowait %steal %idle 84.83 0.00 14.68 0.01 0.00 0.48 82.94 0.00 17.06 0.00 0.00 0.00 81.51 0.00 18.49 0.00 0.00 0.00 78.33 0.00 21.66 0.00 0.00 0.01  
 
That's an interesting point and clearly something I forgot to check. But I was running with latest IRQ assignment settings (USB2 on CPU1 and USB3 on CPU2) so there shouldn't have been a problem with my crippled setup (hiding CPUs 4 and 5). But iostat output above reveals that %iowait with USB3 was much higher compared to USB2 so this is clearly something that needs more investigations.

Since I was not entirely sure whether 'test has been executed appropriately' I went a bit further to test no swap vs. zram on a RK3399 device directly. I had to move from RockPro64 to NanoPC-T4 since with ayufan OS image on RockPro64 I didn't manage to restrict available DRAM in extlinux.conf
 
So I did my test with Armbian on a NanoPC-T4. One time I let the build job run with 4 GB DRAM available and no swapping, next time I limited available physical memory to 1 GB via extraargs="mem=1110M" in /boot/armbianEnv.txt and swapping happened with lz4 compression.
 
We're talking about a 12% difference in performance: 4302 seconds without swapping vs. 4855 seconds with zram/lz4:
tk@nanopct4:~/ComputeLibrary-18.03$ time taskset -c 0-3 scons Werror=1 -j8 debug=0 neon=1 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a build=native ... real 71m42.193s user 277m55.787s sys 8m7.028s tk@nanopct4:~/ComputeLibrary-18.03$ free total used free shared buff/cache available Mem: 3902736 105600 3132652 8456 664484 3698568 Swap: 6291440 0 6291440 And now with zram/lz4:
tk@nanopct4:~/ComputeLibrary-18.03$ time taskset -c 0-3 scons Werror=1 -j8 debug=0 neon=1 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a build=native ... real 80m55.042s user 293m12.371s sys 27m48.478s tk@nanopct4:~/ComputeLibrary-18.03$ free total used free shared buff/cache available Mem: 1014192 85372 850404 3684 78416 853944 Swap: 3042560 27608 3014952  
Problem is: this test is not that representative for real-world workloads since I artificially limited the build job to CPUs 0-3 (little cores) and therefore all the memory compression stuff happened on the two free A72 cores. So next test: trying to disable the two big cores in RK3399 entirely. For whatever reasons setting extraargs="mem=1110M maxcpus=4" in /boot/armbianEnv.txt didn't work (obviously a problem with boot.cmd used for the board) so I ended up with:
extraargs="mem=1110M" extraboardargs="maxcpus=4" After a reboot /proc/cpuinfo confirms that only little cores are available any more and we're running with just 1 GB DRAM. Only caveat: cpufreq scaling is also gone and now the little cores are clocked with ~806 MHz:
root@nanopct4:~# /usr/local/src/mhz/mhz 3 100000 count=330570 us50=20515 us250=102670 diff=82155 cpu_MHz=804.747 count=330570 us50=20540 us250=102614 diff=82074 cpu_MHz=805.541 count=330570 us50=20542 us250=102645 diff=82103 cpu_MHz=805.257 So then this test will answer a different question: how much overhead adds zram based swapping on much slower boards. That's ok too
 
To be continued...

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.