NicoD

Up to @tkaiser for results on sbc-bench...
 
working on an addition - byte-unixbench and sorting out things... removing some gcc over optimizations, looking at threads...
 
https://github.com/sfx2000/byte-unixbench
 
It's a better bench than sysbench, and portable... Doing a -c 1 -1 and -c4 -i 1  keeps things short - however - letting it run thru pushes heat/throttles...
 
UnixBench is interesting from a system perspective...
 
RPI3 B Plus vs Tinker....
 
Tinker is 15 pounds of power in a 5 pound sack - RPi3 B+ is a CPU that can do better that it is with raspbian....
 
Tinkerboard - Cortex-A12/A17 - Armbian ------------------------------------------------------------------------ Benchmark Run: Sat Oct 20 2018 17:02:37 - 17:31:22 4 CPUs in system; running 1 parallel copy of tests System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0    8709974.2    746.4 Double-Precision Whetstone                       55.0       1031.4    187.5 Execl Throughput                                 43.0       1095.7    254.8 File Copy 1024 bufsize 2000 maxblocks          3960.0      91960.7    232.2 File Copy 256 bufsize 500 maxblocks            1655.0      26583.4    160.6 File Copy 4096 bufsize 8000 maxblocks          5800.0     246267.0    424.6 Pipe Throughput                               12440.0     149851.8    120.5 Pipe-based Context Switching                   4000.0      25850.9     64.6 Process Creation                                126.0       2429.0    192.8 Shell Scripts (1 concurrent)                     42.4       2061.9    486.3 Shell Scripts (8 concurrent)                      6.0        432.0    720.1 System Call Overhead                          15000.0     442992.8    295.3                                                                    ======== System Benchmarks Index Score                                         258.2 System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0   13538575.0   1160.1 Double-Precision Whetstone                       55.0       1982.4    360.4 Execl Throughput                                 43.0       1752.7    407.6 File Copy 1024 bufsize 2000 maxblocks          3960.0      87122.4    220.0 File Copy 256 bufsize 500 maxblocks            1655.0      22948.6    138.7 File Copy 4096 bufsize 8000 maxblocks          5800.0     281302.7    485.0 Pipe Throughput                               12440.0     321233.1    258.2 Pipe-based Context Switching                   4000.0      40012.9    100.0 Process Creation                                126.0       3820.3    303.2 Shell Scripts (1 concurrent)                     42.4       3399.0    801.7 Shell Scripts (8 concurrent)                      6.0        433.6    722.7 System Call Overhead                          15000.0     952658.0    635.1                                                                    ======== System Benchmarks Index Score                                         373.1 Rpi 3B+ - Cortex-A53 - VCOS/ThreadX - Raspian ------------------------------------------------------------------------ Benchmark Run: Sat Oct 20 2018 17:02:32 - 17:30:38 4 CPUs in system; running 1 parallel copy of tests System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0    4324740.1    370.6 Double-Precision Whetstone                       55.0        957.4    174.1 Execl Throughput                                 43.0        908.8    211.4 File Copy 1024 bufsize 2000 maxblocks          3960.0     140312.9    354.3 File Copy 256 bufsize 500 maxblocks            1655.0      40618.4    245.4 File Copy 4096 bufsize 8000 maxblocks          5800.0     353296.2    609.1 Pipe Throughput                               12440.0     280908.2    225.8 Pipe-based Context Switching                   4000.0      50734.2    126.8 Process Creation                                126.0       2212.2    175.6 Shell Scripts (1 concurrent)                     42.4       1780.5    419.9 Shell Scripts (8 concurrent)                      6.0        575.7    959.5 System Call Overhead                          15000.0     594784.0    396.5                                                                    ======== System Benchmarks Index Score                                         302.2 System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0   17082008.4   1463.8 Double-Precision Whetstone                       55.0       3803.4    691.5 Execl Throughput                                 43.0       2240.8    521.1 File Copy 1024 bufsize 2000 maxblocks          3960.0     228921.9    578.1 File Copy 256 bufsize 500 maxblocks            1655.0      62777.0    379.3 File Copy 4096 bufsize 8000 maxblocks          5800.0     578721.9    997.8 Pipe Throughput                               12440.0    1112342.2    894.2 Pipe-based Context Switching                   4000.0      98478.8    246.2 Process Creation                                126.0       4789.7    380.1 Shell Scripts (1 concurrent)                     42.4       4464.7   1053.0 Shell Scripts (8 concurrent)                      6.0        589.0    981.7 System Call Overhead                          15000.0    2289227.2   1526.2                                                                    ======== System Benchmarks Index Score                                         705.6  

Gah - watched the video - and a lot of problems across the board (pardon the pun).
 
Different kernels, built with different versions of GCC, userland (for example, Raspbian userland is all ARMv6 with exception of the kernel for the A7/A53 boards)....
 
(I wouldn't have included the any of the Pi's in the set of boards being evaluated because of the userland - <soapbox> nothing against Pi's in general, one must appreciate that 35M+ boards means they're doing something right, and they've spawned an entire HW/SW ecosystem around their platform, that's ok - and that ecosystem has in turn made affordable ARM boards available for hobbyists, makers, and developers - before Pi, if one wanted to do development around ARM, boards were expensive, and SW support was very limited to the vendor BSP - these days, it's a lot more open - not perfect, but much better than it was</soapbox>)
 
Rock64 vs Odroid XU4 - Quad A53 vs A7/A15 big.LITTLE - the big.LITTLE is a challenge for the scheduler, and depending on the BSP from the OEM, it's easy to get wrong, where threads can land on the lesser preferred core, this is an issue even on Android, where much work has been done outside of the mainline kernels (ARM and Qualcomm, I know they've done a lot of research there, but much of that has not been pushed back to mainline).
 
In my experience, with supported boards (for me this is Tinker and NanoPi NEO), Armbian is generally faster than the vendor's images - and that's doing Byte-Unixbench, which is discounted because it is compiler sensitive - that being said, it's still a useful tool when comparing apples to apples (e.g. tweaking settings on the same OS/Platform, but comparing Platform A to Platform B, one has to take the results with a grain of salt)
 
I haven't found a lot of evidence of cheating by any of the SBC vendors - it's really hard to do with FOSS, compared to Android, where cheating has occurred with certain OEM's and specific benchmark APK's - Android has enough hooks to enable this kind of cheating in any event.
 
sbc-bench, in my humble opinion, is a good benchmark for supported boards - as long as the boards being compared are all on the same version of Armbian - and this is made clear in the script comments (please review the script on github, and @tkaiser has been pushing updates, so if one has cloned the repo, it's worthwhile to do a git pull to get the latest revision.
 
To answer your question about the different versions of Cortex...
 
Small Cores - A7, A53 are the low power cores focused on efficiency
Big Cores - A15, A12(A17), A72 - big cores... 
 
Think of it like Atom (Small Core) vs Core i3/i5/i7 (Big Core) - even at the same clock, the big core is going to get more work done, but perhaps at the cost of heat, so thermal solution needs to be considered.

as far as I can see, the same wifi chip as for the firefly is populated on this board.. so by using the same drivers, and ensure it's properly defined in DT chances are high(er) that it should work 'as expected'. Using the same kernel as @hjc used for the firefly..
 
GbE is also the same, then it should be just adjustments in case DT definition changed slightly..  And if it performs badly:
https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test
 
well you've to be in case you want to give it a try.. I'll only help you.. build and test is then up to you... I prefer to mess with DT rather than fixing then broken things after the image is created.. From the sources, this is mostly a reference board with a few additional stuff populated (http://vamrs.com/sapphire-excavator).. There's not much an reason why things should not work. 
 
doesn't need years, DT is good enough described in the documentation to learn it.. 

interesting that they want to dive into the Intel world.. Well I assume it's less work to maintain (e.g. just fire up a recent ubuntu and you're done no hacky arm digging in u-boot or kernel ). CPU reminds me to the old AMDs 10/15 years ago where you always had to be afraid to kill it by mounting the cooler (kill one of those small caps on it and silver thermal paste was the standard so shorting was also an option ). A nice homeserver/NAS thingie for those who don't want to deal with arm. They planed funny cases.. e.g 'iteration iv':

 
but consumption looks IMO impressive (I've to admit, I've no clue how much recent intel low-level CPUs normally need - my last intel was a 7'' atom tablet with 16GB ram and a crappy display for 40$ on discount  the tablet collects dust and the USB charger is used to power an OPi Zero - they sent it with a good powering cable  ) 
 

Under 20$
the Raspberry Pi Zero W for 10$. It's very slow with only 1 core at 1Ghz. You can watch youtube with kiosk browser. And surf, very slowly.
The Banana Pi M2 Zero for 20$. A lot faster. 4x1.2Ghz. You need a good heatsink for it or it overheats constantly. Not very good video playback.
For 25$ the Rock64. Faster, better, but no wifi on-board.
A raspberry pi 3b+ is 35$ and again a bit better.
For your use case an Odroid C2 is perfect. Good Youtube playback, fast, doesn't overheat, ... That's about 50$

Those or the ones I have, and I can recommend. But for 20$ you will not get much.
You need to know that many sbc's don't have hardware acceleration for video playback in browsers. So expect choppy and low resolution video with most. The Odroid C2 does this best in Linux.
Also if a board only has 512MB ram then you want be able to open many tabs.

FriendlyArm also has got some interesting cheap boards.

I review sbc's on their desktop capabilities. Of all those I've got a video, except the C2.
https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg

That NanoPi M4 looks really great, even though it's still pretty new and software support is still in the works. I might be willing to take a gamble on this board since I suspect the Rockchip 3399 will become fairly well supported.
 
I forgot to mention that small form factor is important to me as my project is concealing a wifi-enabled server in an RGB accent lamp which I will carry around with me while living an "ultramobile" lifestyle So, the NanoPi M4 wins on form factor as well. I suspect I could arrive at a tolerable thermal situation by some combination of a copper shim to the heatsink, mounting non-horizontally and building the enclosure with convection in mind, and perhaps some tinkering with clock speeds as needed.
 
Looks like wifi might still be a bit dodgy. I suppose I'll have to take my chances with that and fall back on a known good USB adapter if support is problematic for longer than I have to wait.
 
Thanks so much for the pointers!

This is a good review of the Nano Pi M4.
 
 

I replaced the cable with a 0.25m USB Type-A to Type-C cable (a really cheap one), and it turns out that the voltage is much more stable. At full load+2*RTL8153, it's still up at ~4.97V, and multiple RTL8153 works like a charm now.
 
However it seems that multiple RTL8153 behind a hub has some limitations. On the switch I can see traffic coming out on both USB attached ports, but they're only ~1.3Gbps total. When doing all port test (internal GbE+2 RTL8153, peer is 6*82583v configured with LACP), CPU0 is 100% and CPU2 is near 100%. I guess the A53 cores are not capable of handling such load. Anyway, currently the best choice seems to be attaching one additional RTL8153 for networking. It handles 2Gbps traffic in both directions simultaneously.

That hat is specially for this board. I'll order it when it's out.
For NAS this board is perfect. With an external hd with usb3 or with that sata hat.

@nicoD
Fantastic video you made for this board. I really really want to order one after watching your video!
Thanks a lot!

Hi all.
The undervoltage problem was a bad cable. It's a lot more stable with the original cable.
I've finished my review video about the NanoPi M4.
Again with a great working Armbian. Thank you to everyone who worked on Armbian. Great job.
Greetings.
NicoD
 

Hi all.
The undervoltage problem was a bad cable. It's a lot more stable with the original cable.
I've finished my review video about the NanoPi M4.
Again with a great working Armbian. Thank you to everyone who worked on Armbian. Great job.
Greetings.
NicoD
 

So it's not a defect of the board, right? That's good news. I'd get some shorter cable w/ lower resistance and try to test 2*RTL8153 again.

The problem was my cable. I'm sorry for the confusion.
I've tried again with the short cable they gave with it, and it's a lot better. 1A load and cpu maxed in Armbian makes it sink 0.4V instead of 1V. A huge difference. I should have seen it earlier. The cable was too short to put the M4 on my table with it...
Sorry. Only issue is that it reached 85°C without a fan. But that's only after +14minutes full load. People who max these things should know to use a fan.
Cheers
 

well, there you go: http://docs.armbian.com/Process_Contribute/ 
The way this might be possible is over devicetree overlay. Someone has to implement it, someone has to test it and to quote @Igor: Those 'someones' are rare and the few we have are already overloaded. You may want to make a video how you improved armbian by patching not only reporting?  
Maybe you can simply adjust it similar to here?
 
I never tested it on big.LITTLE SoCs 

I can confirm that my M4 also has the voltage drop issue.
1 RTL8153 connected, system idle: 4.9V Running iperf3 and generate 2Gbps traffic: 4.7V Running iperf3 with 6x cpuburn: 4.5V On NanoPC T4 the voltage is always 5.0V no matter what workload I run.

Here my temperatures with a small fan on the underside and some screws to raise it. As tkaiser said. It works better when the fan blows over a larger area. This works good enough.
It's a great heatsink. But the downside is that it heats up the whole board. So I don't think it's healty to constantly run it at 85°C. I've done it for 1h for a test. The board smelled badly. I want do it again. With low loads it doesn't heat up quickly.

Temperature
---------------
Armbian Bionic/Stretch 64-bit 2Ghz + 1.5Ghz
                        With fan idle        36°C
                        With fan maxed   65°C
                        No fan idle           40°C
                        No fan maxed     Throttles at 85°C after 14m30s
                        
Lubuntu armhf/arm64 1.8Ghz + 1.4GHz
                        With fan idle       29°C
                        With fan maxed   54°C
                        No fan idle          42°C
                        No fan maxed     69°C (after 30 minutes maxed)

Hi all.
I've discovered Vivaldi Browser for arm. A fork of Chromium.
There is a armhf version and a arm64 version.
Youtube playback with this is a lot better. I've tested it on the NanoPi M4.
The same video in Chromium had 2/3 dropped frames. (10 frames/s) 1080p video
With Vivaldi browser you get 1/3 dropped frames. (20 frames/s)
A lot better experience.

Here you can download it.
https://vivaldi.com/nl/blog/snapshots/vivaldi-1-15-rc-2/
 
Here the source where I found it. From Meveric @ Odroid. Also explanation of how to install. No wget, and change filename to the file you've downloaded for gdebi. Or use gdebi package installer.(not tested)
https://forum.odroid.com/viewtopic.php?t=29229

I tried in armhf on the M4 in armhf Lubuntu, worked great. Also tried the arm64 in Armbian Stretch. Also great.
I didn't find any posts about Vivaldi in the Armbian forum. I thought it could be helpful.
Cheers

Hi all.
I've discovered Vivaldi Browser for arm. A fork of Chromium.
There is a armhf version and a arm64 version.
Youtube playback with this is a lot better. I've tested it on the NanoPi M4.
The same video in Chromium had 2/3 dropped frames. (10 frames/s) 1080p video
With Vivaldi browser you get 1/3 dropped frames. (20 frames/s)
A lot better experience.

Here you can download it.
https://vivaldi.com/nl/blog/snapshots/vivaldi-1-15-rc-2/
 
Here the source where I found it. From Meveric @ Odroid. Also explanation of how to install. No wget, and change filename to the file you've downloaded for gdebi. Or use gdebi package installer.(not tested)
https://forum.odroid.com/viewtopic.php?t=29229

I tried in armhf on the M4 in armhf Lubuntu, worked great. Also tried the arm64 in Armbian Stretch. Also great.
I didn't find any posts about Vivaldi in the Armbian forum. I thought it could be helpful.
Cheers

Not the final version.

 
Update(8/24/2018): It's time to deal with NEO4, this picture is not the final version. NEO4 will have PCIe x2 and eMMC connector too, and a MIPI-CSI. But the dual-layer USB connector  will share USB 3.0 & USB 2.0, Type-C take another USB 3.0.

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  

Thanks for your suggestion, we made a SATA HAT prototype for NanoPi M4, it can connect  with 4x 3.5inch hard drive and work well.
 
 

And two quick storage performance updates:
 
1) This is the 8GB eMMC FriendlyELEC sells (write performance limited to 43 MB/s as it's mostly the case with low capacity eMMC, read performance exceeding 130 MB/s, nice random IO values -- compare with our overview):
random random kB reclen write rewrite read reread read write 102400 4 8565 8793 24853 24808 19463 8523 102400 16 25604 25986 66627 66701 56571 24459 102400 512 42217 42326 125788 126508 125959 40394 102400 1024 42762 43178 129692 129726 130452 42636 102400 16384 43914 42877 132828 133254 133417 43012  
2) In the meantime I built also OMV images for NanoPC T4 and NanoPi M4 and did a quick LanTest benchmark with M4 and an externally connected Seagate Barracuda in an USB3 enclosure (not UAS capable -- but this doesn't matter with HDDs)
 
Close to 100 MB/s sequential speed without any more optimizations is simply awesome:

(debug output)

Nope, everything as expected. The M4 number in the list https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md has been made with mainline kernel which shows way higher memory bandwidth on RK3399 (check the other RK3399 devices there). Cpuminer numbers differ due to GCC version (Stretch ships with 6.3, Bionic with 7.3 -- see the first three Rock64 numbers with 1400 MHz in the list -- always Stretch but two times with manually built newer GCC versions which significantly improve cpuminer performance)
 
If you love performance use recent software...

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.