I’ve just written Getting Started Guide for Orange Pi One, a $10 development board based on Allwinner H3 quad core Cortex A7 processor, where I explain how to install and configure Armbian distribution on the board. As promised, I’ve also tested 3D graphics acceleration, and hardware video decoding, and also included some Ethernet benchmarks.
Since ARM Mali-400 GPU found in Allwinner H3 is only capable of OpenGL ES, as in most ARM SoCs, you can test 3D graphics acceleration by using es2gears (and not glxgears as I’ve seen some other do in the past):
|
1 2 3 4 5 6 |
es2gears EGL_VERSION = 1.4 Linux-r3p0-04rel0 vertex shader info: fragment shader info: info: 1463 frames in 5.0 seconds = 292.425 FPS |
The log shows the utility is using Linux-r3p0 Mali driver, and the gears are display at a high frame rate close to 300 fps. If I switch to full screen, the frame rate drops to about 43 fps, which should still be acceptable.
CedarX is the infamous closed source and GPL violating media library released by Allwinner, but the community has worked on an open source alternative dubbed Cedrus, which armbian is using. It has some limitations, but it did a good enough job with Big Buck Bunny 720p and 1080p H.264 videos using mpv to play from a USB flash drive:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
mpv big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4 Playing: big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4 (+) Video --vid=1 (*) (h264) (+) Audio --aid=1 --alang=und (*) (aac) File tags: Artist: created with SUPER(C).v2011.bld.49 Comment: 09:51:32 Title: big_buck_bunny_1080p_surround.avi_006.AVI.MP4 [VDPAU SUNXI] VE version 0x1680 opened [VDPAU SUNXI] OSD disabled! Using hardware decoding (vdpau). VO: [vdpau] 1920x1080 vdpau [VDPAU SUNXI] Presentation time not supported AO: [alsa] 44100Hz stereo 2ch s32 AV: 00:00:00 / 00:00:45 (0%) A-V: 0.031 Cache: 10s+30MB AV: 00:00:00 / 00:00:45 (0%) A-V: 0.031 Cache: 10s+30MB AV: 00:00:00 / 00:00:45 (0%) A-V: 0.000 Cache: 10s+30MB AV: 00:00:00 / 00:00:45 (0%) A-V: 0.000 Cache: 10s+30MB AV: 00:00:00 / 00:00:45 (0%) A-V: 0.000 Cache: 10s+30MB AV: 00:00:00 / 00:00:45 (0%) A-V: 0.000 Cache: 10s+30MB |
Again the log clearly shows hardware video decoding is enabled, and you can see the actual results in the demo video below.
So while es2gears rendering window was very smooth, I found CPU usage to be very high, mostly due to Iceweasel, but even after exiting the web browser, I found it was still fairly high. You will also have noticed a massive lag when moving the browser window around. The system could however handle both es2gears and playing a 720p video at the same time. The 1080p video started with some frame drops, but overall played smoothly, so that’s a positive. Sadly H.265 reverts to software decoding, despite both Cedrus and Allwinner H3 supporting the new codec.
Finally, I tested the network performance of the 100m Ethernet interface using a full duplex transfer with iperf -t 60 -c server_ip -d command:
|
1 2 3 4 5 6 7 |
Client connecting to 192.168.0.112, TCP port 5001 TCP window size: 170 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.0.104 port 36016 connected with 192.168.0.112 port 5001 [ ID] Interval Transfer Bandwidth [ 6] 0.0-60.0 sec 218 MBytes 30.5 Mbits/sec [ 4] 0.0-60.3 sec 671 MBytes 93.4 Mbits/sec |
The download could basically fill the maximum bandwidth, but the upload was limited to 30 Mbps when both occur at the same time.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
interesting.. Thanks!
Keep up the good work!
Awesome tutorial, worth to read.
Is the upload speed through Ethernet is limited to 30 Mbps in every Allwinner H3 based SBC ? Or there is a glitch in Orange Pi One hardware design ? possibly to cut down the cost.
@Arnab
You get ~95 Mbits/sec in each direction individually with our default settings. When you switch to performance governor you get better results (current CPU clockspeed affects network throughput as with most other ‘tablet grade’ ARM SoCs). Then it looks like:
But in every normal situation you max. out Fast Ethernet bandwidth. Don’t expect that any Armbian dev looks into this issue since it has no relevance (at least for us). The mainline Ethernet drivers have been updated yesterday evening and I let an Armbian test build create just 2 hours later (kernel 4.5), unfortunately still not ready for prime time but I would suspect it’s just a few days then we will also roll out Armbian images with mainline kernel.
It should be noted that iperf is not really a good litmus test for anything other than peak available on the link. It was written as a quick and dirty test for supercompute clusters to validate proper configuration of ultra-high speed links between nodes in a cluster and to help with the initial steps on diagnosing problems.
The problem with using it solely to base judgement and belief on performance is that it’s blindingly simple in nature and doesn’t reflect the reality of things like database, FTP, etc. servers running on these devices. iperf can saturate a link (is designed to be simple enough for most devices to be able to do so), but real applications will not match expectations out of iperf.
@Arnab
The limitation isn’t the hardware or the driver. As I said in my previous post, iperf’s not a good judge of speed. Wasn’t designed for that and I wish people would quit using it for that, claiming “ethernet performance” when they post iperf or similar results. You’re measuring the absolute theoretical peak of the device with it and nothing else.
Now, it should be observed that *most* of the “tablet grade” ARM SoC’s can’t handle more than a bit above 100Mbit bi-directionally, because the CPU can’t drive it much faster than that. Back when they started rolling out 1Gbit on pretty much every PC, it was a because they could reason, not because the machine needed or could USE it. It’s no different on this story. I keep cringing when people point to boards in this class that sport GigE and claim it’s “better”- which is more “maybe” than anything else. Most cases, no, you’re not even close to being anything other than hoodwinked as evidenced by this discrepancy you’ve noted here. You’re being marketed to on those cases. You’re better off with the OrangePi or the RPi3B (If you can lay hands on it…) than many of the boards in this class…because the GigE buys you nothing (as does the “native SATA”) The machine can’t take advantage of it.
Excellent work @cnxsoft! Do we know if the Pi Camera is compatible with this board?
@Nobody of Import
Agreed, iperf is clearly the wrong tool to measure ‘real world’ network performance. But that’s also true for nearly all other ‘common’ tools the average user (and unfortunately also ‘Pros’) uses, takes the results for granted and decides then based on ‘numbers without meaning’.
Regarding CPU usage you’re fortunately wrong: http://kaiser-edv.de/tmp/sItUhs/ (~20% max when dealing with Fast Ethernet on OPi PC, on the One it might be 23% then since we don’t allow it to be clocked that high as PC). Since adjusting CPU clockspeeds influences the performance it must be a simple tweak somewhere so get full speed in both directions (but as already written: none of us devs cares about 3.4.x that much and it’s Fast Ethernet anyway).
Regarding GbE (and also SATA) and tablet grade SoCs : http://linux-sunxi.org/Sunxi_devices_as_NAS (with appropriate settings and mainline kernel old boring SoCs like A20 can really shine — at least for the price. And what most if not all benchmarks don’t cover: Random I/O is way better with SATA unless you can benefit from UASP)
so, “hardware acceleration”… which still loads the cpu a lot (apart of loading the vpu 100% of course), overheating, melting down, whith lags, jerkings and overall wasting of all expectations. no, this is not about this particular device, this is an observation on overall hardware “acceleration” rush. (to be honest, I have never ever seen a linux machine of any architecture, not loading cpu high, so it’s maybe not the fail of the “acceleration” itself, but again, did anybody a comparison of how power consumption relates when a board does “software” decoding, thus on the cpu and “hardware” decoding, thus with those “magic” vpu’s? because many people seem believe in this vpu “advantages” so blindly, so maybe someone did an actual analyzis. intereststing to know. though I understand, these tiny SoC’s arm cores might not take it at all, at least on linux) btw, not for flame, just for contrast, my old P4, PC does software decoding of the 1K h264 on Windows without any “vpu” and you know what – the load is not higher than ~4% (average load is even lesser, ~1-2%). So maybe these are not relevant expectations?
@cortex-a72
I did not really test but at least looked into it. Just playing a HEVC movie (jellyfish-90-mbps-hd-hevc.mkv (324MB in size, 90 Mbps bitrate, 1920×1080, HEVC, Main profile, Level 5.0, Tier: high) HW accelerated with H3 means a few degrees more and 0.8W more in the first part of the movie and ~0.3/0.4W the last seconds (less motion I would suspect). According to RPi forums this is something you need already overclocking and a heatsink on RPi 3 since there HEVC decoding isn’t HW accelerated:
http://forum.armbian.com/index.php/topic/789-breaking-news-choosing-armbian-speeds-up-your-orange-pi-multiple-times/?p=6009
Disclaimer: I’ve no idea why Jean-Luc experienced high CPU utilisation in this situation and I’m a video NOOB. We just packaged what members of the great linux-sunxi community (reverse) engineered and are aware that there is still a lot of room for improvements in this area. But most of us at Armbian lack both skills and interest regarding ‘GUI stuff’
@cortex-a72
CPU usage on OrangePI PC with jernej’s openelec port decoding H265 1080p (cedarx-h265):
Mem: 440556K used, 383844K free, 6060K shrd, 40648K buff, 195696K cached
CPU0: 1.4% usr 0.8% sys 0.0% nic 96.8% idle 0.0% io 0.0% irq 0.8% sirq
CPU1: 1.4% usr 0.6% sys 0.0% nic 97.9% idle 0.0% io 0.0% irq 0.0% sirq
CPU2: 2.2% usr 0.6% sys 0.0% nic 96.8% idle 0.0% io 0.0% irq 0.2% sirq
CPU3: 0.6% usr 3.6% sys 1.2% nic 94.2% idle 0.0% io 0.0% irq 0.2% sirq
Load average: 3.23 3.31 2.37 2/114 2207
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
594 589 root S 582m 71.9 2 3.4 /usr/lib/kodi/kodi.bin –standalone -fs –lircdev /run/lirc/lircd
@pmos69
ok, this is a much better picture, totally different of what is seen in the overview above, but this is CedarX working, right? The Cpu isn’t totally offloaded still, but the picture is way better, I agree. But we all know, not only CPU part consumes power, all modules do! And I strongly doubt VPU is “lightweight” in this. How about power consumption during its work? How do you think? Is it more or less power hungry than the cpu (on the same work)? Didn’t you measure it? SoC temperature? Is it really “offloaded”? I heard about other board when vpu is working, the SoC gets melt down. I mean, what benefits of using a vpu are if it still draws alot power, heats the SoC (maybe even more than cpu)? The only reason could be the CPU which isn’t capable to handle the task by itself. Isn’t it really? This question isn’t clear, because it looks like we cannot check its full potential with partially functioning mediocre current video decoding software on the linux. After all you saw the video in the overview. That state of support is not usable.
r3p0 wow that’s old
but having cedarx vdpau working is cool
@cnxsoft – the window moving slowly is from the window manager – you can try “sudo apt-get install metacity”, then run in a terminal “metacity –replace” and you’ll get faster windows moving around.
@Nobody of Import
Usually Gigabit Ethernet is about 1.5 to 2 times faster than Fast Ethernet for copying a large file from a SAMBA share to the internal storage in Android TV boxes. If instead I copy files to a USB drive, I can get up to around 25 MB/s transfer rates with GbE + USB 2.0, or about 3 times faster than Fast Ethernet (~8MB/s in best case).
I would still never recommend Allwinner for a media player that will be decoding video. At least not until Allwinner gets their act together and start make libraires compatible with GPL.
Hello!
How are you?
I have opi pc plus with armbian ubuntu xenial. I want to use it as pc station / thin client. I need to run youtube videos. I tried by firefox and chromium but it rund without good quality. I tried to install kodi but it does not run, give only errors. Please! How do you make run vídeos from opi? Thank you atrenton and help.
@Douglas G. Oechsler
Playing videos in a web browser will be a struggle.
Kodi might have worked, but Android might be a good option.
To play YouTube videos in Linux, you may
1. Download the videos with a script before playing them: http://www.cnx-software.com/2016/09/20/how-to-download-youtube-4k-videos-with-youtube-dl-script/
2. Try to play them from SMPlayer. See demo with Orange Pi mini 2 board @ http://www.cnx-software.com/2015/09/02/debian-8-on-orange-pi-mini-2-board-video/
Where can one get a copy of es2gears specifically for the OrangePiOne? I can’t find it in the apt tree and googling for it doesn’t seem to turn up much.
@Charles Lohr
It’s normally part of mesa-utils-extra package:
I inquiring to bout to become IPTV provider what are the term and conditions for