Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Reputation Activity

  1. Like
    tkaiser got a reaction from Arglebargle in RockPro64   
    For testing purposes I always just grab a bionic or stretch minimal image from ayufan, then look for latest mainline kernel available and install it:
    apt-cache search kernel | grep -- '-4\.1' apt install linux-image-4.18.0-rc5-1048-ayufan-g69e417fe38cf reboot Mainline kernel was a requirement to use PCIe in the past but according to release notes that might have changed recently (by disabling SDIO). So you might want to test with both 4.4 and mainline...
     
    Edit: Don't forget to always check /proc/interrupts for the PCIe related IRQs and assign them to one of the big cores.
  2. Like
    tkaiser reacted to NicoD in Benchmarking CPUs   
    I'm currently downloading the rpi-stretch from 13/03/2018. Release date of the 3B+.
    I'll do the same on that. We'll be able to compare those.
    I'll keep posting my results.
    I found the bad 2.5A very interesting. Also my 2A PSU did very well. So I can show it isn't the amperage but the voltage that's important. Everyone always says, buy a 2.5A or 3A...
    Thanks for all the info. I'm learning every minute. Cheers.
    ps. Check above post for more results. I'll keep it all there to save room on this thread. RPi 3B now comming.
     
    @tkaiser
    Check the 3B no fan vs 3B+ no fan. The 3B outperforms the 3B+ until it overheats to +80°C.
  3. Like
    tkaiser reacted to NicoD in Benchmarking CPUs   
    Ok. I'm on it. Now doing the Rasp 3B+ with the new script and no cooling. After that I'll do the same with a crappy psu.

    Indeed on some I use old distro's. I'll do it again with newer ones. I also have got Tinker Board, BPi M2-Zero, OPi +2, ... that I'll do too. It'll take me some time.  Cheers
  4. Like
    tkaiser got a reaction from NicoD in sbc-bench   
    @malvcr or @chwe: are you able to provide 'sbc-bench neon' output for BPi R2?
     
    Anyone here with a RPi 3 B+ able to run 'sbc-bench neon' with this board one time allowing for throttling (pretty easy since operation without fan should be sufficient) and one time allowing for undervoltage/frequency capping (using any crappy Micro USB cable combined with a 2A USB wall wart)? @NicoD maybe?
     
    A screenshot from a putty session showing the output would be great...
  5. Like
    tkaiser reacted to Arglebargle in RockPro64   
    Thanks! Pcie seems to be working fine on the most recent 4.4 kernel, the Intel nic I tested linked at 5GT 4x without issue.
     
    root@rockpro64:~# uname -a Linux rockpro64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux  
    LnkSta: Speed 5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-  
  6. Like
    tkaiser got a reaction from NicoD in Benchmarking CPUs   
    Please https://pastebin.com/raw/CXtt28y1 instead and no need for dos2unix since this can simply be achieved by stripping out the CR characters ('\015') as shown above using tr.
     
    Vim2 will be very interesting since strange things happen there. Really curious about the results. NanoPC T4 results are above (but with conservative settings limiting CPU cores to 1.8/1.4GHz instead of 2.0/1.5GHz we'll use later) and NanoPC-T3+ will be more or less the same as NanoPi Fire3 since same SoC but different amount (and maybe type) of DRAM. And yeah, XU4 is also interesting.
  7. Like
    tkaiser got a reaction from NicoD in Benchmarking CPUs   
    To sell more of these devices making nice profits? The average RPi user is pretty clueless so all that's needed to sell a new 'incremental update' is mentioning that it's faster. In fact the 3 B+ was a little bit faster for some months (1.4 GHz vs. 1.2 GHz and way better PCB design plus heatspreader resulted in higher sustained performance). Now that all the benchmarks are published they silently reverted the higher performance since everything demanding that would need the 1.4 GHz will now trigger the 60°C throttling treshold easily.
     
    But hey, RPi users won't realize since /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq shows only bogus numbers. Same when undervoltage occurs. In such a situation (input voltage dropping below 4.65V which happens very very very often with Raspberries not using their 'special PSU' but standard Micro USB gear) the ARM cores are immediately downclocked to 600 MHz while /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq happily lies about 1400 MHz on the 3 B+ or 1200 MHz on the 3 B.
     
    BTW: The VC4 is a 2010 design and nothing except exchanged ARM cores has changed. They have nothing else. If they would switch to a new SoC backwards compatibility wouldn't exist any more. I wouldn't be surprised if we see 2019 a last incremental update (then using an eMMC socket, implementing SDR104 mode for faster SD card access and Wi-Fi with 2x2 MIMO and real antennas) and in 2020 they're simply telling 'game over'.
  8. Like
    tkaiser got a reaction from NicoD in Benchmarking CPUs   
    First attempt on sbc-bench.sh (I'll put this later on Github)
     
    In case you still have the RPi 3B+ around it would be really great if you could let the script run without a fan (I need the throttling situation to see whether everything is reported well). The script is designed to work on normal ARM SBC as well as on the crippled Raspberries (VideoCore main CPU controlling the hardware and all the proprietary TheadX stuff). Basic requirement is either Debian Stretch or Ubuntu Bionic (or something similar with somewhat recent packages)
     
    Output from a RPi 2 with Raspbian Stretch I had access to:
    root@raspberrypi:/home/pi# /usr/local/bin/sbc-bench.sh Installing needed tools. This may take some time... Done. Executing tinymembench. This will take a long time... Done. Executing 7-zip benchmark. This will take a long time... Done. Executing OpenSSL benchmark. This will take a long time... Done. Below benchmark results: Memory performance: memcpy: 1013.7 MB/s memset: 1167.9 MB/s 7-zip total scores (three runs): 2134,2129,2125 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 14216.59k 19191.70k 21097.90k 21513.56k 21793.45k 21785.26k aes-128-cbc 14147.59k 19138.28k 21094.49k 21632.68k 21673.30k 21796.18k aes-192-cbc 12802.24k 16565.27k 18059.09k 18446.34k 18352.81k 18568.53k aes-192-cbc 12807.21k 16660.76k 17955.16k 18443.61k 18557.61k 18459.31k aes-256-cbc 11806.24k 14964.78k 16007.42k 16251.22k 16460.46k 16465.92k aes-256-cbc 11738.95k 14962.37k 16062.21k 16279.21k 16455.00k 16460.46k Full results uploaded to http://ix.io/1irc. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL.  
    Output from a heavily throttled NanoPC-T4 with some preliminary Armbian I built few weeks ago:
    root@nanopct4:/tmp# /usr/local/bin/sbc-bench.sh Installing needed tools. This may take some time... Done. Executing tinymembench. This will take a long time... Done. Executing 7-zip benchmark. This will take a long time... Done. Executing OpenSSL benchmark. This will take a long time... Done. ATTENTION: Throttling occured on CPU cluster 4. Check the uploaded log for details. Below benchmark results: Memory performance (on big.LITTLE systems measured individually): memcpy: 2060.7 MB/s (0.3%) memset: 8440.3 MB/s (0.6%) memcpy: 4000.9 MB/s (0.6%) memset: 9011.0 MB/s (0.7%) 7-zip total scores (three runs): 4496,3980,3837 OpenSSL results (on big.LITTLE systems measured individually): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 91970.98k 292346.01k 630755.93k 914955.95k 1053515.78k 1065336.83k aes-128-cbc 272534.69k 638176.02k 956555.26k 1068235.78k 1137390.93k 1144930.30k aes-192-cbc 92993.86k 274024.58k 532484.78k 715422.38k 794593.96k 797059.75k aes-192-cbc 260573.74k 581688.00k 797185.54k 940168.87k 982846.12k 981581.82k aes-256-cbc 90710.94k 257319.98k 466747.22k 601770.33k 656547.84k 654611.80k aes-256-cbc 235117.07k 531296.70k 735206.31k 807839.74k 850635.43k 852792.66k Full results uploaded to http://ix.io/1irf. Please check the log for anomalies (e.g. swapping or throttling happenend) and otherwise share this URL.  
     
    To let it run it's as easy as:
    wget -O /usr/local/bin/sbc-bench.sh https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh chmod 755 /usr/local/bin/sbc-bench.sh sudo /usr/local/bin/sbc-bench.sh (unfortunately needs root privileges to manipulate cpufreq governor and access monitoring data)
  9. Like
    tkaiser got a reaction from NicoD in Benchmarking CPUs   
    LOL, the Moronix Test Suite: https://forum.pine64.org/showthread.php?tid=389&pid=3259#pid3259
     
     
    Unixbench: http://www.brendangregg.com/blog/2014-05-02/compilers-love-messing-with-benchmarks.html
    Bonnie: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html
     
    And so on... all those tools usually recommended are popular since they're easy to execute, do not care about correct benchmarking but people are happy with numbers without meaning. Good luck...
  10. Like
    tkaiser reacted to NicoD in Benchmarking CPUs   
    I was using a fan + heatsink on the Bpi zero and rpi 3b.
     
     
    I've just done the 7-zip bench in Raspbian Lite, now installing the desktop to compare. After that I'll to the same with ubuntu and with the rpi 3b+. I'll add all the numbers to this post.
    Here's the Raspbian Lite results of the Rpi 3B
    rpi 3b Raspbian Lite result 1st time Avr : 329 563 1853 | 393 1208 4746 Tot: 361 886 3300 2nd time Avr : 328 564 1851 | 393 1210 4752 Tot : 360 887 3301 3th and 4th times almost the same as 1st and 2nd Results Raspbian Desktop Rpi 3b
    pi@RPI3B:~ $ 7zr b ; 7zr b 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 949 1197 1198 1196 1198 1198 1198 1199 1198 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1793 317 550 1745 | 56845 394 1231 4850 23: 1759 323 555 1792 | 55419 394 1218 4795 24: 1733 329 566 1863 | 54065 394 1205 4746 25: 1280 252 580 1462 | 50155 384 1162 4464 ---------------------------------- | ------------------------------ Avr: 305 563 1716 | 391 1204 4714 Tot: 348 883 3215 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 801 1089 1126 1059 1167 1184 1186 1186 1186 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1785 316 550 1736 | 56654 392 1232 4834 23: 1757 322 556 1791 | 55426 394 1219 4796 24: 1737 329 568 1868 | 53818 392 1205 4724 25: 1710 337 579 1953 | 51503 387 1184 4584 ---------------------------------- | ------------------------------ Avr: 326 563 1837 | 391 1210 4734 Tot: 359 887 3286 Desktop is a little bit slower.
     
    Raspberry Pi 3b+ Raspbian Lite
     
    rpi 3b+ Raspbian Lite result 1st Avr : 336 610 2051 | 390 1381 5388 Tot : 363 996 3720 2nd Avr : 329 608 2000 | 390 1382 5394 Tot : 360 995 3697 Raspberry Pi 3b+ Raspbian Desktop
    i@raspberrypi:~ $ 7zr b ; 7zr b 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 753 1393 1393 1393 1393 1393 1393 1392 1388 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1915 314 594 1863 | 64588 391 1410 5510 23: 1893 322 599 1930 | 62188 388 1388 5381 24: 1889 332 612 2032 | 60452 388 1368 5307 25: 1508 277 621 1722 | 57029 386 1313 5075 ---------------------------------- | ------------------------------ Avr: 311 607 1887 | 388 1370 5318 Tot: 350 988 3603 7-Zip (a) [32] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,32 bits,4 CPUs LE) LE CPU Freq: 922 1317 1270 1178 1279 1299 1341 1349 1346 RAM size: 911 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1978 325 592 1925 | 63685 387 1404 5433 23: 1977 335 602 2015 | 62343 389 1387 5394 24: 1888 332 611 2031 | 61095 390 1374 5363 25: 1891 350 617 2160 | 56111 375 1333 4994 ---------------------------------- | ------------------------------ Avr: 335 606 2032 | 385 1374 5296 Tot: 360 990 3664 08:33:52: 39.7'C 600/ 600 MHz 0000000000000000000 1.2V 08:33:58: 41.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:03: 44.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:08: 47.8'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:13: 47.2'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:18: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:23: 48.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:28: 48.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:33: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:39: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V Time Temp CPU fake/real Health state Vcore 08:34:44: 48.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:49: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:54: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:34:59: 49.4'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:04: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:10: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:30: 47.2'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:35: 48.3'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:40: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:45: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:50: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:35:56: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:01: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:06: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:11: 51.0'C 1400/1400 MHz 0000000000000000000 1.3250V Time Temp CPU fake/real Health state Vcore 08:36:16: 49.9'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:21: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:26: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:31: 51.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:37: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:42: 50.5'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:47: 51.0'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:53: 52.1'C 1400/1400 MHz 0000000000000000000 1.3250V 08:36:58: 46.2'C 600/ 600 MHz 0000000000000000000 1.2V @tkaiser
    Again a little slower than Lite. In the afternoon I'll check Ubuntu.
    More to come. Cheers
     
  11. Like
    tkaiser got a reaction from valant in Package list error due to filesystem corruption   
    As expected. Personally not experienced with any RK3328 device (since never attached displays to them) but with older Allwinner SoCs I measured a ~5°C difference with HDMI active or not.
     
    It's just as adding a GPU to a PC: Wastes more energy and generates more heat. With SoCs it's more IP blocks active and HDMI PHY inside the SoC so more or less as expected (or an indication for a driver doing things correctly: detecting a display and if none present disabling stuff that's not needed)
  12. Like
    tkaiser got a reaction from gounthar in What would you choose to record and broadcast video?   
    Just a quick snippet below. The 'video surveillance' use case is the only one where we still use Raspberries. The encoding job is done on the proprietary VideoCore IV VPU, raspivid gets the raw h.264 stream, sends it through the network with netcat (lowest latency) and on some Armbian box the streams are received via netcat and then both recorded to disk and 'transcoded' via VLC so that they can be viewed by any RTP capable client (VLC for example):
    # sender raspivid -b 4000000 -t 3600000 -fps 30 -w 960 -h 540 -br 55 -co 25 -sh 25 -o - | nc -k -l 2222 # receiver (needs /bin/zsh) setopt MULTIOS nc 192.168.2.108 2222 >/sata/camera/test-3.h264 | cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/camera1/}' :demux=h264 The slowest devices Armbian supports (Allwinner A20 boards) can cope with up to 8 or 9 streams at the same time.
  13. Like
    tkaiser got a reaction from valant in Package list error due to filesystem corruption   
    If 'armbianmonitor -v' reports corrupted packages then something went already horribly wrong and usually there's no easy way to recover from this other than starting from scratch. Seriously: if you have corrupted packages what should be the result if any other software calls such a corrupted library? It will just cause more and more harm.
  14. Like
    tkaiser reacted to chwe in Benchmarking CPUs (not yet a research article)   
    To late...   I think it makes more sense to split it yet otherwise it will be a hard nut to distinguish between what should be part of the research article and what's the left over from the original thread (this splitting often leads in headache for the one who has to do it). Feel free to change the title as soon as you think it's ready.  
  15. Like
    tkaiser reacted to wtarreau in Benchmarking CPUs (not yet a research article)   
    Please note that the operating points is usually fed via the DT while the operating frequency is defined by the jumpers on the board. It's very possible that the DT doesn't reference the correct frequencies here. From what I've apparently seen till now, the Armada 38x has limited ability to do frequency scaling, something like full speed or half speed possibly. When I was running mine at 1.6 GHz, I remember seeing only 1600 or 800 being effectively used. I didn't check since I upgraded to 2 GHz (well 1.992 to be precise) but I suspect I'm now doing either 2000 or 1000 and nothing else. Thus if you have a smaller number of operating points it would be possible that they are incorrectly mapped. Just my two cents :-)
  16. Like
    tkaiser got a reaction from TonyMac32 in Benchmarking CPUs (not yet a research article)   
    So now a quick overview of the relevant SoC families with Armbian -- results in 7-zip-MIPS:
    A20 @ 912 MHz: ~900 A64 @ 1152 MHz: ~2550 H3 @ 1100 MHz: ~2100 H5 @ 816 MHz: ~2200 H6 @ 912 MHz: ~2550 i.MX6 @ 1000 MHz: ~2100 RK3288 @ 1800 MHz: ~5400 RK3328 @ 1392 MHz: ~3600 S5P6818 @ 1400 MHz: ~7200 S905 @ 1500 MHz: ~3700 (for A20, H3, H5, H6, RK3328 and S5P6818 results see above, for A64 see here and there, for i.MX6 see here (search for my Wandboard), for RK3288 see MiQi results here and for S905 see ODROID-C2 numbers there)
     
    All the SoCs above are quad-core except A20 (dual) and S5P6818 (octa). And it's all about the type of CPU cores: A20 and H3 are Cortex-A7, A64/H5/H6/RK3328/S5P6818/S905 are Cortex-A53, i.MX6 is Cortex-A9 and RK3288 is Cortex-A17. So let's look at all the results, take count of cores into account and MHz also. The following is a table of 7-zip-MIPS per single core at 1GHz clockspeed:
    A7: 475 A9: 525 A53: 625 A15: 700 A17: 750 A72: 850 (yeah, A15 and A72 also exist -- see below).
     
    So that's roughly what you can expect from each individual Cortex core running at 1 GHz. As expected if a SoC contains more cores specific workloads that benefit from parallel code execution get faster (once again: most workloads are single-threaded!). Also as expected clockspeeds matter: if you buy an H3 or H5 board without voltage regulation limiting the maximum clockspeed then obviously this board will perform slower compared to another H3/H5 board with sophisticated voltage regulation allowing the CPU cores to clock much higher.
     
    What also matters with this benchmark and most if not all real world workloads: memory bandwidth. Boards with just a 16-bit memory interface are slower than those with 32- or even 64-bit memory interfaces (something that the incapable sysbench pseudo cpu test is not able to report since whole execution happens inside the CPU cores). Boards that use 'better' DRAM (DDR4 vs DDR3) can be faster as long as available software/settings are available (and that's often not the case -- for example we're still waiting for Rockchip releasing new BLOBs with faster DRAM initialization for (L)PPDR4 equipped Rockchip boards).
     
    Speaking about software/settings it should also be obvious that in the meantime we always also have to take care about heat dissipation of ARM SoCs used today. Heat dissipation is an issue to prevent damaging the SoCs due to overheating under load. But without fully functioning cpufreq/dvfs/thermal drivers we can not allow the CPU cores to clock at their upper limits since we need working throttling to protect the chips. And that's why the results for Allwinner H5 and H6 boards look that bad: since linux-sunxi community still is working on upstreaming driver support and/or we at Armbian have not incorporated latest patches flying around into the build system. Once cpufreq/dvfs/thermal is ready for those newer Allwinner SoCs H5 boards will get 1.5 as fast and H6 boards almost twice as fast as today.
     
    Software/settings matter. Always. That's why it's so disappointing to see all those benchmark numbers flying around not taking this into account.
     
    What about Cortex-A15 and A72? When we look at boards Armbian supports we find those cores in SoCs implementing big.LITTLE: ODROID XU4/HC1/HC2 use Exynos 5442 which consists of 4 fast A15 and 4 slow A7 cores (32-bit ARMv7). Boards based on RK3399 have 2 fast A72 cores and 4 slow A53 cores (64-bit ARMv8)
     
    Does it make sense to run the very same 7-zip benchmark on those big.LITTLE designs? Not that much since we can not easily draw any conclusion for normal workloads from such a benchmark number. For example when executing '7z b' on all 6 cores of an ODROID-N1 at the same time we get an overall score of ~6550 7-zip MIPS. When limiting benchmark execution to only the 2 fast A72 cores at 2 GHz we get ~3350 (that's ~1700 7-zip MIPS per core), when we execute the benchmark on the 4 little cores only (1.5GHz) then it's ~3900 (~975 7-zip MIPS per core). A single threaded task running on one of the two big cores will perform almost twice as fast compared to running on a little core. That's important to keep in mind since based on the workload running in reality some of the benchmark numbers are simply misleading or just... numbers without meaning.
     
    Same with ODROID-XU4/HC1/HC2: when running on the A15 big cores ~4950 7-zip MIPS are reported at around 1.8GHz (~1250 7-zip MIPS per big core), when running only on the little A7 cores at 1.4 GHz it's ~2725 (~675 per core). Same situation as with RK3399: single threaded stuff moved to the big cores performs almost twice as fast as on the little cores. I never measured 7-zip running on all cores together since 'numbers without meaning' but I would assume we get something similar as with RK3399: not the addition of big+little numbers (3350+3900=7250 vs. 6550 in reality) but something lower since all cores have to fight for memory bandwidth.
     
    Other things to keep in mind:
    When looking at the above benchmark numbers we see A53 cores performing with this specific benchmark 30% better compared to A7 cores at the same clockspeed (so there's a slight advantage ARMv8/64-bit has over ARMv7/32-bit). But as soon as we use other software/benchmarks that make heavy use of NEON optimizations we usually see a performance increase much higher (A53 usually performing twice as fast as A7 -- can be easily checked with cpuminer). So as always it depends on the use case. Speaking of 'use case' we should also keep in mind that all those ARM SoCs have special engines for this and that. Almost all ARMv8/64-bit SoCs for example contain a cryptographic acceleration engine called 'ARMv8 Crypto Extensions' that make a massive difference with AES for example compared to 32-bit/ARMv7 SoCs that have to do crypto stuff on the CPU cores (see here for numbers). So again: it's about the use case: if you're interested in VPN stuff or disk encryption looking at generic CPU benchmarks is BS since you want an ARMv8 SoC with crypto support (almost all have, the only exceptions are RPi 3/3+, ODROID-C2 and NanoPi K2) CPU performance with many use cases isn't that important. With Marvell based boards (EspressoBin, Clearfogs, Helios4) CPU benchmarks look rather low but these SoCs are designed for highest I/O and networking throughput and even if the SoC in question scores low in CPU benchmarks those boards outperform everything else if it's about fast storage and network  
  17. Like
    tkaiser got a reaction from valant in Package list error due to filesystem corruption   
    Ah, ok. You were really running the 'armbianmonitor -c' check testing for data integrity (I thought about a fsck first). Yeah, then the SD card is at fault and corrupting data.
  18. Like
    tkaiser got a reaction from valant in Package list error due to filesystem corruption   
    Instead of following stupid networkmanager bashing you might better focus on reality. What you obviously experience is filesystem corruption and quite normal with SBC (result of broken/counterfeit SD cards). In such a situation a filesystem check would be a good idea as well as some integrity checking (of packages and the entire SD card surface):
    sudo armbianmonitor -v armbianmonitor -c $HOME
  19. Like
    tkaiser got a reaction from devman in Benchmarking CPUs (not yet a research article)   
    NanoPi Fire3 with Samsung/Nexell S5P6818 which is an octa-core A53 clocked by default with 1.4 GHz (results irrelevant):
     
    Why are results irrelevant? For two reasons:
    Throttling occured. The board with vendor's standard heatsink starts to overheat badly when running demanding loads. Active cooling is needed and that's why monitoring when running benchmarks is that important! This is an octa-core Cortex-A53 SoC showing with this benchmark a score of well above 7000 when no throttling happens. Once again: such multithreaded results are BS wrt most real world workloads. An RK3399 board like an ODROID-N1 scoring 'just' 6500 will be the faster performing board with almost all usual workloads since equipped with 2 fast A72 cores while the Fire3 only has 8 slow A53 cores. Most workloads do not scale linearly with count of CPU cores. This has to be taken into account.
  20. Like
    tkaiser got a reaction from TonyMac32 in Benchmarking CPUs (not yet a research article)   
    NanoPi Fire3 with Samsung/Nexell S5P6818 which is an octa-core A53 clocked by default with 1.4 GHz (results irrelevant):
     
    Why are results irrelevant? For two reasons:
    Throttling occured. The board with vendor's standard heatsink starts to overheat badly when running demanding loads. Active cooling is needed and that's why monitoring when running benchmarks is that important! This is an octa-core Cortex-A53 SoC showing with this benchmark a score of well above 7000 when no throttling happens. Once again: such multithreaded results are BS wrt most real world workloads. An RK3399 board like an ODROID-N1 scoring 'just' 6500 will be the faster performing board with almost all usual workloads since equipped with 2 fast A72 cores while the Fire3 only has 8 slow A53 cores. Most workloads do not scale linearly with count of CPU cores. This has to be taken into account.
  21. Like
    tkaiser got a reaction from guidol in Benchmarking CPUs (not yet a research article)   
    NanoPi Fire3 with Samsung/Nexell S5P6818 which is an octa-core A53 clocked by default with 1.4 GHz (results irrelevant):
     
    Why are results irrelevant? For two reasons:
    Throttling occured. The board with vendor's standard heatsink starts to overheat badly when running demanding loads. Active cooling is needed and that's why monitoring when running benchmarks is that important! This is an octa-core Cortex-A53 SoC showing with this benchmark a score of well above 7000 when no throttling happens. Once again: such multithreaded results are BS wrt most real world workloads. An RK3399 board like an ODROID-N1 scoring 'just' 6500 will be the faster performing board with almost all usual workloads since equipped with 2 fast A72 cores while the Fire3 only has 8 slow A53 cores. Most workloads do not scale linearly with count of CPU cores. This has to be taken into account.
  22. Like
    tkaiser got a reaction from gounthar in Is your SD-Card a fake? - check with SD Insight Android App   
    Why do you think so? Most probably it's just a fake card with Kingston printed on the surface and copied flash metadata from a Toshiba card. Kingston was pretty popular amongst fraudsters some time ago: https://www.bunniestudios.com/blog/?page_id=1022
     
    Also how should such an app help detecting fake flash that simply reads out some (faked) metadata, looks up in a database and then displays $something? Fake cards use faked metadata. It's pointless to trust in this metadata at all (see my above link).
     
    My personal take on avoiding faked flash:
    Only buy A1 rated cards any more (since for the 'SBC use case' buying anything else is just a mistake) Immediately after purchase check them with either F3 or h2testw. This test will not identify modern fakes who do not fake capacity any more but use real capacity but are made out of inferior components compared to genuine cards After flashing an Armbian image with Etcher the first thing to test is 'iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2' Why? Since fake cards suck wrt especially random IO performance. The result of such an iozone test might look like this:
    root@rock64:~# iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Thu Jul 19 12:36:21 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 1272 1303 7799 7865 6380 140 102400 16384 9837 9640 15924 14124 15921 8077  
    The 4k number for random writes (here 140) must exceed 2000 since A1 specs require at least 500 IOPS with 4k block size, iozone reports KB/s and with 4K that means we need to multiply 500 IOPS with 4K to get at least 2000 KB/s displayed. So if iozone reports anything below 2000 here I immediately ask the seller for return/refund since the card sold is not compliant to A1 performance class. Of course it's important to buy SD cards only from sellers who have a 'no questions asked' return/refund policy.
  23. Like
    tkaiser reacted to Larry Bank in Testing NanoPi NEO Core for gaming potential   
    Update: Everything working now. These issues are resolved:
     
    1) Constant hangs were due to the cheap wifi adapter. It would hang the ssh session after 5-10 minutes of use. Switched to a better one and it now works reliably
    2) GPIO didn't behave the same as other systems. I had to add lseek(handle, 0, SEEK_SET) before each read from a GPIO pin. I should have done it earlier, but other machines seem to work without needing that
    3) Now I need to solder a 3.5mm socket onto the analog audio out to hear the output...
     
    Here's a video of it in action:
     
    https://photos.app.goo.gl/zLZS3Pw3iABCXVkK9
     
  24. Like
    tkaiser reacted to Larry Bank in Testing NanoPi NEO Core for gaming potential   
    Today's project is trying to get my game emulator to run on the NanoPi NEO Core board. Lots of exposed I/O, but I'm getting random hangs and some odd behavior with the latest Armbian. In the photo is a ILI9342 (landscape version) 2.3" display and some ugly protoboards I created to allow reliable wiring + sockets for the Core board. I just updated my SPI_LCD project to include support for both the ILI9342 and the Core board's strange header: https://github.com/bitbank2/SPI_LCD
     
    I had to wire the USB-A socket to the header because the OTG port is not properly enabled (in the available Armbian build). If I spent some time messing with it, there's probably a bunch of patches to get it working, but soldering 4 wires seemed like the quicker fix for me.
     
    I'll keep you posted on my progress (if anyone is interested)
     
     

  25. Like
    tkaiser got a reaction from 5kft in Nanopi NEO2 CPU frequency issue   
    Just had a quick look: https://github.com/friendlyarm/u-boot/commits/5532d5e641a990595156e83952049dd34cf838c0/common/board_r.c ?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines