Search the Community

I have a local OpenVPN server on Banan Pi M1, with latest armbian. I tried to replace with OrangePi3 but current results is disappointing iperf3 results on Banana Pi M1 OpenVPN server Connecting to host bouygues.iperf.fr, port 5201 [ 4] local 10.8.0.4 port 46250 connected to 89.84.1.222 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.69 MBytes 14.1 Mbits/sec [ 4] 1.00-2.00 sec 1.81 MBytes 15.1 Mbits/sec [ 4] 2.00-3.00 sec 2.43 MBytes 20.4 Mbits/sec [ 4] 3.00-4.00 sec 681 KBytes 5.58 Mbits/sec [ 4] 4.00-5.00 sec 1.99 MBytes 16.7 Mbits/sec [ 4] 5.00-6.00 sec 1.33 MBytes 11.2 Mbits/sec [ 4] 6.00-7.00 sec 1.55 MBytes 13.0 Mbits/sec [ 4] 7.00-8.00 sec 1.62 MBytes 13.6 Mbits/sec [ 4] 8.00-9.00 sec 1.33 MBytes 11.2 Mbits/sec [ 4] 9.00-10.00 sec 1.76 MBytes 14.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 16.2 MBytes 13.6 Mbits/sec sender [ 4] 0.00-10.00 sec 15.7 MBytes 13.2 Mbits/sec receiver iperf3 results on Orange Pi 3 OpenVPN server Connecting to host bouygues.iperf.fr, port 5201 [ 4] local 10.8.1.4 port 41583 connected to 89.84.1.222 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 621 KBytes 5.09 Mbits/sec [ 4] 1.00-2.00 sec 868 KBytes 7.11 Mbits/sec [ 4] 2.00-3.00 sec 1.18 MBytes 9.89 Mbits/sec [ 4] 3.00-4.00 sec 1.16 MBytes 9.75 Mbits/sec [ 4] 4.00-5.00 sec 1.02 MBytes 8.53 Mbits/sec [ 4] 5.00-6.00 sec 966 KBytes 7.92 Mbits/sec [ 4] 6.00-7.00 sec 726 KBytes 5.95 Mbits/sec [ 4] 7.00-8.00 sec 676 KBytes 5.54 Mbits/sec [ 4] 8.00-9.00 sec 2.58 MBytes 21.7 Mbits/sec [ 4] 9.00-10.00 sec 4.78 MBytes 40.1 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 14.5 MBytes 12.2 Mbits/sec sender [ 4] 0.00-10.00 sec 14.0 MBytes 11.7 Mbits/sec receiver As you can see, connection via OPi3 is slower, but more than that, it is unstabe and fluctuating from 5-8 MBit/s to 40 MBit/s What can I tune to improve openvpn connectivity?

These days i did install on some devices debian buster (via armbian-build-system generated). On the Orange Pi One this did work also fine with the cpu-temperature (showing via armbianmonitor -m) On a Orange Pi PC2 and a NanoPi K1 Plus this doesnt work. First I did think this is a problem of the dev-image with debian buster where /sys/devices/virtual/thermal/thermal_zone0/temp doesnt show an output via cat or more - but its filesize does show a 4096 bytes size (also on a working device - and also rights 444 = rrr for the file): -r--r--r-- 1 root root 4096 May 20 10:47 temp BUT NOW after a apt update & apt upgrade I also got this "problem" on a NanoPi Neo2 LTS with a stable debian stretch image: Welcome to ARMBIAN 5.85 stable Debian GNU/Linux 9 (stretch) 5.1.0-sunxi64 package bsp-kernel[5.86] u-boot[5.85] dtb[5.86] firmware[5.83] config[5.86] with armbianmonitor -m the stretch and buster devices does show the following error: Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 11:14:59: 1008MHz 0.22 7% 4% 2% 0% 0% 0%/usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected and the devices with this error got these - for me - new error messages about thermal in the dmesg: [ 6.727971] OF: /thermal-zones/cpu-thermal: arguments longer than property [ 6.728007] OF: /thermal-zones/cpu-thermal: arguments longer than property armbianmonitor -u for the NanoPi Neo2 LTS: http://ix.io/1JNA root@npi-neo2-24(192.168.6.24):~# armbianmonitor -u System diagnosis information will now be uploaded to /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected /usr/bin/armbianmonitor: line 385: read: read error: 0: Invalid argument /usr/bin/armbianmonitor: line 386: [: -ge: unary operator expected http://ix.io/1JNA Please post the URL in the forum where you've been asked for.

Looking to purchase a tablet with Android to run Armbian Desktop on. Any suggestions? Looking at the FreakTab forum and see a bunch of tablets listed but no subtopics of removal of Android. Here I was able to install Ubuntu just fine on my Intel based Pipo X7.

I'm only just getting started with this project. So far I have gotten a lot of help from some great people and looking to get further along with this project as time goes on. My main goal is to turn the tinkerboard into a linuxcnc control system with a drop in SDcard/EMMC image(s). The images will be preloaded with everything needed to setup a cnc machine for different control systems such as GPIO, ETHERNET, SPI depending on one's choice or needs for control. The gpio will provide direct step/dir, end stops, router power control signals, etc.... the normal cnc machine control logic one would expect when using a parallel port. Ethernet and SPI will be options for anyone using drivers like the MESA controllers for example. At this point I have the working and current FULL preempt RT images and kernel DEB packages for any one looking to build or install. I have posted the files HERE. I have a working image setup with linuxcnc already compiled, and 3d/opengl video drivers fully working. If anyone is interested or willing to host the multi gig file let me know. CURRENTLY HAL for SPI, GPIO and ETHERNET are not built. These are areas I'm looking for help. Also at this point I could really use a hand with TUNING the build or tuning options for compiling the kernel if any. I'm weak in regards to software, strong in the hardware as well the electronics side. The last few issues I'm having are with the driver support for my LCD. it is not currently working at all. I have a raspberry pi 7" LCD with a native res. of 1024x600. I have to run it at 1024x768 which stretches the image a bit as well makes smaller print harder to read. The other issue though more of a personal one, I have an I2C RTC setup but i2c is not fetching the TIME/DATE but rather seeking network time. I do not know how to fix this and the few febal attempts I've made, I discovered that armbian has been rather locked down to use network time rather then seek multi sources for current time. I'm currently on the kernel 4.19 full preempt RT kernel. If anyone is interested in seeing photos of the project and the VERY custom mold and shell I built for this project check this LINK I've gotten a lot of positive feed back on it so far.

with the armiban-build-system I did build some dev-images. Sometimes I see in other threads, that later build images have newer kernel or package versions. While trying apt update && apt upgrade I didnt get these newer packages So my first try was to use the armbian-build-system and do use the function for creating u-boot and kernel that will give me some .debs in ./build/output/debs/ like this: linux-u-boot-dev-nanopineo2_5.82_arm64.deb linux-dtb-dev-sunxi64_5.82_arm64.deb linux-image-dev-sunxi64_5.82_arm64.deb linux-headers-dev-sunxi64_5.82_arm64.deb linux-source-dev-sunxi64_5.82_all.deb install these (mostly I didnt do that for the headers and source) with dpkg -i will result in higher package numbers, but not for the armbian / bsp-kernel version for getting here the right version I have to compile (again) - now - the a whole OS-image to get linux-stretch-root-dev-nanopineo2_5.82_arm64.deb in ./build/output/debs/stretch If you did install also this .deb with dpkg -i I do get the right/higer armbian/bsp-kernel-version: Welcome to ARMBIAN 5.82 user-built Debian GNU/Linux 9 (stretch) 5.0.7-sunxi64 package bsp-kernel[5.82] u-boot[5.82] dtb[5.82] firmware[5.79] config[5.81] armbian-config does update via apt update && apt upgrade I try to update this way because I didnt want to use a whole new OS-image and reconfigure it. But I think it isnt the right way to update, when I have to compile 2 times on to get the root-deb Is there another way to generate this file? And is there a way to not generate the headers and source .debs? The source .deb take a while because it is getting as big as 370MB Is there a better way or does nobody other like me update this way?

Hi Everyone. I'm having trouble updating to TLS 1.2 on my pcDuino 3 and cannot connect to any website other than Google.com or pinging 8.8.8.8 See attached return from my terminal when attempting to run "sudo apt-get update && sudo apt-get install --only-upgrade openssl" Seems http://www.wiimu.com from what I can tell is a server from a company called LinkSprite. I think the company has disbanded and no longer offers any services… Also seems LinkSprite was lead/CEO by a guy named Jingfeng Liu who is the creator of pcDuino. Also Link Sprite does not monitor their forums nor respond to queries of any sort. There’s got to be an alternative to updating the SSL certs… Has anyone updated their TLS lately? Updating SSL_pcDuino

Release WIP and CSC images from their own page with very specific limitations, including, but not limited to: no kernel or u-boot updates, ideally with the kernel and u-boot package names modified with -unsupported- Explain these are demo snapshot images, potentially even package a different wallpaper that has -unofficial- or something similar watermarked across it. Maybe even use the default WM theme.

Is everybody being hit with custom & handling charges via royal mail? Added a total of £11.72 to my OrangePi H3 plus2 £3.72 customs and £8.00 handling charge. Its no bother as just curiosity with Smaller format boards but just wondering is this a Brexit shape of things to come?

Just wanted to announce that Armbian-NG (https://github.com/AndrewBCN/Armbian-NG/) has been chosen as the OS to power the new CNX Election Meddling System (https://www.cnx-software.com/2019/04/01/introducing-cnx-election-meddling-system/). Why? Because Python. Have a nice day and don't forget to vote!

Hi, I am looking for a device, which has the following hardware: - 2x wifi adapter - 2x ethernet adapter - CSI connector for camera - 2x USB port or 1x USB and 1x USB-C port I know it would be very hard to find such a device, but an option would be to use one USB port and WiFi dongle instead second build-in WiFi and another USB to connect ethernet dogle into it. And for USB-C I can use use an USB-C-to-USB adapter... So at least I would like to find a device with: - 1x wifi adapter - 1x ethernet adapter - CSI connector for camera - 2x or 3x USB port Any ideas?

Some SBCs, such as PIneA64, provide a built-in RTC on-board while others do not. For those boards that do have a built-in RTC, it appears the kernel driver is configured as a builtin rather than as a module at least in some cases (I only checked a few). This in turn brings up a question: For boards that include a built-in RTC and also have the respective kernel driver configured as a built-in, should the kernel configuration to also set the system clock from that RTC (RTC_HCTOSYS) be enabled by default? There is a dependency that the RTC be built-in as the kernel will try to read from the RTC rather early, before any loadable modules would have been loaded. That would potentially preclude this from being a common default, but doesn't necessarily need to. For cases where this can be done, this has the advantage of not requiring separate user-space accommodations. For distributions based on systemd there are sadly a very large number of discussions and proposals on how to set the system time from RTC at boot time but also sadly there is no standard nor common solution. /lib/udev/hwclock-set explicitly exits without setting the system clock if systemd is found, and systemd will not read the RTC itself expecting to use a network time source (NTP) instead. Having the kernel set system time from RTC would happen a bit earlier than any user-land option which would result in consistent and correct timestamps on files created/modified during startup as well as in various logs. It may not be a perfect nor complete solution, but where possible does this seem like something that could/should be done?

Hi, I bought the edimax EW-7822ULC usb wifi device (based on rtl8822). I was able to build the driver, install it, and test it (works!). Edimax provides the sources on their site. Is anyone working on incorporating this into Armbian? Steve

I'm a newbie to Armbian, just a hobby user, no company behind me. While building Armbian for my Banana Pi R1 (aka Lamobo R1) [Allwinner A20, sunxi] the build system gave the following warnings originating from the U-Boot project. I think some maintainers and/or experienced users should take a look at the following. ===================== WARNING ====================== This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_VIDEO Please update the board to use CONFIG_DM_VIDEO before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== Here's also the full content of the file ./cache/sources/u-boot/v2019.01/doc/driver-model/MIGRATION.txt :

In the following window the cursor keys (arrow up, down, left, right) aren't working: the raw terminal control chars appear instead. And the window is kind of "distorted" (for example the G char of General setup appears at the right side of the window, same with the following lines): Tried in a X console as well on tty8, same behavior. One can press only CTRL-C to get out of this window, this of course also aborts the build: How to fix this? My system: x86_64 Debian 8 (jessie) with LXDE desktop, using a Debian 8 in a LXC container for building Armbian for an A20 device. .config - Linux/arm 4.19.25 Kernel Configuration ────────────────────────────────────────────────────────────────────────────── ┌──────────────── Linux/arm 4.19.25 Kernel Configuration ─────────────────┐ │ Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty │ │ submenus ----). Highlighted letters are hotkeys. Pressing <Y> │ │ includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to │ │ exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │neral setup ---> │ │ │ │aximum PAGE_SIZE order of alignment for DMA IOMMU buffers │ │ Sy │ │Type ---> │ │ B │ │pport ---> │ │ K │ │ Features ---> │ │ B │ │ptions ---> │ │ C │ │wer Management ---> │ │ F │ │ng point emulation ---> │ │ P │ │management options ---> │ │ │ └────┴(+)─────────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────────────────┤ │ <Select> < Exit > < Help > < Save > < Load > │ └─────────────────────────────────────────────────────────────────────────┘

Hi everyone, I'm building a micro server based on orange pi prime and armbian, after reading a lot about sd card wear out, I started thinking how could I improve that in my project. For my project it is ok, if data would be physically written to card, every 1 minute instead of on every commit. Now, what I can't find: is there a way to generally configure such memory buffering for a filesystem, so that I don't have to configure this for a database engine?

Hi, while toying around build system for Odroid C1 I saw that toolchains for arm-linux-gnueabihf where "old" as we are at "gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf" since the 7.3.1 looks like it is not available for this platform. So I did some changes in lib/general.sh and added the following as a fast hack: "https://releases.linaro.org/components/toolchain/binaries/7.4-2019.02/arm-linux-gnueabihf/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf.tar.xz" "https://developer.arm.com/-/media/Files/downloads/gnu-a/8.2-2019.01/gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabihf.tar.xz" Then I modified the configuration files for odroidc1 to test both toolchains (namely config/sources/odroidc1.conf) and I produced working images with both toolchains. Personally (but without any scientific approach) I saw: 7.4.1 it looked like very slow to compile... maybe my system was busy doing other things maybe not 8.2 produced a smaller kernel (with same .config) and its speed was acceptable Is there a reason that arm-linux-gnueabihf is stil at 7.2.1 (2017.11)? Thanks in advance *Bye Piero

Hi there, I was playing around with the new sun6i-csi driver and was able to capture up to 800x600, but if I try to capture with a higher resolution it will always fail: fswebcam -S 5 -d /dev/video0 -r 1600x1200 -p YUV420P test.jpg --- Opening /dev/video0... Trying source module v4l2... /dev/video0 opened. No input was specified, using the first. [ 2313.151304] sun6i-csi 1cb4000.csi: Wrong width or height 1600x1200 (800x600 expected) Error starting stream. VIDIOC_STREAMON: Broken pipe Unable to use mmap. Using read instead. Unable to use read. I have also tried to set a higher resolution with v4l2-ctl beforehand. It doesn't make an difference. v4l2-ctl --set-fmt-video=width=1600,height=1200,pixelformat=YUV420P I'm using a OV2640 with a maximal resolution of 1600x1200. This piece of code throws out the error message (from sun6i_video.c): if (source_fmt.format.width != video->fmt.fmt.pix.width || source_fmt.format.height != video->fmt.fmt.pix.height) { dev_err(video->csi->dev, "Wrong width or height %ux%u (%ux%u expected)\n", video->fmt.fmt.pix.width, video->fmt.fmt.pix.height, source_fmt.format.width, source_fmt.format.height); return -EPIPE; } video->mbus_code = source_fmt.format.code; return 0; } Maybe someone can help me with that. thanks

