piter75

  • Content Count

    214
  • Joined

  • Last visited

Reputation Activity

  1. Like
    piter75 reacted to JMCC in AMD Threadripper 3990X Armbian Build Server Review   
    Okay, another use case. This one will bring some surprises.
     
    Let us imagine we want to compile natively armhf/arm64 binaries. Like, for example, making the new Armbian multimedia packages that we will announce very soon
     
    In this case, the Threadripper will be in clear disadvantage, since it needs to virtualize the ARM CPU through Qemu. But, will it be able to make up with core count and sheer processing power? Here are the numbers. We will compare the Threadripper with the Ampere ARM server, and with my highly optimized Odroid XU4 (good cooling and slight overclock).
     
    First, a single thread 7-zip bench (Decompressing MIPS, higher is better):
    $ 7z b -mmt1 Threadripper (native amd64): 4793 Threadripper (emulating armhf): 1529 Ampere ARM server (native armhf): 2889 Odroid XU4 (native armhf): 2160 As you can see, the single-core performance of the Threadripper is reduced to 1/3 of its natiive performance when emulating through Qemu, leaving it well below the Odroid XU4 and the Ampere.
     
    Now, a real-world use case: let us compile our customized version of Kodi for armhf (compilation time, lower is better):
    $ time cmake --build . -- -j$(nproc --all) Threadripper (emulating armhf): 18m9.696s Ampere (native armhf): 5m50.033s Odroid XU4 (native armhf): 45m50.711s The 32-core ARM server beats here the 64C/128T AMD server for more than three times shorter compile time. And Odroid XU4 gets just slightly above double the compile time of the AMD. If we factor in power consumption, it becomes very clear that compiling in an emulated environment is very suboptimal.
     
    Now, we must remember that for building Armbian images we don't emulate, but instead cross-compile. In that case, the AMD is working natively, and that is another story. In that case, the AMD has absolutely no match with the ARM server, or anything else I ever tested. We will probably post numbers about this in some other opportunity.
  2. Like
    piter75 got a reaction from TRS-80 in Rock Pi S won't boot with custom builds   
    I remember building the ROCK Pi S image a few day ago and it was working fine. I will build again to verify it.
     
    Refer to the output/debug/install.log to see if there are any errors during initramfs build.
  3. Like
    piter75 got a reaction from JMCC in Armbian v20.11 (Tamandua) Planning Thread   
    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.
  4. Like
    piter75 reacted to Igor in Armbian Donations   
    Assembled - first boot of Ubuntu 20.04 looks very very nice  But it was tense ... "what if it will not work?"
     
    Also NVME and SATA DOMs are recognized but 10Gb NIC. Which probably need more recent kernel ... and water cooling doesn't fit into the case. Currently mounted outside, which might even not be that bad.
     

  5. Like
    piter75 reacted to Werner in Forum adjustments   
    To strengthen the symbiosis between Kobol and Armbian a new dedicated club has been created for Kobol products with Armbian support. It will be maintained directly by Kobol associates @gprovost and @aprayoga.
    Check it out:
     
  6. Like
    piter75 reacted to Igor in Armbian Donations   
    2 x NVME arrived, memory tomorrow, CPU, cooling and 2x DOM ETA next week.


  7. Like
    piter75 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.
    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
  8. Like
    piter75 got a reaction from Pedro Lamas in NanoPi M4V2 randomly crashes   
    @aprayoga Fingers crossed!
    I remember playing with "regulator-ramp-delay" with M4V2 before (after noticing slow big cpu cluster transitions) but I probably did not got that high and definitely did not see that post you mentioned (and was not successful).
    I started some tests with 40000 right now.
     
    @Pedro Lamas if you want to also try testing it...
    Save below overlay into a file in your M4V2 (let's name it rump-delay-test.dts), run "sudo armbian-add-overlay rump-delay-test.dts" and reboot your M4V2.
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&vdd_cpu_b>; __overlay__ { regulator-ramp-delay = <40000>; }; }; };  
  9. Like
    piter75 got a reaction from Pedro Lamas in NanoPi M4V2 randomly crashes   
    Yes. They are treated as separate groups/clusters when it comes to scaling and they also have separate regulators assigned to them.
     
    cpufrequtils however cannot configure their limits separately - the same limits are applied to both clusters
     
  10. Like
    piter75 got a reaction from Dante4 in Rock Pi 4C only USB-OTG is working   
    We need to work a bit on our download page for ROCK Pi 4 boards as I see you used 4B images - and these are the only ones easily accessible on the download page  (CC: @Igor)
     
    For current use the images from here: https://dl.armbian.com/rockpi-4c/archive/ - all USB ports should work there.
    In legacy they will not work right now. I have it on my TODO list so it is possible that with the next point release all USB ports will work in legacy too.
  11. Like
    piter75 got a reaction from Werner in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    rtl8189fs was patched "upstream": https://github.com/jwrdegoede/rtl8189ES_linux/commit/0ba46e2434eec6f67d0712ed119a4ef8e05ccf91
     
    I removed rtl8189fs from our patches for rockchip64 yesterday and propagated the change to other families about an hour ago.
  12. Like
    piter75 got a reaction from Dunc4n1d4h0 in Armbian_20.08_Rockpro64_focal_current_5.7.15 no HDMI output after "starting kernel"   
    Log in with ssh, remove /etc/modprobe.d/blacklist-rockpro64.conf file and reboot. HDMI should work then.
    There is an issue with current v20.08 builds for some boards (including RockPro64) that crucial graphics modules are blacklisted - it will be fixed with next patch release.
  13. Like
    piter75 reacted to martinayotte in Switching ROCKCHIP64-DEV to 5.8.y   
    I've done an PinebookPro build with rockchip64-dev 5.8.y, it worked, I'm planning to do a rockchip64-dev garden tour, and if nothing special, commit those change for 5.8.y ...
  14. Like
    piter75 reacted to Igor in Help Test Upcoming Armbian v20.08 (Caple)!   
    My big test rig:
     
    32 devices IN
    https://dl.armbian.com/_test-reports/2020-08-04_21.44.52.html
     
    31 devices OUT
    Only Orange Pi Zero Plus 2 failed to respond after extreme testings ...
  15. Like
    piter75 got a reaction from baptiste in RockPro64 kernel v5.4 doesn't boot on eMMC (while kernel v4.4 does)   
    This is a known issue with rk3399 boards using mainline kernel and it was mitigated for all other boards using mainline u-boot some time ago.
    RockPro64 is the last one that is uses u-boot v2017.09 but I am planning to switch it to mainline for the next Armbian release (v20.11).
    For now you need to either be patient or stay with 4.4.y.
  16. Like
    piter75 got a reaction from NicoD in SOLVED: Nanopi M4V2 Focal Please help, I think I somehow removed my wlan0 interface   
    Run these two commands:
    sudo cp /lib/firmware/brcm/brcmfmac4356-sdio{-nanopi-m4v2,}.bin sudo cp /lib/firmware/brcm/brcmfmac4356-sdio{-nanopi-m4v2,}.txt Reboot and verify if your wlan0 interface is working.
  17. Like
    piter75 got a reaction from lanefu in SOLVED: Nanopi M4V2 Focal Please help, I think I somehow removed my wlan0 interface   
    This happens after upgrading armbian-firmware package and it is already fixed in master and will be part of v20.08 release.
  18. Like
    piter75 got a reaction from Werner in SOLVED: Nanopi M4V2 Focal Please help, I think I somehow removed my wlan0 interface   
    This happens after upgrading armbian-firmware package and it is already fixed in master and will be part of v20.08 release.
  19. Like
    piter75 got a reaction from JrRockeTer in SOLVED: Nanopi M4V2 Focal Please help, I think I somehow removed my wlan0 interface   
    This happens after upgrading armbian-firmware package and it is already fixed in master and will be part of v20.08 release.
  20. Like
    piter75 got a reaction from haajee in Orange Pi 4 Kernel 5.x.x rt5651 sound and bluetooth fixed   
    Did you change the mac address of the interface by using `btmgmt` according to this message?
    Without it the device is using default mac address from firmware and thus is set to `DOWN RAW` status.
     
  21. Like
    piter75 reacted to Kyra in Switch kernel from legacy (rk3399) to current (rockchip64) on NanoPi M4 V2   
    I advise sticking with the legacy kernel until the stability issues with the current kernels (specific to the NanoPi M4 V2) have been resolved.
  22. Like
    piter75 got a reaction from haajee in Orange Pi 4 Kernel 5.x.x rt5651 sound and bluetooth fixed   
    It is fixed for some time already. It's just that there were no releases built for the board in the meantime.
    It is however part of v20.05.1 - after you upgrade you should not see it disappearing again.
  23. Like
    piter75 got a reaction from Werner in kernel 5.4.43 Rock PI 4B not starting   
    u-boot does not recognise the storage and tries to boot from network.
    I see that you have built yourself an image yesterday but it is probably using some old Armbian build repository revision as it still uses v2017.09 u-boot which is switched to mainline for RockPi 4 in current sources.
     
    Did you also try to use the ready made v20.05.1 images from https://dl.armbian.com/rockpi-4b/archive/? Does it also get stuck with them?
     
    Please use Spoiler next time for boot log ;-)
  24. Like
    piter75 got a reaction from JrRockeTer in Nanopi-M4V2 won't booting from eMMC and does not see eMMC: SOLVED eMMC plugs in opposite way than original M4   
    You are right, eMMC modules are compatible with both M4 and M4V2.
    Do you install eMMC modules the right way? eMMC in M4V2 needs to be rotated 180º vs. the way it was installed in your M4.
  25. Like
    piter75 got a reaction from Dyfcom in Nanopi M4v2 - crash/freeze   
    There are some older threads where people noticed it too, myself included 
     
    Would you like to participate in testing of a possible cure workaround for those issues?
    Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 
    If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix
     
    I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful.