JMCC

So my whole goal with java-periphery was to create a decent cross platform userspace IO library which I believe I have achieved. One of my other goals was to create a high performance GPIO API that's also cross platform. If you look around there aren't any from what I can tell. Most high performance GPIO libraries support only a few boards. What I've done is use a well known interface (GPIO device) and some MMIO code to detect deltas and generate the required resisters and masks from an input file. This surely beats doing this by hand which I tried at first. The result is code that supports Allwinner H2+/H3 and H5/H6 by using just an input file. I'm going to look at other CPU types next, but this is promising. For more info check out High performance GPIO using MMIO.

I took a shortcut and enabled SPI by default for ROCK Pi 4.
I verified it with SPI CLK shorted on v1.4 but obviously it was not enough
The fix is in master.

Today I had the pleasure of benchmarking an ARM64 server.
This server has been made available for Armbian to test native ARM64 image building.
I knew nothing about the server. Nobody told me any details.
So everything was an adventure for me to find out. I got SSH access, so my research began.

A lscpu informed me it had 32-cores all clocked at 3.3Ghz. 
 
cat /proc/cpuinfo confirmed these 32-cores
 
Checking on what kernel we're on. Ubuntu Focal 5.4.0-52-generic. 
And how much memory. 128GB RAM.

So first thing I wanted to know, how does one core perform with 7-zip benchmark?
The record I had seen until now was from the A73 cores from the Odroid N2+ clocked at 2.4Ghz. 2504MIPS decompression.
So :
taskset -c 31 7z b
 
This beats the Odroid N2+ its A73 cores clocked at 2.4Ghz. 2763 vs 2504MIPS decompression. 
This also tells me these cores do not perform as good per clock as a high performance core. 
While doing the single core benchmark I checked the sensors to know the wattage and temperature.
 
CPU power is about 20W for a single core tasks. 
Without a load the CPU consumes between 10W-15W. So in total it consumes a bit more than 20W in idle.
Temperature never went under 49C even after +5 minutes in idle. 
 
Of course, the next thing to do is an all-core 7zip benchmark. 
This gives an amazing result. Way higher than anything I had ever seen on ARM.
 
85975MIPS decompression. This is amazing.
Best I had seen was 11000MIPS of the Odroid N2+. So this server does 8 x better than the N2+. 
Tho, I must say. 7zip does bad with unequal clusers. The N2+ has a great difference in cluster frequencies. So it performs worse then expected here. 

The wattage went a lot higher, up to 110W. And the temperature rose quickly up to 75C in seconds.
 
To test the internet connection I downloaded an Armbian image multiple times. Sometimes it was as low as 3MB/s. 
Highest average speed I've seen was 12.5MB/s
 
Next test. BMW Blender render benchmark. 
Here the fastest I had ever seen was by the Khadas VIM3. That did it in 42m51s.
I haven't done this yet with the N2+ in Armbian. In Odroid's Ubuntu it was a little slower. I expect it to be a little faster than the VIM3 in Armbian Bionic. 
This is a tile based test. So every core gets its own task, until all tiles are done. 

Well, this ARM64 server did this in 8m27s. 
5 x faster compared to the Khadas VIM3. 

For this the wattage didn't go over 85W. But the temperature did rise to 83C. So it started to throttle. 

@lanefu already had done SBC-Bench on it when it was free. So this I didn't have to do myself.
http://ix.io/2Dcc
Here we see a lot. For example the CPUMiner did : 81.0kH/s 
The Odroid N2+                                                         : 14 kH/s         5.7 x less 
RK3399 does a maximum of                                     : 10.23kH/s     8 x less
Odroid C2 clocked at 1.75Ghz                                   : 4.65kH/s       17 x less

So this server clearly can move a lot of bits around. 
Now, what is this server? Ask google if nobody else tells me. "32 core ARM server 3.3Ghz"
First answer : https://www.theregister.com/2018/09/18/ampere_shipping/
That looks like it is this CPU. But still I can't find the exact name. 
2nd answer : https://www.servethehome.com/ampere-32-core-64-bit-arm-chip-x-gene-3-ip/
So this is the Ampere 32-core 64-bit from X-Gene 3 IP.

Here the wikichip : https://en.wikichip.org/wiki/apm/x-gene/apm883832-x3?fbclid=IwAR0ljCQ61DY8Zwh_VyZd0fQH43dmPUTJA-CGLiQKYqU2fWwszFm1CPjH6Zo

This supports up to 1TB RAM. 8 channels @ 2666Mhz. With a maximum memory bandwidth of 158.95 GiB/s.
42 lanes of PCIe Gen 3, with 8 controllers
– x16 or two x8/x4
– x16 or two x8/x4
– x8 or two x4
– Two x1

4 x SATA Gen 3 ports, 2 x USB2. And a TDP of 125W TDP.

For me this is just an awesome thing to behold. I use ARM for almost everything.
The NanoPi M4V2 is my main desktop computer.
It isn't as powerful as my PC, but does the task for 10 x less power consumption, while being completely silent.

But when I need a big CPU, it isn't enough.
Even the more powerful Odroid N2+ isn't powerful enough to render long, +20minutes 1440p video's for example for my Youtube channel.
So then i need to use my x86/amd64 PC. 

Today I have seen and tasted the future. 
While this doesn't use the most modern Cortex/clusters. And it is only 16nm.
So there is still a lot of room for improvements in performance and lower power consumption. 

ARM for desktop is possible, and ARM servers for big datacenters is possible(AWS). I have seen the future, I loved every second of it. 

Here benchmarks compared to my SBCs

 

Greetings, NicoD

Excellent! Good luck with it.
 
However, I want to make some clarifications for people following the thread. As I said above, when I talk about transcoding, I am always thinking about HEVC sources, since h.264 sources don't need transcoding. XU4, therefore, will use SW to decode the HEVC, and HW to encode into h.264. That is how acceleration works.
 
As a matter of fact, if you force ffmpeg in command line to do both HW decoding and encoding (e.g., from h.264 to h.264 in XU4), it will have a negative impact on performance, versus using SW decoding and HW encoding. Again, we are always talking about the XU4 v4l2-m2m encoder, AFAIK the only ARM encoder currently supported by ffmpeg besides RPi.

Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.
 
You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.

Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.
 
You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.

TL;DR: Odroid XU4/HC1/MC1

Sorry, I didn't see this post before. I have a jellyfin server on a Odroid HC1, working like a charm since long ago. HW transcoding can do 1080p with no problem. I have special ffmpeg packages for Armbian buster, in case you want them.



Enviado desde mi moto g(6) plus mediante Tapatalk

Excellent! Good luck with it.
 
However, I want to make some clarifications for people following the thread. As I said above, when I talk about transcoding, I am always thinking about HEVC sources, since h.264 sources don't need transcoding. XU4, therefore, will use SW to decode the HEVC, and HW to encode into h.264. That is how acceleration works.
 
As a matter of fact, if you force ffmpeg in command line to do both HW decoding and encoding (e.g., from h.264 to h.264 in XU4), it will have a negative impact on performance, versus using SW decoding and HW encoding. Again, we are always talking about the XU4 v4l2-m2m encoder, AFAIK the only ARM encoder currently supported by ffmpeg besides RPi.

Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.
 
You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.

Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.
 
You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.

Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.
 
You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.

The solution is that it works with Kernel 4.9, it doesn't with 5.9. If you want that feature, then you can download the "legacy" version with the proper kernel: https://redirect.armbian.com/odroidn2/Buster_legacy.torrent

The only HW acceleration that is going to work among Armbian-supported boards is XU4. Besides that, it's Intel or RPi. Or, of course, SW transcoding.

Nice!
BTW, someone might have noticed my new "aggresive" signature. In case someone wants to use the same image, or modify it (change the color, etc.), it is available here: https://users.armbian.com/jmcc/images/

Nice!
BTW, someone might have noticed my new "aggresive" signature. In case someone wants to use the same image, or modify it (change the color, etc.), it is available here: https://users.armbian.com/jmcc/images/

Board is here 
 

Wait, you mentioned h264. You are aware that h264 normally doesn't need transcoding, right? The server just feeds the stream to the client, so the limit is set by your network connection and/or your storage device. You can stream many h264 streams of any resolution at once, even 4k.
 
Transcoding is only needed when the file is in a format that the client cannot handle natively. So, for example, if you are using Chrome browser as client, it cannot handle HEVC, and therefore it needs transcoding. But, if your client is Kodi with Jellyfin plugin, then you won't need transcode either for HEVC, since Kodi can handle it.
 
Since almost all clients support h264, it will normally not be transcoded. And, if you want, you can convert all your videos to h264, and then you can use any SBC as server, even with a weak CPU.

Yes, I use tvheadend with Jellyfin. So when I am watching a SD channel, which uses MPEG2-ts, it does transcoding.

Enviado desde mi moto g(6) plus mediante Tapatalk

Yes, I use tvheadend with Jellyfin. So when I am watching a SD channel, which uses MPEG2-ts, it does transcoding.

Enviado desde mi moto g(6) plus mediante Tapatalk

Wait, you mentioned h264. You are aware that h264 normally doesn't need transcoding, right? The server just feeds the stream to the client, so the limit is set by your network connection and/or your storage device. You can stream many h264 streams of any resolution at once, even 4k.
 
Transcoding is only needed when the file is in a format that the client cannot handle natively. So, for example, if you are using Chrome browser as client, it cannot handle HEVC, and therefore it needs transcoding. But, if your client is Kodi with Jellyfin plugin, then you won't need transcode either for HEVC, since Kodi can handle it.
 
Since almost all clients support h264, it will normally not be transcoded. And, if you want, you can convert all your videos to h264, and then you can use any SBC as server, even with a weak CPU.

The only Armbian-supported VPUs that can handle that are Rockchips. But there is no FFmpeg support for encoding, only Gstreamer. So no Jellyfin either.

You can try SW transcoding in a Odroid N2+, and see if it can cope with it. Otherwise, you must go for some Intel SBC, or probably RPi4.

Enviado desde mi moto g(6) plus mediante Tapatalk

Yep. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five simultaneous 480p (though it will depend on the bitrate of the source material). It may have trouble if you feed some HEVC 4k  material to it, particularly if it is 10-bit or high bitrate.

The only Armbian-supported VPUs that can handle that are Rockchips. But there is no FFmpeg support for encoding, only Gstreamer. So no Jellyfin either.

You can try SW transcoding in a Odroid N2+, and see if it can cope with it. Otherwise, you must go for some Intel SBC, or probably RPi4.

Enviado desde mi moto g(6) plus mediante Tapatalk

Yep. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five simultaneous 480p (though it will depend on the bitrate of the source material). It may have trouble if you feed some HEVC 4k  material to it, particularly if it is 10-bit or high bitrate.

TL;DR: Odroid XU4/HC1/MC1

Sorry, I didn't see this post before. I have a jellyfin server on a Odroid HC1, working like a charm since long ago. HW transcoding can do 1080p with no problem. I have special ffmpeg packages for Armbian buster, in case you want them.



Enviado desde mi moto g(6) plus mediante Tapatalk