Hello, I have had a look to the new Development Image (Armbian_5.76.190228_Tinkerboard_Debian_stretch_dev_5.0.0-rc8_desktop.7z) My SixFfab Hat which was working like a charm on 4.19-20 kernel. Any changes to add supoort for this Hardware again? Do you need any additional information? Many Thanks Roman

Hi all. Since I wanted a 3D intro for my Youtube Channel I started working with Blender again. Now the intro is finished I've got time to try to make a 3D Armbian Logo. I'll show some of the progress here for those who are interested. And if anybody else wants to do the same, go ahead. We can then compare the results. I've only just begun. But I needed a break so I started writing this. Here's how it begins... create a side view ...  Then put those pictures in Blender, add a cube, position it right on both pictures, and start modeling.... All done with the NanoPi M4 on Armbian Bionic. I'll slowly keep working on it. I can't promise it will look great, but nothing is lost if it doesn't... Someone once asked me to do this, I can't remember who it was. I think Chwe or jmcc or tido. Could also have been a ghost in my sleep. Cheers, NicoD ps: @Igor It would be nice if we could easily resize images in our posts. Maybe with a dropdown box and % would be easiest to do. I know this isn't a priority, just a suggestion.

https://github.com/StuartIanNaylor/log2ram/tree/log2zram git clone --single-branch --branch log2zram https://github.com/StuartIanNaylor/log2ram /etc/log2ram.conf says it all. # Configuration file for Log2Ram (https://github.com/azlux/log2ram) under MIT license. This configuration file is read # by the log2ram service Size for the ram folder, it defines the size the log folder will reserve into the RAM. If it's # not enough, log2ram will not be able to use ram. Check you /var/log size folder. The default is 40M and is basically # enough for a lot of applications. You will need to increase it if you have a server and a lot of log for example. # Above is log2ram original size increased to 80M zram. Assuming 3:1 LZO compression ram usage should be reduced to # 26.66M. Size is in MB SIZE=80 # This variable can be set to true if you prefer "rsync" rather than "cp". I use the command cp -u and rsync -X, so I # don't copy the all folder every time for optimization. You can choose which one you want. Be sure rsync is installed # if you use it. USE_RSYNC=false # If there are some errors with available RAM space, a system mail will be send Change it to false and you will have # only a log if there is no place on RAM anymore. MAIL=true # Big cores should only be counted really but this is where you can dictate zram stream count Default is 1 and settings # can be edited to personal taste. # BIG_CORES=0 Disables zram BIG_CORES=1 # Free mem factor deb is 505 I concur that 75 is better but its open. Free mem factor is just the fraction of # free mem used for swap drive total Drive size = Free_Mem * mem_factor / 100 / Big_Cores # So if you want .75 of total mem make mem_factor 75 as divided by 100 to avoid float usage MEM_FACTOR=75 # Compression algorythm either LZ0 or LZ$ COMP_ALG=lzo # ZLTG flag means use ZRAM ramdisk for log2ram true=enable / false=disable ZLTG=true # SWAP_PRI sets swap_priority of zram streams set by big_cores default=75 SWAP_PRI=75 Just gives you a bit more control than zram-config_0.5_all.deb but basically is just that and log2ram in a single package. Any issues tips or ideas give us a shout here or github

This is some more research based on prior efforts. The goal is to make more efficient use of available RAM. If the system runs low on memory only two options are possible: either the kernel invokes the oom-killer to quit tasks to free memory (oom --> out of memory) or starting to swap. Swap is a problem if it happens on slow media. 'Slow' media usually describes the situation on SBC. 'Average' SD cards (not A1 rated) are slow as hell when it's about random IO performance. So swapping is usually something that should be avoided. But... technology improves over time. In Linux we're able to swap not only to physical storage but since a few years also to compressed memory. If you want to get the details simply do a web search for zram or check Wikipedia first.. Test setup is a NanoPC-T4 equipped with 4 GB RAM (RK3399 based so a big.LITTLE design with 2xA72 and 4xA53). I crippled the board down to being a quad-core A53 running at 800 MHz where I can easily switch between 4GB RAM and lower numbers: Adding 'mem=1110M maxcpus=4' to kernel cmdline results in the A72 cores being inactive, the kernel only using 1 GB DRAM and for whatever reasons cpufreq scaling not working so the RK3399 statically being clocked at 808 MHz. All tests done with RK's 4.4 (4.4.152). This test setup is meant as 'worst case possible'. A quad-core A53 at 800 MHz is more or less equivalent to a quad-core A7 running at ~1000-1100 MHz. So we're trying to test with the lower limit. I used a compile job that requires up to 2.6 GB RAM to be built (based on this blog post). The task is to build ARM's Compute Library which involves swapping on systems with less than 3 GB memory. Let's have a look: In the following I tried a couple of different scenarios: Swap on physical media and also two different zram algorithms: w/o: no swapping happened since board booted with full 4GB RAM active nvme: Transcend TS128GMTE110S SSD in M.2 slot, link is established at x4 Gen2 emmc: the 16GB ultra fast Samsung eMMC 5.1 on NanoPC-T4 usb2: Samsung EVO840 SSD in JMS567 disk enclosure, attached to USB2 port (UAS works) usb3: Samsung EVO840 SSD in JMS567 disk enclosure, attached to USB3 port (UAS works) hdd: Samsung HM500JI 2.5" HDD in JMS567 disk enclosure, attached to USB2 port (UAS works) sd card: 'average' SanDisk 8 GB SD card (not A1 rated so horribly low random IO performance) lzo: zram with lzo as compression algorithm lz4: zram with lz4 as compression algorithm And the numbers are: w/o nvme lzo lz4 emmc usb2 usb3 hdd sd card real 100m39 118m47 125m26 127m46 133m34 146m49 154m51 481m19 1151m21 user 389m48 415m38 405m39 402m52 415m38 415m29 407m18 346m28 342m49 sys 11m05 29m37 36m14 60m01 34m35 66m59 65m44 23m05 216m25 You need to look at the 1st row: that's the time the whole job took. For more details consult the 'time' manual page. In other words: When limiting the RK3399 on NanoPC-T4 to just the four A53 cores running at 800 MHz the compile job takes 100 minutes with 4 GB RAM. As soon as we limit the available RAM to 1 GB swapping has to occur so it gets interesting how efficient the various approaches are: NVMe SSD is the fastest option. Performance drop only 18%. That's due to NVMe being a modern storage protocol suited for modern (multi-core) CPUs. Problem: there's no PCIe and therefore no NVMe on the majority of SBC Zram with both lzo and lz4 algorithms performs more or less the same (interestingly lzo slightly faster) Slightly slower: the fast Samsung eMMC 5.1 Surprisingly the EVO840 SSD connected via USB2 performs better than connected via USB3 (some thoughts on this) Using a HDD for swap is BS (and was BS already the last 4 decades but we had no alternative until SSDs appeared). The compile job needs almost 5 times longer to complete since all HDD suck at random IO Using an average SD card for swap is just horrible. The job that finished within 100 minutes with 4 GB DRAM available took over 19 HOURS with swap on an average SD card (please note that today usual A1 rated SD cards are magnitudes faster and easily outperform HDDs) Summarizing: NVMe SSDs are no general option (since only available on some RK3399 boards). Swap on HDD or SD card is insane. Swap on USB connected SSDs performs ok-ish (~1.5 times slower) so the best option is to use compressed DRAM. We get a performance drop of just 25% at no additional cost. That's amazing. The above numbers were 'worst case'. That's why I crippled the RK3399 to a slow performing quad-core A53. You get the idea how 'worse' zram might be on the slowest SBCs Armbian runs on (I know that there are still the boring Allwinner A20 boards around -- yep, they're too slow for this). When I did all this boring test stuff I always recorded the environment using 'iostat 1800' (reports every 30 minutes what really happened and shows in detail how much data has been transferred and on which the CPU cores spent time). Quite interesting to compare %user, %sys and especially %iowait percentages:

Hi all, sbc-bench is now on Github: https://github.com/ThomasKaiser/sbc-bench I'll link from the README there to this thread for further discussion about the tool and proper benchmark methodology.

With this commit I added 7-zip benchmark reporting to Armbian now. Will be available after next updates and with next batch of new images. Why not recommending to just do an 'apt install p7zip ; 7zr b'? Since 'fire and forget' benchmarking is always BS. You need some monitoring in parallel to know whether your system was really idle and at which clockspeeds the CPU cores were operating (throttling occuring or not?). Most recent 7-zip contains an own routine to 'pre-heat' the system prior to starting the benchmark (to let cpufreq scaling switch from low clockspeeds to highest ones and e.g. on Intel systems let the system enter TurboBoost modes). This 7-zip code runs single threaded so based on the kernel's scheduler sometimes ending up on the 'wrong' CPU core (e.g. a little core on big.LITTLE SoCs) On a NanoPC T4 with conservative settings (limiting big CPU cores to 1.8 GHz and little cores to 1.4 GHz) this looks like this: root@nanopct4:/home/tk# armbianmonitor -z Preparing benchmark. Be patient please... 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE) LE CPU Freq: 1413 1414 1414 1411 1413 1414 1414 1414 1415 RAM size: 3878 MB, # CPU hardware threads: 6 RAM usage: 1323 MB, # Benchmark threads: 6 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 3642 363 976 3543 | 98020 543 1540 8359 23: 3691 365 1030 3761 | 95217 541 1522 8239 24: 3606 354 1094 3878 | 92662 535 1520 8133 25: 4597 451 1164 5249 | 89079 529 1498 7928 ---------------------------------- | ------------------------------ Avr: 383 1066 4108 | 537 1520 8165 Tot: 460 1293 6136 Monitoring output recorded while running the benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:16:19: 1800/1416MHz 0.12 12% 1% 7% 2% 1% 0% 44.4°C 0/5 10:16:25: 408/ 600MHz 0.11 0% 0% 0% 0% 0% 0% 43.9°C 0/5 10:16:30: 600/1416MHz 0.10 1% 0% 0% 0% 0% 0% 45.0°C 0/5 10:16:35: 1800/1416MHz 0.17 40% 0% 39% 0% 0% 0% 49.4°C 0/5 10:16:40: 1800/1416MHz 0.32 77% 0% 77% 0% 0% 0% 55.0°C 0/5 10:16:45: 1800/1416MHz 0.94 73% 0% 72% 0% 0% 0% 51.1°C 0/5 10:16:50: 1800/1416MHz 0.94 65% 0% 65% 0% 0% 0% 53.3°C 0/5 10:16:55: 1800/1416MHz 1.19 68% 0% 67% 0% 0% 0% 56.1°C 0/5 10:17:00: 1800/1416MHz 1.49 79% 1% 78% 0% 0% 0% 53.9°C 0/5 10:17:06: 1800/1416MHz 1.45 31% 0% 31% 0% 0% 0% 57.8°C 0/5 10:17:11: 1800/1416MHz 2.07 68% 0% 67% 0% 0% 0% 57.2°C 0/5 10:17:17: 1800/1416MHz 2.30 78% 0% 77% 0% 0% 0% 58.9°C 0/5 10:17:22: 1800/1416MHz 2.52 90% 1% 89% 0% 0% 0% 57.8°C 0/5 10:17:27: 1800/1416MHz 2.72 81% 0% 80% 0% 0% 0% 57.2°C 0/5 Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:17:32: 1800/1416MHz 2.66 61% 0% 60% 0% 0% 0% 60.6°C 0/5 We get an overall score of above 6100 and 7-zip's 'CPU Freq' line reports CPU0 (a little core) being clocked at 1.4 GHz. But since this is a big.LITTLE design we need the monitoring output that gets displayed below 7-zip benchmark numbers. By looking at the 2nd line we see that the system was totally idle prior to starting the benchmark (I implemented a 10 second sleep between starting monitoring and firing up the benchmark for this reason -- to control whether the system was already busy or not). As a comparison 7-zip numbers of another RK3399 board that allowed the CPU cores to clock slightly higher (2.0/1.5 GHz): ODROID-N1 scored 6500. As a reference some other boards. Rock64 with new 1.4 GHz settings: NanoPi NEO with cpufreq scaling limited to 816 MHz to keep the board always at lowest DVFS voltage (results irrelevant) Please keep in mind that benchmarks that run fully multi threaded are NOT representative for most workloads running on computers (they're single threaded). Also please keep in mind that while 7-zip is not that much affected by different compiler settings (like the infamous sysbench) of course it is somewhat. So when you see 7-zip benchmark numbers generated few years ago when the 7z binary has been built with a GCC 4.x most probably with today's software and a binary built by GCC 7.x you see higher scores. So take these comparison numbers with a grain of salt: https://s1.hoffart.de/7zip-bench/ To get new armbianmonitor with -z functionality today it's as easy as wget -O /usr/bin/armbianmonitor https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/bin/armbianmonitor

Clearfog PRO with Linux 4.12.4-mvebu Samsung 840 PRO utilization: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 62501 101691 98761 94430 34522 93050 102400 16 183325 215091 231439 232948 101667 171875 102400 512 301985 307789 341261 344567 328849 309560 102400 1024 294818 309177 345099 347791 339763 309775 102400 16384 271066 344426 384226 388587 387169 346825 2 x Samsung 840 PRO in RAID0, ext4 utilization: random random kB reclen write rewrite read reread read write 102400 4 67614 95508 94561 94984 32561 74157 102400 16 174075 200947 222430 223840 109654 199578 102400 512 307905 294689 317652 308007 307057 268841 102400 1024 307821 317784 327007 330213 322851 317024 102400 16384 286193 383463 394221 398474 397951 374333 Logs: http://sprunge.us/CfRS Controller temperature is stable at 64°C, network utilization is also at top speed. Card was donated via Amazan wish list. Thank you! Hummingboard 2 with Linux 3.14.79-cubox (mainline not working out of the box) Not that impressive as Clearfog, but works. random random kB reclen write rewrite read reread read write 102400 4 28502 39271 37895 37983 22325 38821 102400 16 68494 80988 69940 70511 53264 80047 102400 512 116594 118132 93789 94280 92828 118884 102400 1024 138185 140277 122610 123717 120853 139393 102400 16384 183976 183169 151745 153813 151890 179652 Logs: http://sprunge.us/OeMY Espressobin 2 x Samsung PRO 840, RAID 0, BTRFS http://sprunge.us/iBFS random random kB reclen write rewrite read reread read write 102400 4 21547 20493 37509 37024 21747 17728 102400 16 61955 56230 93068 93795 64349 45724 102400 512 188611 186828 175688 176961 172098 185109 102400 1024 215817 216559 189477 191846 188481 214727 102400 16384 226764 228502 229162 238883 222826 229894 Intel N4200 / Up2board Square 1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 65003 76031 93147 92507 32024 73029 102400 16 146880 175968 187734 224409 106025 163916 102400 512 244782 225736 348401 357949 343145 221037 102400 1024 239203 247778 313476 313372 309170 248540 102400 16384 254396 266530 357708 368483 370731 276458 2 x Samsung 840 PRO in RAID 0 random random kB reclen write rewrite read reread read write 102400 4 61680 70018 67650 66635 18221 67984 102400 16 145869 164784 147884 143877 46355 160169 102400 512 230140 219870 213069 199087 213587 210607 102400 1024 273150 271782 257206 279397 275632 271896 102400 16384 314895 311385 365117 376228 375081 317790 Native onboard SATA 1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 70611 80842 100647 97276 30072 77666 102400 16 194707 208422 239401 224119 102211 218393 102400 512 346735 410867 401536 425167 396013 412711 102400 1024 374032 366490 378981 394321 382352 368195 102400 16384 441298 430380 475063 486540 482151 414518 Reference: A20's native SATA This document is work in progress ...

Starting to work on lets call it the "dogafu" experiment (don't give a fuck about recommendations). This would combine my threads about powering & bad SD-Cards. Cause I want do something useful and not just crash armbian on a system, from which I know that it would happen, I decided to do not only stupid tasks on my OPi zero. I could just hammering the SD-Card with a webcam and motion until it crashes and write on this thread 'opi 0 with terrible setup crashes after x days'. But, nobody would read this thread cause it's not interesting for anyone. We know that this would happen and for those users who don't know, there's nothing of interest in this thread. Since thermal throttling on the opi zero seems to be a real issue and there's a lack of information, that the temperature readouts from the SoC are correct, I decided to connect a DS18b20 to the OPi0 and let it measure the temperature of the SoC. Everything was installed on ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i. Hooking up the DS18b20: First we edit the configuration file and uncomment the w1 modules with sudo nano /etc/modules-load.d/modules.conf and cause onewire does not work properly @240 MHz we had also to change MIN_SPEED to 480000 with: sudo nano /etc/default/cpufrequtils after a shutdown we can connect the DS18b20 on GPIO10 (Data, physical pin 26), VCC to one of the 3.3V (physical pin 1 or 17) and ground (physical pin 6,9,14,20 or 25) don't forget to have a 4.8kOhm resistor betwenn VCC and Data! If you want to have your data pin not on GPIO10 you have to modify the script.bin with bin2fex /boot/script.bin /tmp/orange.fex followed by nano /tmp/orange.fex and change the GPIO in the [w1_para] section (example for using of GPIO6 for DS18b20): sudo fex2bin /tmp/orange.fex /boot/script.bin and a reboot is needed to activate this settings. Im everything works correctly sudo armbianmonitor -m should show that the cpu frequency would not go below 480MHz (otherwise DS18b20 would not run smoothly). Go to cd /sys/bus/w1/devices/ we can see our sensor with ls. It should start with something like 28-XXXXXXXXXXX. cat 28-0517010cbeff/w1_slave should show our actual temperature. So the actual temperature in my room is 23.562°C (IMO forget about everything behind the °C, proper precise temperature measurement isn't trivial and needs calibration which is not possible without professional equipment). Send data to an other device: Cause this setup with bad powering & a corrupt SD card will brick and I do not want to lose the collected data, I decided to send all the data to a second, proper running, OPi 0 via mqtt. This will be done by some bash scripts and crontab (it would be possible to do this only with crontab, but cause I may use this scripts on other devices for other purposes it's easier to have them isolated). For this, I installed a mqqt client with sudo apt-get install mosquitto-clients. After installation, we test if the client can publish on an other device with: mosquitto_pub -h 192.168.x.xx -t test -m "everything works ;-)" (-h ip oft the mqtt broker, -t topic to publish -m msg.payload). On my second OPi 0 with node-red and mosquitto we should see that the message arrived (installation of node-red and mosquitto). (with #, we subscribe to every topic on the mosquitto broker) Bash script & crontab: IMO the easiest way to send data periodically is to generate a small bash script which includes all the tasks and then setup a crontab to start this bash script. The scritp was saved in /home/opi/scripts/ with nano scriptname the script was generated (It might be possible to do this tasks without a bash script but since I'll reuse parts of it i decided it's the lazy way to do it.): Cause cpu infos are only available as root, crontab must run under root privileges. Add a new crontab with sudo crontab -e (1 for edit with nano). This crontab will start our script every minute: Cause this script runs now with root privileges, this might be a security risk so make sure that no one has access to your OPi! Now it's time to set up everything in node-red to get our results visible. I added dashboard to node-red to have some nice UI templates (usage of node-red & how to set up can easily learned by google . FYI: This is an ongoing project. At the moment, everything runs on a reliable SD-Card and the DS18b20 is not properly mounted on the SoC (waiting for thermal paste). As soon as I have everything setted up, I'll put it on the bad SD-Card with a cheap phone charger to see how stable it runs.