KY69 reacted to NicoD in 32-core 3.3Ghz ARM Server Review
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.
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.
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
KY69 reacted to SteeMan in Armbian for Amlogic S905X3
Technically Balbes never supported the s905x3. But it is true that he is now ending support of all amlogic cpus. I already make my own kernel builds, and since I own a few different amlogic based boxes, I have an interest in seeing support continue in some form. I have asked balbes in another thread if he would tag his public github repositories with a tag that corresponds to his last build supporting amlogic, which then can be a starting point for continued support by the community if there is enough interest.
KY69 reacted to skyfly555 in Armbian for Amlogic S9xxx kernel 5.x
I totally agree with @balbes150.
In my opinion, what he's doing is absolutely great.
Maybe it's easy to forget @balbes150 is doing this for free, and maybe we don't know how many hours he's spending on doing this (I bet some of them, everyday).
Thank you, Mr. @balbes150: I think you should be paid by ATVs manufacturers, because, thanks to your work, and only in my case, they have sold 3 Amlogic ATVs (to me); and I had never bought them because of Android: It's your Armbian, the reason
To be sincere, I'm happier with my ATV boxes, running @balbes150 Armbian, than I am with my Raspberrys, covered by tons of dust in this very moment.
KY69 reacted to mb16 in Armbian for TV box rk3328
Glad to read I seem to have created something useful.
My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.
Used adb to read the device tree directory from the box running android. Converted to android.dts file using dtc. For armbian used the ...box.dtb because the device could boot using that one. Converted dtb to dts using the "sorted" option of dtc for comparison (a). Converted dtb to dts without the "sorted" option for optimization (b). Used a merge utility (meld) to compare (a) against android.dts Put the found differences into (b), used dtc to compile. Too easy
Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files
and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.
I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.
Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.
Reading things like ... "did not work... suddenly did... then stopped to work again...":
This can mean pin settings (called pad nowadays, ok) might be wrong.
Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.
Regarding dram settings
These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.
Regarding the wifi chip
The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection.
It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.
KY69 got a reaction from manuti in Armbian for TV box rk3328
It probably already works for the box you linked, but if I may suggest, this one already works for sure, it costs just a few dollars more (4/16 model), and has twice the amount of RAM. I wouldn't think twice:
KY69 reacted to ab1jx in Terrible Synaptic performance
That problem was cured by not keeping the package info in compressed form as far as I'm concerned. You have to change something in a config file then delete the lists and apt-get update again. It's 10-20 times as fast now.
If you have to live without Synaptic try apt search.
KY69 got a reaction from Xiaofan in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)
I remember I had similar problems a few months ago when I tried installing Armbian on my TX3 mini for the first time. I did some tests back then and if I recall correctly mounting any Linux partition (extX) on Android seemed to be changing the file system to use SElinux permissions, which prevented Armbian from even reaching the first login prompt. I had the same problem even after having everything running and simply mounting the SD card or HDD on Android, it simply messed everything up, and changing all permissions back was time consuming, so I simply do NOT mount any linux filesystem when running Android on the box. Actually I never even boot Android, I bought the box specifically to run Armbian, sadly I haven't had time to play with it for over a month now.
But the symptom was as you described, I prepared the SD card, updated the box to multiboot (via Android, so it mounted the linux filesystem on the SD card and messed it up right there), and no matter what dtb file I used it would halt somewhere like what you showed. After rewriting the SD card and not mounting it on Android (I already had multiboot), Armbian booted out of the box, but it took me some time to figure that out. After I had the system working I booted Android and inserted the SD card, and I was again not able to fully boot Armbian due to SElinux permissions on certain system files (actually all over the filesystem, but fixing the permissions to a few system files made the system bootable again. Afterwards I still had to fix the whole filesystem nonetheless). I tried a few things after I had the system running from an HDD, and simply mounting this HDD on Android was enough to "update" the file permissions and make Armbian unbootable again. In summary, at least with my TX3 mini, I cannot mount any media with Armbian partitions on Android. I believe my box has Android 7.1 from March/2018.
In fewer words, your problem is probably not with the Android Update app, but with Android itself whenever it mounts the extX partition(s). Hope this helps somehow.