• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    Dwyt reacted to 5kft in Nanopi NEO2 CPU frequency issue   
    Per request, here are updated instructions for overclocking the NEO2 v1.1 LTS board to 1.3GHz, for the latest builds of Armbian (kernel 4.19+, build 5.70+):
    1.  Please note that this will not work on a NEO2 v1.0 board - the first version of the board doesn't include a regulator nor circuit that supports voltage switching.  Only follow these instructions if you are using a v1.1 board!
    2.  Edit /boot/armbianEnv.txt, and add these lines:
    overlay_prefix=sun50i-h5 overlays=cpu-clock-1.3GHz-1.3v If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example:
    overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost1 usbhost2 cpu-clock-1.3GHz-1.3v  
    3.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000, e.g.:
    # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand  
    4.  Configure APT so that /etc/default/cpufrequtils will not be reverted to the system default when the package is upgraded (e.g., via "apt upgrade"):
    dpkg-divert --add /etc/default/cpufrequtils  
    5.  Reboot the board.
    That should be it!  Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).
  2. Like
    Dwyt reacted to 5kft in Nanopi NEO2 CPU frequency issue   
    Given the number of boards that can support higher CPU clocks (e.g., Nano Pi Neo 2, Plus2, Core2, OPi Zero Plus, OPi Zero Plus2 w/H/W MOSFET fix, etc.) it'd be great to be able to do this with overlays, rather than introduce a combinatorial explosion of board DTBs (i.e., per-board 1.1GHz max, 1.3GHz max, 1.4GHz max).
    I have made some test override overlays to add the regulator and extend the CPU operating table (e.g., adding additional CPU core clock frequencies).  This works fine - one can just add the desired overlays in armbianEnv.txt and the new clock speeds appear and work:
    ... overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz param_spidev_spi_bus=1 ... However the problem is that one can't reliably run these boards at the higher clock rates without adjusting the thermal-zone cooling-map for the higher speeds.  Unfortunately device tree overlays don't appear to support thermal zones (at least I can't get them to compile with these present ).
    I'm interested if anyone might have any ideas to to manage this.  Just brainstorming here, but perhaps we could make the default cooling-map for the H5 a bit more conservative, and then it could cover the introduction of the higher possible clock rates?  Or perhaps we could remove some slower entries from the H5 default clock operating table to allow for the addition of the optional higher clock rates (to better correspond to the default H5 cooling-map)?
    Again, the nice thing about the overlay route is that we wouldn't have to change the 1.1GHz Armbian H5 default, so operation will be reliable.  But if users want to try speeding up their boards (whatever brand, VDD regulator, etc.), then they can just add an overlay or two and voila the higher speeds will be enabled.
  3. Like
    Dwyt reacted to tkaiser 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: https://www.amazon.com/Sandisk-Ultra-Micro-UHS-I-Adapter/dp/B073JWXGNT/ (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.
  4. Like
    Dwyt reacted to tkaiser 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 https://github.com/Fourdee/DietPi/issues/1550 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/resize_rootfs.sh 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: https://www.linuxatemyram.com), 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?
  5. Like
    Dwyt reacted to Frank F. in NanoPi NEO2 or NEO Plus2 - Shopping advice needed   
    Hi @5kft,
    thank you for the detailed reply. I have to admit, both the NEO2 and the NEO Plus2 looked so appealing with their metal cases, that I ended up ordering both. I'm happy to hear, that the eMMC performance is nice. I had not found any benchmarks on that, but found that there's real differences between the various manufacturers and models.
    I also have a BPI-M2 Berry and was very disappointed, when I found out just how bad the software support is. The stock OS is indiscussable, which is how I came to Armbian. Armbian by itself runs stable out of the box, but I could not get any of the interfaces like GPIOs, I2C, SPI, ... to work at all. I had originally bought it because it's the cheapest board with real Gigabit Ethernet, because I'm using it as a network device, but overall it was still a rather large disappointment. I never wanted this experience again, which is why I was asking about the WiP status of the +2. I thoroughly searched before and after my Post, but I could not find any reason for it being WiP still, so I thought I'd give it a shot. Now I can't wait for the packages to arrive... in a few weeks or so.
  6. Like
    Dwyt reacted to Igor in Predictable Network Interface names   
    Add this
    extraargs=net.ifnames=0 to /boot/armbianEnv.txt