• Content Count

  • Joined

Reputation Activity

  1. Like
    tkaiser got a reaction from Werner in Banana PI BPI-W2   
    Anyone interested in RTD1295/RTD1296 platform would need to do something like this first
    check out upstream mainline kernel at version 4.9.119 import changes from RealTek's kernel above (you then end up with one giant commit like this -- context) Now you can spend some days or weeks to have a look what's different, where security holes exist (remember Allwinner's 'rootmydevice'?) and what's not properly licensed If this step is skipped there exists no reason to trust into RealTek's 4.9 at all. Especially if this step is skipped it's impossible to start with Armbian support for RTD1295/RTD1295 devices since it would harm the project repeating mistakes like with Allwinner's H3 BSP kernel again (where something like rootmydevice was only discovered by accident).
    We can't trust Android vendor's BSP kernels since those employees forced to hack driver support into something they're not interested in (the Linux kernel and its concepts) never worked with mechanisms like peer review or code quality control. If those employees would've started to submit patches upstream where all this stuff happens (Linux kernel community) then this would be something entirely different. But RealTek just like Allwinner and the majority of ARM SoC vendors has no interest in properly upstreaming their code so this code can't be trusted.
    If their stuff is not properly licensed this will most likely prevent developing mainline drivers for the affected hardware (but I doubt anyone will do this anyway since so far only Suse's Andreas Färber worked on the platform -- tried to inform him via CNX but no idea whether he's aware that some RealTek kernel sources are now provided).
    Having now sources does not mean everything's fine now. Next step is looking at the mess contained (if anyone wants to spend weeks of his life with something like this).
  2. Like
    tkaiser got a reaction from TheOWL in pyCurl installation Failed: arm-linux-gnueabihf-gcc   
    So it seems, GNUTLS development stuff is missing. Did you try to install libcurl4-gnutls-dev already? Or try 
    apt-cache search gnutls | grep dev and install the packages listed one by one.
  3. Like
    tkaiser got a reaction from lomady in SD card performance   
    Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
    Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
    Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: (see also/especially the comments there)
    Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards:
    Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
    Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.

    I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
      Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new)   Samsung EVO+ 64GB (brand new)   Samsung EVO+ 32GB (brand new)   Samsung EVO 64GB (already used some time)   SanDisk Extreme Pro 8GB (already used some time)   SanDisk 'Class 10' 8GB (already used some time)   Intenso 'Class 10' 16GB (already used some time)   Intenso 'Class 4' 4GB (already used some time)   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new)  
    Sandisk Extreme Pro 8Gb (almost new)
    Hardkernel eMMC 8G via SD reader (brand new)
    Sandisk Ultra 8Gb (old and very used)
    Sandisk 8GB (almost new)
    Sandisk 8G (new)
    Transcend 8Gb (used)
    Samsung EVO 32Gb (brand new)
        Further readings: Conclusions:
    If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card
  4. Like
    tkaiser got a reaction from lomady in SD card performance   
    2018 SD card update
    It's 2018 now, SD Association's A1 'performance class' spec is out over a year now and in the meantime we can buy products trying to be compliant to this performance class. SD cards carrying the A1 logo must be able to perform at least 1500 random read input-output operations per second (IOPS) with 4KB block size, 500 random write IOPS and 10 MB/s sustained sequential performance (see here for more details and background info)
    Why is this important? Since what we do on SBC at least for the rootfs is mostly random IO and not sequential IO as it's common in cameras or video recorders (that's the stuff SD cards have been invented to be used with in the beginning). As an SBC (or Android) user we're mostly interested in high random IO performance with smaller blocksizes since this is how 'real world' IO patterns mostly look like. Prior to A1 and A2 performance classes there was no way to know how SD cards perform in this area prior to buying. Fortunately this has changed now.
    Last week arrived an ODROID N1 dev sample so I bought two SanDisk A1 cards with 32GB capacity each. An el cheapo 'Ultra A1' for 13€ (~$15) and an 'Extreme A1' for 23€. I wanted to buy a slightly more expensive 'Extreme Plus A1' (since even more performance and especially reliability/longevity) but ordered the wrong one  Please keep in mind that the 'Extreme Plus' numbers shown below are made with an older card missing the A1 logo.
    Let's look how these things perform, this time on a new platform: RK3399 with an SD card interface that supports higher speed modes (requires kernel support and switching between 3.3V to 1.8V at the hardware layer). So results aren't comparable with the numbers we generated the last two years in this and other threads but that's not important any more... see at the bottom.
    A1 conformance requires at least 10 MB/s sequential performance and 500/1500 (write/read) IOPS with 4K blocksize. I tested also with 1K and 16K blocksizes for the simple reason to get an idea whether 4K results are useful to determine performance with smaller or larger blocksizes (since we already know that the vast majority of cheap SD cards out there shows a severe 16K random write performance drop which is the real reason so many people consider all SD cards being crap from a performance point of view).
    I tested with 7 cards, 4 of them SanDisk, two Samsung and the 'Crappy card' being a results mixture of a 4GB Kingston I started to test with and old results from a 4GB Intenso from two years ago (see first post of this thread). The Kingston died when testing with 4K blocksize and the performance of all these crappy 'noname class' cards doesn't vary that much:
    1K w/r 4K w/r 16K w/r Crappy card 4GB 32 1854 35 1595 2 603 Samsung EVO+ 128GB 141 1549 160 1471 579 1161 Ultra A1 32GB 456 3171 843 2791 548 1777 Extreme A1 32GB 833 3289 1507 3281 1126 2113 Samsung Pro 64GB 1091 4786 1124 3898 478 2296 Extreme Plus 16GB 566 2998 731 2738 557 2037 Extreme Pro 8GB 304 2779 323 2754 221 1821 (All results in IOPS --> IO operations per second) For A1 compliance we only need to look at the middle column and have to expect at least 500/1500 IOPS minimum here. The 'Crappy card' fails as expected, the Samsung EVO+ too (but we already knew that for whatever reasons newer EVO+ or those with larger capacity perform worse than the 32GB and 64GB variants we tested two years ago), the Samsung Pro shows the best performance here while one of the 4 SanDisk also fails. But my Extreme Pro 8GB is now 3 years old, the other one I had showed signs of data corruption few months ago and when testing 2 years ago (see 1st post in this thread) random write performance was at 800. So most probably this card is about to die soon and the numbers above are partially irrelevant..
    What about sequential performance? Well, 'Crappy card' also not able to meet specs and all the better cards being 'bottlenecked' by ODROID N1 (some of these cards show 80 MB/s in my MacBook's card reader but Hardkernel chose to use some safety headroom for good reasons and limits the maximum speed for improved reliability)
    MB/s write MB/s read Crappy card 4GB 9 15 Samsung EVO+ 128GB 21 65 Ultra A1 32GB 20 66 Extreme A1 32GB 59 68 Samsung Pro 64GB 61 66 Extreme Plus 16GB 63 67 Extreme Pro 8GB 50 67 Well, sequential transfer speeds are close to irrelevant with single board computers or Android but it's good to know that boards that allow for higher SD card speed modes (e.g. almost all ODROIDs and the Tinkerboard) also show an improvement in random IO performance if the card is a good one. The ODROID N1 was limited to DDR50 (slowest SD card mode) until today when Hardkernel unlocked UHS capabilities so that my cards (except of 'Crappy card') could all use SDR104 mode. With DDR50 mode sequential performance is limited to 22.5/23.5MB/s (write/read) but more interestingly random IO performance also differs. See IOPS results with the two SanDisk A1 cards, one time limited to DDR50 and then with SDR104:
    1K w/r 4K w/r 16K w/r Ultra A1 DDR50 449 2966 678 2191 445 985 Ultra A1 SDR104 456 3171 843 2791 548 1777 1K w/r 4K w/r 16K w/r Extreme A1 DDR50 740 3049 1039 2408 747 1068 Extreme A1 SDR104 833 3289 1507 3281 1126 2113 We can clearly see that the larger the blocksize the more the interface speed influences also random IO performance (look especially at 16K random reads that double with SDR104)
    Some conclusions:
    When comparing results above the somewhat older Samsung Pro performs pretty similar to the Extreme A1. But great random IO performance is only guaranteed with cards carrying the A1 logo (or A2 soon) so it might happen to you that buying another Samsung Pro today results in way lower random IO performance (see Hardkernel's results with a Samsung Pro Plus showing 224/3023 4k IOPS which is way below the 1124/3898 my old Pro achieves with especially write performance 5 times worse and below A1 criteria) We still need to focus on the correct performance metrics. Sequential performance is more or less irrelevant ('Class 10', 'UHS' and so on), all that matters is random IO (A1 and A2 soon). Please keep in mind that you can buy a nice looking UHS card from 'reputable' brands like Kingston, Verbatim, PNY and the like that might achieve theoretical 80MB/s or even 100MB/s sequential performance (you're not able to benefit from anyway since your board's SD card interface will be the bottleneck) but simply sucks with random IO performance. We're talking about up to 500 times worse performance when trusting in 'renowned' brands and ignoring performance reality (see 16k random writes comparing 'Crappy card' and 'Extreme A1') Only a few vendors on this planet run NAND flash memory fabs, only a few companies produce flash memory controllers and have the necessary know-how in house. And only a few combine their own NAND flash with their own controllers to their own retail products. That's the simple reason why at least I only buy SD cards from these 4 brands: Samsung, SanDisk, Toshiba, Transcend The A1 performance speed class is a great and necessary improvement since now we can rely on getting covenant random IO performance. This also helps in fighting counterfeit flash memory products since even if fraudsters in the meantime produce fake SD cards that look real and show same capacity usually these fakes suck at random IO performance. So after testing new cards with either F3 or H2testw it's now another iozone or CrystalDiskMark test to check for overall performance including random IO (!) and if performance sucks you simply return the cards asking for a refund. TL;DR: If you buy new SD cards choose those carrying an A1 or A2 logo. Buy only good brands (their names start with either S or T). Don't trust in getting genuine products but always expect counterfeit stuff. That's why you should only buy at sellers with a 'no questions asked' return/refund policy and why you have to immediately check your cards directly after purchase. If you also care about reliability/resilience buy more expensive cards (e.g. the twice as expensive Extreme Plus A1 instead of Ultra A1) and choose larger capacities than needed.
    Finally: All detailed SD card test results can be found here: As a comparison performance numbers made with same ODROID N1, same settings but vendor's orange eMMC modules based on Samsung eMMC and varying only in size:
  5. Like
    tkaiser got a reaction from pask in Announcement : Odroid N2   
    No, you do NOT know when you're finished firing up your next round of passive benchmarking tests spitting out some numbers. You need to know what's going on to generate answers to the question 'why is A faster than B' and also 'what is the limiter on A and why can't A not be twice as fast'? You missed this change and attributed faster RockPi scores to DDR4 vs. DDR3 memory while in reality you compared old Armbian kernel config with newer one. This whole passive benchmarking approach (and IMO 'technical' Youtube videos in general) always only contributes to confusion and generates zero insights.
    The general rule of passive benchmarking and what in fact happened here is: you benchmark A, but actually measure B, and conclude you've measured C (what's needed instead is Active Benchmarking)
    What matters are insights, settings and software. And this not only applies to RK3399 but to N2/S922X too of course. So with your use case that utilizes all CPU cores in parallel you surely should go with S922X (since being definitely faster than RK3399 with everything that's multi-threaded), then use a kernel with CONFIG_HZ=100 and an optimized software stack. With Gentoo for example, most recent GCC, optimal/aggressive compiler flags for the A53/A73 combo and a CONFIG_HZ=100 kernel on the N2 your Blender job might finish in less than 40 minutes (maybe just 20 or even less if a programmer equipped with knowledge starts to look into Blender code and adds NEON optimizations to the performance critical code parts -- see here for a great example of Active Benchmarking and adding NEON optimizations on ARM to a software that utilizes SIMD Extensions only on x86 so far just like SSE2 optimized Blender does)
    The price you'll pay is a few weeks of your life needed to become a Linux expert since there's nothing ready. Choosing Armbian is usually a matter of convenience but if you want software that performs as fast as possible it's a problematic choice since the software stack is not meant to be performant but to be compatible and stable (funny joke since Armbian's own approach with kernel/bootloader updates is the opposite). The two distro variants Armbian provides are
    Ubuntu also known as 'everything outdated' Debian also known as 'everything outdated as hell' (there are areas where Armbian is in fact faster than other Ubuntu/Debian based images or distros using a more modern software stack like Gentoo or Fedora but this is due to what separates Armbian from the stock Debian/Ubuntu stuff: settings like CPU/IRQ affinity, thermal/DVFS tuning, zram, log2ram and such stuff. But two guys who mostly took care of this contributed nothing to Armbian for a longer time now and no idea how Armbian evolves here in the future. On EoL platforms like Allwinner H5 IRQ affinity is already broken but nobody cares)
  6. Like
    tkaiser got a reaction from TRS-80 in Odroid XU4 - Ubuntu Xenial doesn't run on eMMC   
    XU4 and HC1 are fully software compatible (check the readme) and heat dissipation on HC1 is WAY BETTER than with XU4. But you're limited to 2.5" disks here and should keep in mind that Hardkernel already announced a HC2 without that much details (so maybe using the same JMS561 as on Cloudshell 2 minus the interconnection problems -- better ask in their forum).
    Wrt new boards being interesting for NAS use cases:
    Pine folks want to provide something called 'Cloudmedia Transformer' (same idea as XU4 vs. HC1, the Transformer is a 100% software compatible ROCK64 + JMS578 on the PCB in an heat emitting metal enclosure that fits a 2.5" HDD, they also thought about a 3.5" variant) Similar to 'Le Potato' a so called 'Le Fly' also with RK3328 might appear (the bottom one here) A bunch of RK3399 devices will be available (all with PCIe 2.x x4 and USB3), I expect software support next year on par with RK3328 EspressoBin might have stable software support next year (you can use the native SATA port there and add mPCIe SATA cards with 2 or even 4 additional real SATA ports) Allwinner H6 boards with both PCIe (single lane, PCIe 2.x) and USB3 will appear (see here and keep in mind that Banana Pi people also have an H6 board in the works) Banana Pi R2 might be ready next year (MTK software support looks promising so maybe next year when mainline kernel support matured we'll support the board) The GnuBees are not listed by intention.
  7. Like
    tkaiser got a reaction from RussianNeuroMancer in Banana Pi R2   
    Welcome here! Just looked through your commits and it's really great seeing MTK become commited to open source in the meantime and how far you already got!
    MT7623 hardware features sound great (is there something like the 'MT7623N Datasheet for Development Board' available for MT7623A too?) and I'm really looking forward to devices based on MT7623N/MT7623A from reputable board makers hopefully soon.
    Wrt Banana Pi R2 unfortunately it's challenging. You chose to cooperate with a partner here who has a horrible history: not releasing sources, not releasing schematics (timely), providing insufficient/incorrect information (no one right in his mind would call this abstruse copy&paste mess 'technical documentation'), advertising their products with wrong specs (numbers too high), not supporting their own products responsibly, not cooperating with open source community (even ignoring every try to help, see their reluctance to merge pull requests above who would fix tons of security issues on another device, or fix stability issues and so on) and most importantly their inability to even realize these problems (an unbelievable high level of ignorance, that's most probably their main problem).
    This could all be problems of the past but as you can see clearly it's not. All of the above still applies, Sinovoip fails at unbelievable low levels and just recently they crossed a red line and censored in their forum posts they found to be 'useless' (eg. the only one analyzing R2's boot log and giving some hints). In the meantime they stepped a bit back and reverted their censorship partially but the whole situation is still a mess and just inacceptable. Almost all parts of open source community simple gave up on them and only a few people still try hard to help them (even if they're too ignorant to realize this).
    You know better than anyone else that MTK has not the best reputation in open source circles based on the past (no sources available, NDA required and so on). And while I highly appreciate MTK opening themselves now and becoming part of the open source world all your efforts are at risk! Soon your first open source dedicated board will available. The board maker you cooperate here has obviously no clues what people want to do later with your device (otherwise they would test network and storage performance and so on and focus on reasonable use cases and not moronically try to use this board as a 'Desktop Linux' thingie). And all of the above listed problems unfortunately still apply in 2017, it's only needed to read through this thread: (at the time of this writing still 11 posts of mine censored/hidden).
    Soon all of the above will also be associated with MTK and your open source efforts if you don't step in now. I already fear the first R2 reviews appearing in the wild (since software/support situation will be as horrible as it was all the times in the past with SinoVoip). Please try to escalate this problem with a manager, let representatives get in touch with responsible people at SinoVoip (is Foxconn/Nora Lee also involved?). I think it's really necessary that your partner wakes up and ensures that the problems outlined above get addressed. Otherwise I fear that your whole 'dev board' and open source engagement will fail with the first device since without situation improving R2 starting to sell will just be the same fiasco as with R1 back then (but this time all those people talking about 'If you want open source avoid MTK' will simply move into 'told you so!' mode and blame Mediatek instead of your hardware partner here suffering still so badly from the same problems they had already 2.5 years ago -- most notably ignorance) 
  8. Like
    tkaiser got a reaction from Dwyt in Learning from DietPi!   
    I would call the price/performance not good but simply awesome today given we get ultra performant cards like the 32GB SanDisk Ultra A1 for as low as 12 bucks currently: (I got mine 2 weeks ago for 13€ at a local shop though). And the A1 logo is important since cards compliant to A1 performance class perform magnitudes faster with random IO and small blocksizes (which pretty much describes the majority of IO happening with Linux on our boards).
    As can be seen in my '2018 A1 SD card performance update' the random IO performance at small blocksizes is magnitudes better compared to an average/old/slow/bad SD card with low capacity:
    average 4GB card SanDisk Ultra A1 1K read 1854 3171 4K read 1595 2791 16K read 603 1777 1K write 32 456 4K write 35 843 16K write 2 548 With pretty common writes at 4K block size the A1 SanDisk shows 843 vs. 35 IOPS (IO operations per second) and with 16K writes it's 548 vs. 2 IOPS. So that's over 20 or even 250 times faster (I don't know the reason but so far all average SD cards I tested with up to 8 GB capacity show this same weird 16KB random write bottleneck -- even those normal SanDisk Ultra with just 8GB). This might be one of the reasons why 'common knowledge' amongst SBC users seems to be trying to prevent writing to SD card at all. Since the majority doesn't take care which SD cards they use, test them wrongly (looking at irrelevant sequential transfer speeds instead of random IO and IOPS) and chose therefore pretty crappy ones.
    BTW: the smallest A1 rated cards available start with 16GB capacity. But for obvious reasons I would better buy those with 32GB or even 64GB: price/performance ratio is much better and it should be common knowledge that buying larger cards 'than needed' leads to SD cards wearing out later.
  9. Like
    tkaiser got a reaction from Dwyt in Learning from DietPi!   
    The nice dashboard screenshot above is used by @Fourdee to explain why DietPi is superiour to Armbian: 'With #DietPi, logs and DietPi scripts are mounted to RAM , this reduces SD card write operations vastly' -- while I don't understand the purpose to 'mount scripts to RAM' of course the idea to cache logs into RAM is great! That's why Armbian does it since 2014 already.
    While the above 'proof' is somewhat questionable (watching a 5 min period in a dashboard and once there's activity in one graph taking a screenshot with numbers without meaning) let's look into what makes DietPi that superiour compared to Armbian since it's always a great idea to improve even if that means taking over other project's USPs.
    For whatever reasons DietPi dropped support for all Orange and Banana Pis recently (seems this started with a conversation between @Igor and @Fourdee on Twitter, then continued here and ended up there) so I had to take another board to do a direct comparison. The only boards that are supported by both projects are now Pine64, Rock64, Tinkerboard, some NanoPi and the ODROIDs. I chose Rock64 mostly to ensure that we use same kernel and almost same settings (Armbian's philosophy is to fix as much as possible upstream so our usual performance fixes went into ayufan's Rock64 build scripts DietPi in this case is relying on by accident so even DietPi users can continue to benefit from our work  )
    I took latest official DietPi image for Rock64 and the first surprise was the rootfs being pretty small and entirely full so no way to proceed:
    /dev/mmcblk1p7 466M 453M 0 100% / For whatever reasons DietPi chose to overtake ayufan's partition layout (for users new to DietPi: this is always just someone else's Debian image processed manually and by some scripts until it becames 'DietPi') but their 'dietpi-drive_manager' responsible to resize the rootfs seems not to be able to cope with this (I wanted to report it to DietPi but there's already a report that gets ignored and it seems I can't comment there).
    Edit: Ah, it seems @Fourdee blocked me from helping them entirely. I wanted to assist DietPi folks over at but can't point them to fix the thermal issues they're running into again or why it's a bit weird to reintroduce the 'rootmydevice' issue again or why the new Allwinner BSP code is not such a great idea due to non-existing dvfs/thermal support  
    Fortunately our scripts below /usr/local/sbin/ were not deleted by DietPi so I simply called /usr/local/sbin/ which instantly resized the rootfs partition and was then able to continue. For whatever reasons it took 3 whole reboots to get DietPi upgraded to their latest version v6.2 but then I was able to do so some measurements:
    I then downloaded our Rock64 nightly image (based on Ubuntu Xenial but that doesn't matter that much -- as we all know the userland stuff is close to irrelevant since kernel and settings matter) and did the same thing. But no reboot needed since for whatever reasons DietPi remained on pretty outdated 4.4.77 kernel so I chose to not update Armbian's kernel to our 4.4.115 but to remain at 4.4.77 too:
    Let's look at the results leaving aside the various performance and security issues DietPi suffers from since not relevant if we want to look at stuff where DietPi outperforms Armbian. First 'idle behaviour':
    DietPi Armbian DRAM used: 39 MB (2%) 44 MB (2%) processes: 120 134 cpufreq lowest: 97.5% 99.8% cpufreq highest: 2.0% 0.1% idle temp: 46°C 43.5°C %idle percent: 99.95% 99.98% So we're talking more or less about identical numbers. 'Used' memory after booting is 2% of the available 2GB (anyone thinking 'free' RAM would be desirable on Linux... please try to educate yourself:, the count of processes reported by ps is almost the same, cpufreq behaviour, %idle percentage and temperatures are also the same (DietPi temperature readout is somewhat flawed since their 'cpu' tool affects system behaviour negatively).
    Even if Armbian ships with almost twice as much packages installed by default the process count doesn't differ that much (and idling processes really don't hurt anyway) and used memory after booting also doesn't differ significantly. But this 'boot and sit there in idle' use case isn't that relevant anyway and in situations when RAM is really needed I would assume Armbian users are in a much better position since we ship with zram active allowed to use half of the physical DRAM (see here for a brief introduction to zram).
    So far I don't see that much advantages (none to be honest) but most probably I missed something?
    Anyway: let's continue focussing on storage utilization and 'use':
    DietPi Armbian size img.7z: 104 MB 223 MB (x 2.1) size img: 668 MB 1.6 GB (x 2.5) rootfs size: 457 MB 1.2 GB (x 2.7) packages: 229 436 (x 1.9) commit interval: 5 s 600 s kB_wrtn: 156 KB 448 KB (x 2.9) kB_read: 1008 KB 5912 KB (x 5.9) So both compressed and uncompressed image sizes are much larger with Armbian, same goes for used space on the rootfs which is understandable given that Armbian does not try to be as minimalistic as possible (see the count of pre-installed packages). I don't think going minimalistic is something desirable though we could think about removing development related packages from default installations as @zador.blood.stained suggested already. Maybe it's worth to adjust the rootfs partition size calculation to use slightly less so the uncompressed image size can be a little bit smaller?
    Anyway: for people being concerned about smallest image size possible even without leaving out packages from default install simply building an own image and then switching from ext4 to btrfs does the job since reducing image size to around ~60% (one of Armbian's advantages is that our images are not hand-crafted unique 'gems' but the fully automated result of our build system so everyone on this earth can simply build his own Armbian images suiting his own needs).
    And besides that I really see no benefit in trying to get the rootfs size smaller since we surely don't want to start to encourage users to write Armbian images to old and crappy SD cards with less than 4GB size (though I already consider 4GB cards nothing anyone should use these days since almost all those cards are insanely slow). Let's better continue to educate our users about the importance to choose good and reliable SD cards!
    Now looking at the last 3 lines above. I executed an 'iostat -y 3600' to query the kernel about the total amount of data read and written at the block device layer. within one whole hour With DietPi/Stretch 156KB/1008KB (write/read) were reported and with Armbian/Xenial 448KB/5912KB (write/read). All numbers are too low for further investigations though something is worth a look: that's the default rootfs 'commit interval.' DietPi seems to use ext4 defaults (sync every 5 seconds to SD card) while in Armbian we choose a somewhat high 10 minute value (commit=600).
    So while with Armbian and 448 KB written in one hour almost three times as much data has been written at the block device layer it might be possible that the 156 KB written by the DietPi installation caused more wear at the flash layer below due to a phenomenon called Write Amplification (TL;DR version: writes at the flash layer happen at 'page sizes', usually 8K, and by using a high commit interval somewhat larger data chunks will be written only every few minutes which can result in significantly less page writes at the flash layer compared to writing every few seconds smaller chunks of data. Adding to the problem once a card is 'full' now we're talking about much higher Write Amplification since now not just pages are written but usually whole Erase Blocks are affected that are much larger. So please choose your SD card wisely and always use a much larger capacity than needed since there's no TRIM with SD cards in Linux!)
    It would need a lot of more detailled analysis about this write behaviour but IMO it's not worth the efforts and Armbian's 10 min commit interval does a great job reducing further SD card wearout (anyone with too much spare time? Grab 'iostat 5' and 'iotop -o -b -d5 -q -t -k | grep -v Total' and start to analyse what's happening at the block device and application layer forgetting about the filesystem layer in between!)
    So where's some room for improvement when comparing our defaults with DietPi's?
    Maybe removing development related packages from default package list? Maybe tuning rootfs partition creation to use slightly less space? Mostly unrelated but an issue: improving our log2ram behaviour as already discussed?
  10. Like
    tkaiser got a reaction from lanefu in netdata is awesome   
    Nope. Netdata is awesome. All I tried to explain is why 'armbianmonitor -r' was an attempt to generate insights about SBC behavior 3 years ago and why netdata is not sufficient for this purpose. Once you look at results the data collection approach completely changes system behavior --> useless for this use case.
    IMO you should take care of cpufreq scaling on this class of devices and if netdata should generate insights and not just fancy graphs you might want to explore EAS.
  11. Like
    tkaiser got a reaction from lanefu in Announcement : Odroid N2   
    Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
    RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
    That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
  12. Like
    tkaiser got a reaction from NicoD in Announcement : Odroid N2   
    There's a lot more. I just updated my post above with GCC 8.2 results. When Blender is built with a more recent compiler rendering gets faster (this is one of the many reasons why this Phoronix stuff is so bad -- Michael Larabel doesn't educate his users about such basics but throws a bunch of meaningless numbers and graphs at them to create the impression benchmarking would be something magic).
    And if you build Blender from source with appropriate compiler flags (not those ultra conservative distro defaults, especially not with 'stable' distros like Debian and Ubuntu) then it will be even faster.
    Very unlikely. And performance is already known, check sbc-results for PineH64 (board vendors don't matter, it's only about the SoC in question). And of course settings matter. If you use one of those crappy Xunlong images there's no need to test further since they're known for using crappy Allwinner defaults that suck.
  13. Like
    tkaiser got a reaction from balbes150 in Announcement : Odroid N2   
    Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
    RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
    That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
  14. Like
    tkaiser got a reaction from NicoD in Announcement : Odroid N2   
    'Around for a long time'? The point is not since when settings exist but what the defaults are and why people interested in maximum performance should care about such settings. This was the context:
    And by looking at both tinymembench and Blender scores it should be pretty obvious that this makes a difference for workloads that utilize CPU cores fully... just to explain why comparing RK3399 and S922X benchmark scores doesn't make that much sense as long as such essential stuff is not also considered.
    @NicoD: I explained in my former post how to check for such settings, simply check the spoiler.
  15. Like
    tkaiser got a reaction from NicoD in Announcement : Odroid N2   
    Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
    RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
    That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
  16. Like
    tkaiser got a reaction from NicoD in Announcement : Odroid N2   
    Same with S922X, simply check @rooted's sbc-bench results (where even the cpufreq OPP are checked and confirmed). The problem is not thermal but reliability/undervoltage due to the firmware running on the Cortex-M3 controlling DVFS which can be clearly seen by running the most heavy load called cpuminer. 
    Quoting myself: ''Overclocked' executions with both CPU clusters set to 2.0 GHz showed reliability issues most probably due to DVFS undervoltage (cpuminer quit almost immediately here while it ran only 50 seconds there -- this tool since being a load generator checking for data corruption can also be used for reliability testing but I would prefer our StabilityTester instead)'
    I already suggested to Justin and Dongjin to take our StabilityTester approach to provide N2 users with an easy way to check for undervoltage/instabilities since a lot of those users will activate the 'overclocking' settings (most probably these are undervolting settings at the same time based on results) and then end up with silent data corruption and/or crashes (all the great results of trying to get laughable 7%-8% performance gain almost nobody is able to notice).
    Simply do a web search for CONFIG_HZ
  17. Like
    tkaiser got a reaction from TonyMac32 in Announcement : Odroid N2   
    Since the last round of Moronix madness didn't include a single RK3399 device I decided to give two rounds of silly kitchen-sink benchmarking a try using the 'reputable' Phoronix Test Suite:

    For those thinking the N2 results would be better when running bare metal... I doubt it since of course I checked with sbc-bench first:
    here's running sbc-bench on 'ODROID Bench' inside a container: and there's the results Dongjin (@tobetter) shared with me few days ago (look at the timestamp, Hardkernel tested already weeks ago so they were pretty clear about which benchmark results to publish and which not): The ODROID-N1 numbers are representative for each and every RK3399 device out there running at 2.0/1.5GHz with CONFIG_HZ=250. Scores might improve once Rockchip provides new DRAM initialization BLOBs especially on those boards using LPDDR4.
  18. Like
    tkaiser got a reaction from TonyMac32 in Announcement : Odroid N2   
    Funny place here...
    All the RK3399 'benchmark' results collected so far were done with CONFIG_HZ=1000 (good for a responsive UI in Android and Linux, not so good for normal computing or server tasks) while everywhere around CONFIG_HZ=250 is the default. Is this affecting Blender or not? Anyone tested so far (latest ayufan images switched to CONFIG_HZ=250)? Anyone into Active Benchmarking instead of just firing up the next round of kitchen-sink benchmarks in fire-and-forget mode collecting more numbers without meaning? The challenge with 'overclocking' the N2 is not trottling but stability/reliability as can be easily seen with the cpuminer tests that are sufficient for reliability testing (see N2 notes here). The DVFS OPP are defined in a closed firmware BLOB and the whole thing happens on the Cortex-M3 inside S922X. N2 has no LPDDR4 but DDR4, memory performance depends not just on type of memory but on DRAM initialization (done with BLOBs on both RK3399 and S922X). TL Lim said Rockchip will provide a new BLOB to make use of faster LPDDR4 access on RockPro64 in 2018 but I don't know whether this has already happened or not Memory benchmark scores depend on stuff like dmc or CONFIG_HZ since how would you explain better memory performance when switching from CONFIG_HZ=1000 to CONFIG_HZ=250 on RK3399 (previously known as difference between RK's 4.4 kernel and mainline though it's just different CONFIG_HZ defaults). Same with executing a memory benchmark on a little vs. big core Memory bus width is different between S922X and RK3399 (32-bit vs. 64-bit) but whether this will result in faster execution depends on a lot of factors (application in question, DRAM initialization BLOB, kernel settings, kernel tunables, see dmc memory governor with RK3399, and so on)  
    Added some updates to
  19. Like
    tkaiser got a reaction from Spemerchina in NanoPi M4 performance and consumption review   
    Really looking forward to this HAT
    BTW: I've not the slightest idea how much efforts and initial development costs are needed for such a HAT. But in case the Marvell based 4-port SATA solution will be somewhat expensive maybe designing another one with an ASMedia ASM1062 (PCIe x2 and 2 x SATA) and just one Molex for 2 drives might be an idea. Could be one design made for NEO4 that will work on M4 too with a larger (or dual-purpose) HAT PCB?
  20. Like
    tkaiser got a reaction from UnixOutlaw in Avahi   
    When did we do that the last time? Ah, that must have be Stone Age or was it already the Dark Ages?
    That reminds me to check u-boot's algorithm to generate the MAC address based on sunxi SoC's SID to create dnsmasq entries automagically based on the SID of the board in question. 
    BTW: One of the many Armbian advantages is the ability to deploy devices headless without crap like connecting a serial console first or fiddle around in configuration files. And static IP addresses can be assigned in a central location and not by editing text files on a bunch of devices. It's 2016 and not 1970 any more!
  21. Like
    tkaiser reacted to memeka in Htop on xu3/4   
    My english is better than that
  22. Like
    tkaiser got a reaction from typoinmyname in Just a test   
    Armbianmonitor: http://ignorance.stupidity Which kind of idiot 'designed' 4 checkboxes without an alternative each that all have to be checked? What's the purpose of this mess? Anyone awake here?

  23. Like
    tkaiser got a reaction from alexparser in KSZ9031RNX Ethernet IC   
    Nope. Needs 3.9 or above.
  24. Like
    tkaiser got a reaction from NicoD in NanoPI M4   
    Of course. You need to fix this otherwise everything you do is just a waste of time. And it's under-VOLTAGE and not under-current so as long as you ignore Ohm's law you're getting nowhere. The problem is high resistance and most probably (and as usual) the cable between PSU and device is to blame.
  25. Like
    tkaiser got a reaction from lomady in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable ( and update the NAS Expansion board ( with:
    root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
    /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.