Jump to content

manuti

Members
  • Posts

    352
  • Joined

  • Last visited

Reputation Activity

  1. Like
    manuti reacted to segv in [RK3328] Scishion V88 Piano and V88 Mini III TV boxes   
    Ayufan’s Armbian on a V88 Piano or V88 Mini III
     
    These two TV boxes seem to be electrically identical except that the V88 Mini III has 2 GB RAM and 8 GB ROM whereas the V88 Piano has 4 GB RAM and 16 GB ROM.
    They use the same PCB as can be seen from the photos in these FreakTab topics:-
    - http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/681869-scishion-v88-piano-tv-box-rk3328-4gb-ram-16gb-rom-android-7-1-usb-3-0-fast-lan
    - http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/663248-scishion-v88-mini-iii-tv-box-rk3328-2-8gb-2-4-wifi-fast-lan
     
    I do not have a V88 Mini III to test but I believe that my results for the V88 Piano should also be relevant to it.
     
    N.B. many sites claim that the V88 Piano has Gigabit Ethernet (1000 Mbps). It does not: it only has Fast Ethernet (100 Mbps) like the V88 Mini III.
     
    One nice thing about these TV boxes is that, unlike many others, they will boot easily from a micro-SD card.
    Just insert the card and power on
     
    My aim was to have Ubuntu running with all version-specific partitions (boot and root) on a USB drive.
    I wanted to keep Android in the internal eMMC so that I could dual-boot by just inserting or removing the micro-SD card.
     
    I wanted to have the root partition on a USB stick for three reasons:
    1) A good USB stick is faster than a micro-SD card.
    2) This avoids the system writing repeatedly to the micro-SD card because, if the root partition is on the micro-SD card, after a while it gets corrupted and will no longer boot. This happened to me with both a cheap Ansonchina card and also with a Kingston card. Maybe the write timings in the micro-SD card driver are incorrect.
    3) Whilst experimenting on Amlogic boxes I have fried two big micro-SD cards. I have read that others have fried cards on Rockchip boxes. Moving the rootfs to a USB stick enables me to use a smaller and cheaper card.
    (I suspect that they were destroyed by over-voltage due to a badly programmed regulator. With a 5 V USB stick and a 5 V PSU there should be no risk as I don’t think the regulators used can step up the voltage.)
     
    I also wanted the boot partition to be on the USB stick so that I could have several GNU/Linux distributions on different USB sticks and boot with the same unmodified micro-SD card containing just the boot loaders.
     
    I have deliberately avoided the necessity to have a Linux (or even Windows) PC.
     
    N.B. the Ubuntu system will not (yet) have working Wi-Fi.
     
    You will need:-
    - a rooted V88 Piano (mine was sold pre-rooted)
    - a micro-SD card: mine was 8 GB but 4 GB should suffice
    - a USB Flash Drive: I have used both 32 GB and 8 GB but 4 GB may suffice for a fairly minimal system
    - a USB keyboard (and mouse if installing a desktop): I used a wireless mini-keyboard/mouse
    - a wired (RJ45) Ethernet connection with DHCP and Internet access
    - an HDMI display
     
    WARNING: before using a /dev/ or /dev/block device verify that you are using the correct one, using dmesg for instance. Otherwise you could overwrite precious data.
    However if you remove all additional USB drives the names below should be correct.
     
    The login is rock64 with password rock64 which is also required for sudo.
     
    First step – install Ayfan’s Ubuntu Xenial Minimal 0.5.15 on a micro-SD card and prepare 0.6.25 on a USB stick.
     
    Boot Android.
     
    I installed and used Google Chrome for the following downloads because, with the stock Lightning browser, I couldn’t see when the download had finished.
    (The busybox wget can't be used because it doesn’t support https.)
     
    Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 in the browser.
    Download xenial-minimal-rock64-0.5.15-136-arm64.img.xz
     
    If you wish to pass directly to Ubuntu Bionic you could use the Bionic 0.6.25 image instead of Xenial below.
    However this may make it more difficult to update U-Boot later as I think a Xenial environment is expected to compile it.
    Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.6.25 in the browser.
    Download xenial-minimal-rock64-0.6.25-193-arm64.img.xz

    Insert the micro-SD card and the USB stick.
    N.B. all existing files on both will be destroyed.
    You will be asked how to use the USB stick: choose "removable storage" and "cancel" if asked whether to format it.
     
    Execute the following actions and commands (in the text following the $ or #).
     
    Install and start ConnectBot.
     
    Open a local shell.
    Become root.
    $ su
     
    Enter the directory where browsers save downloaded files.
    # cd /sdcard/Download
     
    Decompress the files.
    # busybox xz -d xenial-minimal-rock64-0.5.15-136-arm64.img.xz
    # busybox xz -d xenial-minimal-rock64-0.6.25-193-arm64.img.xz
     
    Write the 0.6.25 image to the USB stick.
    # dd if=xenial-minimal-rock64-0.6.25-193-arm64.img of=/dev/block/sda bs=1048576
     
    Write the 0.5.15 image to the micro-SD card.
    # dd if=xenial-minimal-rock64-0.5.15-136-arm64.img of=/dev/block/mmcblk1 bs=1048576
     
    Ensure everything is written.
    # sync
     
    Power off the box.

    Second step – boot Ayfan’s Ubuntu Xenial Minimal 0.5.15 and prepare the switch to 0.6.25 on the USB stick.
     
    Insert the micro-SD card.
    Boot and login (rock64/rock64).
     
    Become root.
    $ sudo -s
     
    Remove partitions 6 (boot) and 7 (root) from the micro-SD card so that U-Boot and Linux will use the ones on the USB stick next time.
    Luckily this only deletes their entries so Linux can continue to use them until they are unmounted.
    Reply "Yes" and "Ignore" to the warnings.
    # parted /dev/mmcblk1
    rm 6
    rm 7
    q
     
    # poweroff

    Third step - boot Ayfan’s Ubuntu Xenial Minimal 0.6.25 from the boot and root partitions on the USB stick and prepare to update to a recent version.
     
    Insert the USB stick in the middle USB slot and insert the micro-SD card.
    Boot and login.
    $ sudo -s
     
    This DHCP configuration will be necessary for Bionic.
    # cd /etc/network/interfaces.d
    # sed s/eth0/eth1/ eth0 > eth1
     
    At the time of writing there are only pre-release versions of 0.6.x but Ayufan has promised an official release shortly after the official release of Bionic due on 24th April.
    If, in addition to Ubuntu updates,  you want to update to Auyufan's pre-release versions with an added risk of instability then:
    # vi /etc/apt/sources.list.d/ayufan-rock64.list
    Uncomment the last line
     
    # apt update
     
    The following lines are necessary if you update to a more recent Ayufan version which will disable eth1:
    This is needed to re-enable eth1:
    # apt install device-tree-compiler
    Make rc.local enable eth1 which is disabled in recent versions and disable eth0 which is not used on the V88 Piano:
    # vi /etc/rc.local
    Add these two lines just before the last line (exit 0):
    enable_dtoverlay eth1 ethernet@ff550000 okay
    enable_dtoverlay eth0 ethernet@ff540000 disabled
     
    # apt dist-upgrade -y
     
    If you want a Mate desktop you can:
    # install_desktop.sh mate
     
    This gave me an error which I corrected with:
    # apt -f install
     
    If you wish you can also upgrade from Xenial to Bionic with do-release-upgrade.
     
    # reboot
     
    You should now be running an up-to-date version with the boot and root partitions on the USB stick.

    The next step will be to compile and install a more recent U-Boot supporting the USB 3.0 port correctly.
    To be continued...

    The procedure above may seem convoluted so here are some additional explanations.
    0.5.15 is used for its boot loaders as it is the latest version which will boot directly from a micro-SD card. Unfortunately it does not have working Ethernet and its U-Boot will not load correctly from the USB 3.0 slot.
    0.6.25 is used because it has working Ethernet to install device-tree-compiler which is needed to re-enable eth1 on recent versions.
  2. Like
    manuti reacted to heimlich in Armbian very slow on mxq pro 4k s905   
    Answer to myself,  in fact i had problems on my bpl but now my lan is ok.
     
    But i ve got another problem,  plex server is installed on my mxq pro, when plex check the library after a short time it is freezed. 
    Where can i see temp log?  What is the max temp supported? 
    Thx
  3. Like
    manuti reacted to balbes150 in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    The test version of the KODI-17.6 (for s905\s905x). Important warning. This version is built on Ubuntu, so when you try to install on Debian libraries may not be suitable and you will have to manually install the necessary packages and create the necessary links to these libraries. In the future, I hope to build a deb version of the package for Debian as well. The order of installing the new version on the previous images.
     
    1. To remove all packages with for version 17.3 names that start in aml-* (amremote, mali, kodi).
    2. Remove the package "libasound2-plugins" with all its dependencies (**this is important**). Corrected. This item does not need to perform.
    3. Restart the system.
    4. Install a set of new packages at this link (aml-remote aml-codec aml-mali6 aml-kodi).
     
    https://yadi.sk/d/NoKnDPJL3SxzbK
     
    5. Restart the system.
     
    After these steps, you can test the new version of KODI-17.6.
    Please note-this is a test version and there may be errors. You can go back to the previous version of KODI-17.3 (remove the new packages and install old versions of packages).
     
     
    Update Armband images for s9xxx 20180303 .
    In the image with Ubuntu Mate now uses a new version of KODI 17.6 (for s905\s905x).
     
    https://yadi.sk/d/7iYtTCRh3SyBZT
  4. Like
    manuti reacted to TheLinuxBug in H2: Sunvell R69 Android TV Box (AliExpress)   
    Well, it wasn't that weekend, it took me a while but I did eventually make a blog post for it: Sunvell R69 - My adventures with a cheap TV Box
     
    Additionally, Sunvell R69 is fully supported by H3Droid but we do suggest the use of a fan for sure!
     
    Cheers!
  5. Like
    manuti 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?
  6. Like
    manuti reacted to tkaiser in ODROID N1 -- not a review (yet)   
    USB3 anomalies / problems
     
     
    When I tested this almost 2 weeks ago I did not pay attention close enough to the crappy write performance: 470 MB/s with 4 SSDs in parallel attached to all SATA and USB3 ports is just horribly low given that we have a 'per port' and a 'per port group' limitation of around 390 MB/s. What we should've seen is +650 MB/s taking the overhead into account. But 470 MB/s was already an indication that there's something wrong.
     
    Fortunately in the meantime an ODROID community member tested various mirror attemps with 2 Seagate USB3 disks, reported 'RAID 0 doubles disk IO' while in reality showing exactly the opposite: None of his three mirror attempts (mdraid, lvm and btrfs) reported write performance exceeding 50 MB/s which is insanely low for a RAID0 made out of two 3.5" disks (such lousy numbers are usually not even possible with 2 USB2 disks on separate USB2 ports).
     
    So let's take a look again: EVO840 and EVO750 both in JMS567 enclosures connected to each USB3 port. I simply created an mdraid RAID0 and measured sequential performance with 'taskset -c 5 iozone -e -I -a -s 500M -r 16384k -i 0 -i 1':
    kB reclen write rewrite read reread 512000 16384 85367 85179 312532 315012 Yep, there's something seriously wrong when accessing two USB3 disks in parallel. Only 85 MB/s write and 310 MB/s read is way too low especially for rather fast SSDs. 'iostat 1' output shows that each disk when writing remains at ~83 tps (transactions per second): https://pastebin.com/CvgA3ggQ
     
    Ok, let's try to get a clue what's bottlenecking. I removed the RAID0 and formatted both SSDs as ext4. First tests with only one SSD active at a time:
    kB reclen write rewrite read reread EVO840 512000 16384 378665 382100 388932 392917 EVO750 512000 16384 386473 385902 377608 383549 Now trying to start the iozone runs at the same time (of course iozone tasks sent to different CPU cores to avoid CPU bottlenecks, same applies to IRQs: that's /proc/interrupts after test execution):
    kB reclen write rewrite read reread EVO840 512000 16384 243482 215862 192638 160677 EVO750 512000 16384 214356 252474 168322 195164 So there is still some sort of a limitation but at least it's not as severe as in the mirror modes when all accesses to the two USB connected disks happen exactly in parallel.
     
    When looking closer we see another USB3 problem long known from N1's little sibling ROCK64 (any RK3328 device is a much nearer relative to N1 than any of the other ODROIDs):
    [ 3.433165] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 3.433183] xhci-hcd xhci-hcd.7.auto: @00000000efc59440 00000000 00000000 1b000000 01078001 [ 3.441152] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 3.441171] xhci-hcd xhci-hcd.8.auto: @00000000efc7e440 00000000 00000000 1b000000 01078001 [ 11.363314] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 11.376118] xhci-hcd xhci-hcd.7.auto: @00000000efc59e30 00000000 00000000 1b000000 01078001 [ 11.385567] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 11.395145] xhci-hcd xhci-hcd.8.auto: @00000000efc7ec30 00000000 00000000 1b000000 01078000 [ 465.710783] usb 8-1: new SuperSpeed USB device number 3 using xhci-hcd [ 465.807944] xhci-hcd xhci-hcd.8.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 465.817503] xhci-hcd xhci-hcd.8.auto: @00000000efc7ea90 00000000 00000000 1b000000 01078001 [ 468.601895] usb 6-1: new SuperSpeed USB device number 3 using xhci-hcd [ 468.671876] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 468.671881] xhci-hcd xhci-hcd.7.auto: @00000000efc591f0 00000000 00000000 1b000000 01078001 I updated bootloader and kernel this morning and have no idea whether this was introduced (again?) just recently or existed already before:
    root@odroid:~# dpkg -l | egrep "odroid|bootini" ii bootini 20180226-8 arm64 boot.ini and its relatives for ODROID-N1 ii linux-odroidn1 4.4.112-16 arm64 Linux kernel for ODROID-N1  
    But I guess we're still talking about a lot of room for improvements when it's about XHCI/USB3, BSP kernel and RK3399
     
    Edit: Strangely when I tested with USB3 when I received the N1 two weeks ago the RAID0 results weren't that low. Now I remembered what happened back then: I immediately discovered coherent pool size being too low and increased that to 2MB (gets removed every time the 'bootini' package will be updated). And guess what: that does the trick. I added 'coherent_pool=2M' to kernel cmdline and we're back at normal performance though there's still a ~390 MB/s overall limitation.
     
  7. Like
    manuti reacted to tkaiser in Banana Pi R64   
    Just for the record: Banana people work on another MediaTek based board: https://github.com/BPI-SINOVOIP/BPI-files/commit/a3c53c233fd2059a43763a78b13ca1c5fd0b0f50
     
    SoC is a MT7622A (dual core ARM Cortex A53 processor with some 'dedicated network accelerator', RAID/XOR engine, SATA and PCIe 2.0), latest bootloader commit suggests that the board will be equipped with 802.11ac (AC2600) Wi-Fi.
  8. Like
    manuti reacted to raschid in H2: Sunvell R69 Android TV Box (AliExpress)   
    Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 17:17:45: 1008MHz 0.11 7% 4% 3% 0% 0% 0% 36.2°C 0/7 same build (4.14.20-sunxi). Ambient temp: 21 degs.
     
  9. Like
    manuti reacted to Larry Bank in UC1701 LCD library   
    I just released a new C library to draw text and graphics on the UC1701 128x64 monochrome LCD. It makes use of my ArmbianIO library to manipulate the GPIO lines:
     
    https://github.com/bitbank2/uc1701

  10. Like
    manuti reacted to tkaiser in ODROID N1 -- not a review (yet)   
    Storage performance update... what to use to store the rootfs on?
     
    In the following I compare 4 good SD cards with 4 different eMMC modules Hardkernel sells for the N1 with 4 different SSD setups. As some background why I chose to measure random IO with 1k, 4k and 16k block sizes please read the 'SD card performance 2018 update' first.
     
    The following are IOPS numbers (IO operations per second) and important if we want to know how fast storage performs when used as an 'OS drive' (random IO performance is the most important factor here):
    1K w/r 4K w/r 16K w/r SanDisk Extreme Plus 16GB 566 2998 731 2738 557 2037 SanDisk Ultra A1 32GB 456 3171 843 2791 548 1777 SanDisk Extreme A1 32GB 833 3289 1507 3281 1126 2113 Samsung Pro 64GB 1091 4786 1124 3898 478 2296 Orange eMMC 16GB 2450 7344 7093 7243 2968 5038 Orange eMMC 32GB 2568 7453 7365 7463 5682 5203 Orange eMMC 64GB 2489 7316 7950 6944 6059 5250 Orange eMMC 128GB 2498 8337 7064 7197 5459 4909 Intel 540 USB3 7076 4732 7053 4785 5342 3294 Samsung EVO750 USB3 8043 6245 7622 5421 6175 4481 Samsung EVO840 powersave 8167 5627 7605 5720 5973 4766 Samsung EVO840 performance 18742 10471 16156 9657 10390 7188 The SD cards I chose for this comparison all perform very well (an average no-name, Kingston, PNY, Verbatim or whatever other 'reputable' brand performs way lower wrt random IO!). But it can be clearly seen that Hardkernel's eMMC modules are a lot more performant. Regardless of size they all perform pretty similar though the small 16GB module being bottlenecked due to a write performance limitation that also affects 16k random IO write performance.
     
    With SSDs it depends: I chose somewhat ok-ish consumer SSDs for the test so in case you want to buy used SSDs or some 'great bargains' on Aliexpress or eBay be prepared that your numbers will look way worse. The SATA connected EVO840 is listed two times since performance with small blocksizes heavily depends on PCIe power management settings (default is powersave -- switching to performance increases idle consumption by around ~250mW but only then a SATA connected SSD is able to outperform Hardkernel's eMMC. That's important to know and also only applies to really performant SSDs. Cheap SSDs especially with small capacities perform way lower)
     
    Now let's look at sequential performance with large blocksizes (something that does NOT represent the 'OS drive' use case even remotely and is pretty irrelevant for almost all use cases except creation of stupid benchmark graphs):
    MB/s write MB/s read SanDisk Extreme Plus 16GB 63 67 SanDisk Ultra A1 32GB 20 66 SanDisk Extreme A1 32GB 59 68 Samsung Pro 64GB 61 66 Orange eMMC 16GB 48 298 Orange eMMC 32GB 133 252 Orange eMMC 64GB 148 306 Orange eMMC 128GB 148 302 Intel 540 USB3 325 370 Samsung EVO750 USB3 400 395 Samsung EVO840 powersave 375 385 Samsung EVO840 performance 375 385 We can see that N1's SD card interface seems to bottleneck sequential read performance of all tested cards to around ~67 MB/s. Write performance depends mostly on the cards (all cheap cards like the tested SanDisk Ultra A1 32GB you get currently for $12 on Amazon are limited here). The Hardkernel eMMC modules perform very well with sustained read performance at around 300MB/s and write performance depending on module size at up to ~150 MB/s.
     
    With SSDs it depends -- we have an interface limitation of around ~395 MB/s on the USB3 ports and a little bit lower on the SATA ports but unless you buy rather expensive SSDs you won't be able to reach the board's bottleneck anyway. Please also keep in mind that the vast majority of consumer SSDs implements some sort of write caching and write performance drops down drastically once a certain amount of data is written (my Intel 540 get's then as slow as 60MB/s, IIRC the EVO750 can achieve ~150 MB/s and the EVO840 180 MB/s).
     
    Why aren't HDDs listed above? Since useless. Even Enterprise HDDs show random IO performance way too low. These things are good to store 'cold data' on it but never ever put your rootfs on them. They're outperformed by at least 5 times by any recent A1 rated SD card, even crappy SSDs are at least 10 times faster and Hardkernel's eMMC performs at least 50 times better.
     
    So how to interpret results above? If you want energy efficient and ok-ish performing storage for your rootfs (OS drive) then choose any of the currently available A1 rated SD cards from reputable vendors (choose more expensive ones for better performance/resilience, choose larger capacities than needed if you fear your flash memory wearing out too fast). If you want top performance at lowest consumption level choose Hardkernel's eMMC and keep in mind that the smallest module is somewhat write performance bottlenecked. Again: if you fear your flash memory wearing out too fast simply choose larger capacities than 'needed'.
     
    If you want to waste huge amounts of energy while still being outperformed by Hardkernel's eMMC buy a cheap SSD. Keep in mind that you need to disable PCIe powermanagement further increasing idle consumption to be able to outperform eMMC storage otherwise N1's SATA/PCIe implementation will bottleneck too much. So when do SSDs start to make sense? If you either really need higher performance than Hardkernel's eMMC modules and are willing to spend some serious amount of money for a good SSD or the '1k random IO' use case really applies to you (e.g. trying to run a database with insanely small record sizes that constantly updates at the storage layer).
     
    But always keep in mind: if you not really choose a more expensive and high performing SSD you'll always get lower performance than eMMC while consumption is at least 100 times higher. And always use SSDs at the SATA ports since only there you can get higher random IO performance compared to eMMC and being able to benefit from TRIM is essential (for details why TRIM is a problem on USB ports see above). But keep in mind that internal SATA ports are rated for 50 matings max so be prepared to destroy connectors easily when you permanently change cables on those SATA ports   
     
    But what if you feel that any SATA attached storage (the cheapest SSD around and even HDDs) must be an improvement compared to eMMC or SD cards? Just use it, all of the above is about facts and not feelings. You should only ensure to never ever test your storage performance since that might hurt your feelings (it would be as easy as 'cd $ssd-mountpoint ; iozone -e -I -a -s 100M -r 1k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' but really don't do this if you want to believe in one of the most common misbeliefs with consumer electronics today)
     
    As a reference all IO benchmark results for SD cards, Hardkernel's eMMC modules and the SSD tests:
    https://pastebin.com/2wxPWcWr https://pastebin.com/ePUCXyg6 https://pastebin.com/N5wEghn3  
     
  11. Like
    manuti reacted to hekkru in H2: Sunvell R69 Android TV Box (AliExpress)   
    hey! using this h2 beast, completely unusable when hdmi is connected(96C degrees), without hdmi is okay(55C).
    nand install, self-compiled headless debian9 image.
  12. Like
    manuti reacted to tkaiser 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: https://pastebin.com/2wxPWcWr 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: https://pastebin.com/ePUCXyg6
  13. Like
    manuti got a reaction from balbes150 in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    Better way. You can count on me to try with S905X in MXQ Pro and pro plus. 
  14. Like
    manuti reacted to Attila in armbian-config starts flashing automatically   
    I've installed a pristine copy of Armbian_5.38_Nanopiair_Debian_stretch_next_4.14.15 onto an SD card, booted up my NanoPi Neo Air successfully. I even managed to get wifi to work, etc. When trying to enable the SPI interface (ls -la /dev/ | grep -i spi returns no devices) I ran sudo armbian-config which suddenly started to flash my eMMC.
     
    The strange thing is that my keyboard seems to be just fine, no other application on my machine is "typing automatically". The screen during the flash is also seemingly broken.
     
    Did anyone experience the same?
     
    Thanks.
     
    (Is there another way to enable SPI without the armbian-config utility if it indeed seems to be broken?)

  15. Like
    manuti reacted to Tido in Etcher.io bug   
    Change is not always improvement. etcher.io v 1.2.1 burns fine.
  16. Like
    manuti reacted to jernej in H3/H5/A64 DRM display driver   
    Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).
  17. Like
    manuti reacted to balbes150 in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    Try to use the image 20180216. In the kernel with updated modules WiFi and added module sv6051.
     
    I pay attention all, in connection with change of sources, the module name for qca9377 changed, now it is called "wlan".
  18. Like
    manuti reacted to guidol in Orange Pi Zero H2+ Status LED   
    Well - the LEDs are not statically defined, because you can define their usage by yourself - and the OS can have another default funtion like on a other OS (Orange Pi original Linux <--> armbian)
     
    Your could find the available LEDs here:
    root@pihole:~# ls -l /sys/class/leds
    total 0
    lrwxrwxrwx 1 root root 0 Jan  1  1970 green_led -> ../../devices/platform/leds-gpio/leds/green_led
    lrwxrwxrwx 1 root root 0 Jan  1  1970 red_led -> ../../devices/platform/leds-gpio/leds/red_led
     
    and which function is assigned to the LED you could find out while do a "more" an their trigger-file:
    root@pihole:~# more /sys/class/leds/red_led/trigger
    none mmc0 mmc1 timer [heartbeat] backlight default-on
     
    here you could see I assigned the funtion [heartbeat] to the red LED
     
    I did this in the /etc/rc.local with the following command (before the line with "exit 0") :
    echo "heartbeat" > /sys/class/leds/red_led/trigger
     
    heartbeat is this flashing LED - showing the system is running
     
    mmc0 will be like a HDD-LED for your uSD-Card:
    echo "mmc0" > /sys/class/leds/green_led/trigger
     
    The names of your LEDs may varies.
     
  19. Like
    manuti reacted to balbes150 in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    fix
  20. Like
    manuti reacted to guidol in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    Mine DID boot without a dtb.img! (but didnt with the wrong .dtb)
    But I think - that I did read - that the system does try to use the right dtb by itself
  21. Like
    manuti reacted to balbes150 in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    Yes, the system tries to use the embedded dtb (from the eMMC), but this only works if the eMMC uses a the same kernel . For example, if the eMMC  installed has a version of LE that uses a similar kernel or Armbian\Linux.
  22. Like
    manuti reacted to Moklev in ARMBIAN for Amlogic S905 and S905X (ver 5.44 =<)   
    No, he can't.
     
    For the MXQ Pro 4k (SOC: Amlogic S905X) try first the file "gxl_p212_2g.dtb" (if 2GB... or xxx_1g.dtb if 1GB).
     
    In general:
    p212: for Amlogic S905X
    p200/p201: for Amlogic S905
    q200/q201: for Amlogic S912
    ... and other version for specific hardware (S912 100mbps or 1gpps, Weitek Play, Khadas VIM/VIM2, Realtek wifi, etc...).
  23. Like
    manuti reacted to guidol in Successfully built .img but failed to boot...   
    I did learn much here in the forum from "one to many" teaching or while reading problems and solutions of other boards/users.
    Mostly I could solve my problems while reading other post, just because its all armbian and it all board are arm-style

    The best for @jiapei100 will also to read a while in differnt threads and the armbian documentation - there are so many answers to questions.
    You could learn much from many users here - and maybe later someone from you - if you could faster answer to more easy questions.

    And if the armbian-forum isnt enough, then there are the forums of the board-manufacturers or the Facebook-Groups for this board
  24. Like
    manuti reacted to guidol in H2: Sunvell R69 Android TV Box (AliExpress)   
    Yes - if you do not only compile a Kernel - you will get a full image which can be written to uSD,
    BUT you need a 64Bit Ubuntu on your main computer and some disk space.
    The image will be written to ./build/output/images - for me thats /home/guido/build/output/images/
     
    Because I got it in a VirtualBox - I created only a 30GB Disk.
    Before compiling I have 9GB free Disk-Space and the build-process does warn me.
    But when I do compile for the R69 I have mostly ofer 6.7GB free (looking with df at the disks).
     
    On my QuadCore AMD 3GHz the compile does run in the frist try 26 Minutes.... later if I compile another image with other kernel then it could run as fast as 16 minutes (less download?)
     
  25. Like
    manuti reacted to raschid in H2: Sunvell R69 Android TV Box (AliExpress)   
    Good news but still odd: the legacy image's FEX file indicates a DRAM clock of 576MHz. Never mind, I created a pull request with an updated u-boot patch which should solve the issue for other users as well.
    Thx for raising the issue and the extensive testing
     
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines