tkaiser

Hmm... I don't think so. In situations with more than one NIC connected to the same subnet 'funny' things happen and I'm already curious how many many many new threads caused by this will flood the forum soon. Hmm... I don't think so since they use more or less the same settings/software. Only difference between OPi Zero and R1 image is u-boot version (2017.05 vs. most recent now) and I would assume that somehow affects thermal calibration and the numbers the thermal sensor seems to spit out. Or do you measure real temperatures at chip surface? Well, Xunlong (or the guy they pay/paid for software support) surprised us many times and I prefer to not monitor Orange Pi forum so I was waiting all the time for a confirmation that their most recent image running on the real hardware provides working Wi-Fi. All the babbling in this thread the last months took way longer than doing the real work (especially in this case where mainline kernel device-tree stuff can be shared between Zero and R1)

My OMV installation routine was at fault (cause/fix), it only affects installations with IPv6 propagated through DHCP (that's why I did not notice since my lab is IPv4 only) and is fixed at least on the XU4/HC1 image in the meantime. Most probably only C2 image affected any more (and maybe C1 image). Still waiting for C2 being usable with btrfs and next kernel in general. Then I'll regenerate the image. In the meantime affected users should take care that IPv6 is temporarely disabled when they boot their OMV image the first time.

Ok, this looks good. MAC address of the RTL8152 is persistent accross reboots and wlan0 comes up (the same weird 'load module twice' workaround needed as on Beelink X2) https://github.com/armbian/build/commit/e7f363c363244da602a908903b9ad247d4c335f8 Thank you again for the support!

So there is either no cpufreq support or the numbers are bogus? Anyway, the mostly useless sysbench pseudo benchmark can be used funnily for exactly this: estimating at which clockspeed a specific CPU is running if CPU architecture and build options for the binary are known (easy with upstream distro packages). Can you please execute sysbench –test=cpu –cpu-max-prime=20000 run –num-threads=4 sysbench –test=cpu –cpu-max-prime=20000 run –num-threads=2 sysbench –test=cpu –cpu-max-prime=20000 run –num-threads=1 find /sys -name "scaling_available_frequencies" cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state armbianmonitor -u

Here's http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Orangepi-r1_Ubuntu_xenial_default_3.4.113.img.xz based on the fex contents from there (MD5 sum: 566d614f3bc7a0dd27e2bd848be6f5ee) Please connect a single Ethernet cable to one of the two ports, boot it, login through network or serial console, if the image asks for a reboot (likely due to rootfs resize), then reboot and finally provide output from 'armbianmonitor -u' and iwconfig. Please note that /etc/network/interfaces is empty on this image so you either configure everything with nmtui (recommended) or fiddle around filling this file. But at least I would be interested in results from using nmtui only, configuring both eth interfaces with static or dynamic settings and also activate Wi-Fi (if possible). Then of course 'armbianmonitor -u' and iwconfig again

Ok, no change to the stuff I looked into already in August. Preliminary support added, now building an image. Thank you!

That would be great. Or at least I need to know which clockspeeds are used (I know nothing about current state of Le Potato kernel, whether cpufreq/DVFS is already working and if it's working how throttling is configured). I assumed S905X would run with 1500 MHz but both openssl and especially 7z numbers are too low for that. I know and that's the reason I was asking for tinymembench numbers (low 7-zip compression speed is often related to high memory latency).

Well, thanks for confirming that it is an 8189ETV. Then we have the following 'issues': https://forum.armbian.com/topic/4933-orange-pi-r1/?do=findComment&comment=37681 https://forum.armbian.com/topic/4933-orange-pi-r1/?do=findComment&comment=37745 In other words: As already explained in this thread it's absolutely useless to try out this board with mainline kernel yet (since driver not ready) and there might be different settings needed to correctly get the Wi-Fi module running. So we know we have no schematics that correctly describe the hardware, we know that Xunlong's own OS image correctly enables Wi-Fi, I asked several times in the meantime for a few bits of information (the f*cking fex file, lsmod and dmesg output!) and what happens instead? Not the needed information is provided but people only try what can't work as already explained. Please also note that all three links above are from this very same thread here. It's frustrating.

Well, giving up on the approach now. It took 7 months to get at least some sparse information wrt swap usage on real-world Armbian installations and I clearly don't want to wait another few months to see any improvements. Relying on systemd-swap or any other already existing 'solution' will not work that great 'on Armbian' since all those attempts are made only for x86 situation (requiring recent kernels, no big.LITTLE problem, zswap better than zram and so on). Emergency swap is fine... Edit: systemd-swap's zram activation routine (which while being the only part of interest on SBC is disabled by default) needs to be rewritten entirely anyway to work properly or at all on Armbian.

Ok, let's stop (I neither understand what you're doing now either on an 'orangepione' or using the image for this board nor do I understand why you claim 8189es is wrong and still try to load the module). None of us devs has this board yet (Xunlong for whatever reasons never sent out the promised dev samples), there are no schematics that match reality released, I assumed it would be 8189ETV based on pictures of the board, you're the first user having the hardware in his hands pointing out that it's 8189FTV in reality (true?). Edit: Realized that it reads 'orangepirone' and not 'orangepione' -- though still a waste of time...

Can you try the following please on the image with legacy kernel and report back: echo 'blacklist 8189es' >/etc/modprobe.d/blacklist-8189es.conf update-initramfs -u reboot

With latest commits it's now implemented like this: zram-config added to Xenial default package list firstrun checks for this package and if installed will neither create a swap file nor write vm.swappiness=0 to /etc/sysctl.conf nand-sata-install (hopefully) learned to deal with what's configured and will honor existing settings when transferring installation So only new Xenial images are affected currently since there SD card based swap will be replaced by zram with default vm.swappiness. I did a lot of testing mostly with legacy kernels and to be honest find it really hard to 'measure' effects. With Pinebook I had to open 40 Chromium tabs to let Chromium eat up to 2.7 GB memory and as expected it just felt slow. But it feels slow all the time (compared to what I'm used to) so it's really hard to 'measure' any effects. I read about people adjusting vm.swappiness to much lower values happily reporting back that 'everything way better now' but based on user experience tests I wouldn't count on this and my personal tests resulted in me just thinking 'well, still slow'. With my very own use cases (server tasks) I'm not able to get zram swap being used extensively, mostly since it seems I'm only using daemons that behave well. So we really need some experiences made by users out there. In the meantime installation of zram-config package is not needed any more since I added everything this package does to an activate_zram function in armhwinfo (wrong place, I know -- reasons below). I took most of the functionality unaltered except a few details amount of memory used is the same (half of DRAM) and it's only configurable by adjusting armhwinfo code (done by intention, I really want to avoid dealing with problem reports from users adjusting everything to death while not even understanding virtual memory and paging basics) number of zram devices == count of CPU cores but limited to 4 (using all CPU cores works well on x86 but we don't want compression/decompression happening on A7 cores in big.LITTLE designs) set LZ4 as algorithm where possible (otherwise fallback to what the kernel is configured to use -- LZO today -- will happen). This might need adjustments in the future if we switch to 'better' compression algos on a specific platform (eg. zstd -- an interesting read here) So what's next (please keep in mind that I'm solely focused on a way to collect user experiences in the least 'expensive' (time consuming) way -- it kinda sucks how much efforts are needed to get good user feedback! With new Xenial images users are testing zram + vm.swappiness=60 behaviour Experienced users who know what they do can be encouraged by another forum thread to start experimenting with zram on their installations (it's as easy as uncommenting the 'activate_zram' line in armhwinfo, adjusting vm.swappiness in /etc/sysctl.conf and/or deleting the swap entry in /etc/fstab) Experienced users with interesting hardware setups (eg. running off pretty fast ODROID eMMC or a SATA SSD and not a slow SD card) can be encouraged to do even more testing (combining zram with swap on SSD for example with modified vm.swappiness) We can uncomment the 'activate_zram' line in armhwinfo in a few months causing no harm on existing installations since due to vm.swappiness=0 there nothing will change (only emergency swap behaviour will improve a lot) In half a year based on the collected experiences we can remove zram-config from Xenial package list and finally adjust firstrun to skip swapfile creation and adjusting vm.swappiness (or maybe we came up with a better value in the meantime and set this as default) There's only a single change that affects already existing installations and that would be activate_zram enabled which only affects (improves) emergency swap behaviour. All other changes only affect new images/installations so users are safe. BTW: What about renaming armhwinfo? For example armbian_hw_setup?

Seems I need to ask a second time: is anyone here able and willing to do a quick but correct benchmark test on Le Potato (not Tinkerboard, that's not interesting). I'm still interested in tinymembench numbers for this board and both openssl and 7-zip tests in an environment where cpufreq is monitored and throttling (if it would happen) gets noticed and avoided in a subsequent run.

The 4 port things are based on Marvell 88SE9215 (this is a 4 port SATA to single PCIe 2.x lane controller, so suitable for mPCIe where only one lane is available). I got mine from Aliexpress, Igor got his for twice the price from Amazon, you also find them sometimes at local resellers, just search for '88SE9215'. (there's also a x2 variant called 88SE9235 -- just like there's ASM1062 vs. ASM1061 -- but at least behind mPCIe there's no advantage in choosing this over 88SE9215, it would need M.2 or a real PCIe port to make use of the second available lane)

SinoVoip as usual: they're not even able to specify the dimensions of their products. Countless times they've been informed that their M2 Zero thingie is 65x30mm in size but they simply don't give a shit and still list wrong dimensions. And the same people wonder why there's zero community around them given this 'we don't care about anything' attitude. Some REAL information about this board: https://groups.google.com/forum/#!topic/linux-sunxi/I8xJS_6q6kg

Undervoltage, it seems you forgot that the Tinkerboard is a pile of crap you can switch off even with light loads. Wrt the S905X benchmark results unfortunately I miss distro and clockspeed info. Based on the information I assume it's Ubuntu Xenial y la patata is running at slightly above 1.4 GHz These are your results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 172077.88k 476222.74k 796116.22k 989857.79k 1065203.03k aes-192-cbc 166314.77k 410735.66k 636071.94k 756757.16k 800991.91k aes-256-cbc 159311.97k 370863.64k 544318.12k 630333.78k 660720.30k And this is ROCK64 at stable 1.3 GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 163161.40k 436259.80k 729289.90k 906723.33k 975929.34k aes-192-cbc 152362.85k 375675.22k 582690.99k 693259.95k 733563.56k aes-256-cbc 145928.50k 337163.26k 498586.20k 577371.48k 605145.77k Smells like 1.3 GHz vs. 1.42 GHz (and not 1.5GHz). Would be great if someone could provide tinymembench results too. 7-zip numbers are not that great since even an RPi 3 at 1200 MHz performs at this level. Strange.

EDIT: Please don't trust in the numbers appearing at the top of this thread. Obviously there were bootloader/firmware issues that needed to be resolved and afterwards Potato performance will be somewhat higher. Since I didn't find numbers may I ask owners of the device ( @Igor, @TonyMac32 ?) to run 4 quick benchmarks? Two times openssl, 7-zip and tinymembench. Please comment also which clockspeeds and which distro you used (Xenial preferred). Thanks!

Nah, only new images and clearly mentioning in release/changelog: 'Ubuntu Xenial images use zram instead of swap' (so anyone concerned about stuff not working as 20 years ago any more can choose Stretch for now). No modification of already existing images, the goal is to provide new images with a documented change. Well, I wanted to activate the new behaviour on all boards by default with Xenial since it's pretty interesting to get feedback from Orange/NanoPi with just 256 MB as well as devices with 2 or even 4 GB. If vm.swappiness is controlled by a eg. /etc/sysctl.d/armbian-vm-tweaks from now on we can react quickly if we discover problems where vm.swappiness=60 doesn't fit (and since it's known that vm.swappiness=0 works even worst case scenarios can be fixed with an 'apt upgrade' on user's side)

No, because there is none Armbian only supports boards that do not need a separate (FAT) boot partition (like Raspberries) and so we don't implement this since useless anyway. You can use an SD card as small as 4GB, then simply move the system to HDD and are done. SD card is then by default read-only since only the bootloader will be loaded from there (though you can use the remaining capacity for whatever you want -- real SD card corruption is a 1st gen Raspberry Pi problem) Whether Nextcloud will perform fast enough is dependent on your settings (encryption or not?) and based on our community's experience random IO performance of the storage device is important (HDDs are pretty slow here but the 'average' SD cards the majority of users bought is again 100 times slower). BTW: I would choose a Cubietruck (or almost any other A20 device) today only if it's already lying around (since it's almost 2018, A20 is a 5 years old design now and there exist a lot more interesting boards in the meantime -- not directly related but this list might help when interested in 'server use cases')

Yeah, so let's get rid of this rather sooner than later. My personal timeline for the approach (expectations vs reality included ): Started to prepare this 7 months ago: https://github.com/armbian/build/commit/de059a12a9f8ab7f3b40ab8e2e3671030e5dd51e#diff-01333a069633e14fb9510b0dbedadab5 Naively thought 2 months later we would've collected enough reports to get a clue what's going on (I wanted to wait for 50 different logs) so that we can drop 'swap on SD card' with next release Well, (not so) surprisingly I had to wait until now (7 months) to get those ~50 debug logs containing ~180 swap usage reports (and 2 times swapping really happened) Since 2-3 months few hundred to thousand OMV users test 'no swap on SD card' successfully already but with settings that don't make better use of the physical memory Now we know a little bit wrt 'out of memory' situations (I wouldn't call those ~50 debug logs representative but at least it's more than nothing) and that it seems to work pretty well to avoid swap on SD cards. But then any further testing is useless since how to get rid of the swap file then? The reason why I want to (temporarely) implement this as proposed is that in Ubuntu Xenial it's as easy as adding 'zram-config' to a variable in our build system to get zram activated automagically. So all that's missing is not enabing the swap file and then collect real-world experiences from our users so that we can then (maybe in half a year) decide whether to use Ubuntu's zram-config package everywhere (works flawlessly with both Jessie and Stretch BTW) or we implement this as an own startup service. I absolutely second the idea to move the vm.swappiness setting to a BSP contained file below /etc/sysctl.d/ but this does not solve the real problem to collect experiences now. At least in my testings (server and NAS use cases) I can not force excessive vm usage anyway. Seems the daemons I deal with are all well-behaving so we need some real-world experiences from people using SBCs as desktop and stuff like this. So I still propose a simple firstrun logic change making creation of the swapfile optional based on existence of zram-config package. Once we collected new experiences this can be dropped altogether or reverted back to mandatory swapfile creation.

Well, that might depend on a lot of other vm related stuff, most importantly few of the last ones on below list (that's a sysctl dump from XU4 4.9 kernel): vm.admin_reserve_kbytes = 8192 vm.block_dump = 0 vm.compact_unevictable_allowed = 1 vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 500 vm.dirtytime_expire_seconds = 43200 vm.drop_caches = 0 vm.extfrag_threshold = 500 vm.highmem_is_dirtyable = 0 vm.laptop_mode = 0 vm.legacy_va_layout = 0 vm.lowmem_reserve_ratio = 32 32 vm.max_map_count = 65530 vm.min_free_kbytes = 3454 vm.mmap_min_addr = 4096 vm.mmap_rnd_bits = 8 vm.nr_pdflush_threads = 0 vm.oom_dump_tasks = 1 vm.oom_kill_allocating_task = 0 vm.overcommit_kbytes = 0 vm.overcommit_memory = 0 vm.overcommit_ratio = 50 vm.page-cluster = 3 vm.panic_on_oom = 0 vm.percpu_pagelist_fraction = 0 vm.stat_interval = 1 vm.swappiness = 100 vm.user_reserve_kbytes = 63391 vm.vfs_cache_pressure = 100 vm.watermark_scale_factor = 10 I think we all agree that swap hitting the SD card can be considered 'game over' especially when happening on 'average' SD cards (thosethe majority of users bought with 2-10 random write IOPS at 16K block size). Our strategy to deal with this in the past was to set vm.swappiness to 0 as a try to prevent swapping in any situation. When we now still allow swap on SD card and increase swappiness then depending on kernel and other defaults we (or our users) might end up with situations where once the kernel is running out of zram swap devices it starts to swap to SD card (game over). As far as I understood this is not something comparable to 'tiered storage' where each storage layer is handled appropriately (and 'hot data' gets moved on demand) but this is just a couple of different swap devices with different priorities that are used based on a rather simple strategy. So if swap on SD card is allowd the system might use it for 'hot data' once the zram swap devices are full (containing partially 'cold data' then). If we want to avoid 'swap on SD card' and also avoid testing through all different kernels and distros (that might tweak this or that somewhere -- see Ubuntu's ondemand service that interfered with our cpufreq settings) then IMO the easy way is to drop 'swap on SD card' entirely. We can assume this works pretty well with vm.swappiness=0 (since that's tested by OMV users in the meantime) so let's try to get some experiences with higher swappiness values.

Another quick check: grepping for 'Out of memory' in all debug logs: [ 1374.514623] Out of memory: Kill process 5386 (supertuxkart) score 523 or sacrifice child (also an occurence of real swap usage I missed before since whole system configured to use french: 'Partition d'échange') [ 3790.835574] Out of memory: Kill process 2143 (python2.7) score 624 or sacrifice child (that's the other swapping occurence) I checked again (this time searching for ' 127M ') and we had 2 real swap scenarios in 182 cases and in both oom-killer 'resolved' the issue anyway.

If we leave it 'as is' then we can stop here since vm.swappiness=0 results in neither zram nor swap used unless really needed (and then there are no positive effects and we can leave everything as is). No idea how vm.swappiness was set for the 'Swap: 127M 256K 127M' entry above -- maybe @dragonlost can comment on this? At least this here was me having activated zram with vm.swappiness defaults (AFAIK that's 60). As can be seen there's slight zram usage with zero swap but I can't remember exactly what I did back then (since 4 SATA devices are attached most probably ZFS/RAID tests). But with a default vm.swappiness value we might end up with swap on SD card being really used even in situations where 'cold pages' sit compressed in zram and the host is swapping to death with hot pages on SD card. This is nothing I would roll out as part of a new Armbian release. So IMO the only reasonable test scenario is dropping swap entirely, using only zram and vm.swappiness=100 To sum it up: vm.swappiness=0 --> no need to test since behaviour not different than today. Hosts limited to real physical memory, only emergency behaviour when really running out of memory would change vm.swappiness default (60?) --> very interesting to test with swap and zram but I fear negative behaviour once paging reaches SD card (see also 'RAM + ZRAM + SWAP (on HDD)' section here) vm.swappiness=100 --> only useful without swap configured. As we can see above at least the 53 'participating' parties ran really out of memory only once ( @op1tjaap might remember what happened back then) I'm not interested in exploring better 'emergency situation' behaviour but in enabling SBC with low memory to make better use of available DRAM. I mean: that's what zram has been invented for on Android devices: Cope with low memory situations and avoid swapping to slow flash. And it works in the meantime on hundreds of millions of devices (and a few hundred -- counting Raspberries too then even a few thousand -- Armbian installations running OMV)

Will never work since average users don't give a shit about improving things. And if they enabled zram via armbian-config everything bad that will happen within the next 3 months (eg. SD card dying) will lead to zram being blamed. Let's continue discussion over there.

I added a while back 'free' output to 'armbianmonitor' and 'armhwinfo' to get some monitoring data from real-world installations about swap usage. Armbian uses an emergency swap file of 128MB by default (vm.swappiness=0) which means swapping should be avoided unless really needed. Let's have a look and extract data from +50 support URLs collected within the last months. I piped the output of https://pastebin.com/raw/DjxAX6Rn through while read ; do curl -q "${REPLY}" | grep '^Swap: '; done | sort | uniq -c and this is what we end with: 175 Swap: 127M 0B 127M 1 Swap: 127M 22M 105M 1 Swap: 127M 256K 127M 3 Swap: 2.0G 0B 2.0G 1 Swap: 513M 0B 513M 1 Swap: 617M 0B 617M So we have 182 times swap usage monitored and get 1 single occasion when swapping occured (the 256KB case here was not swapping but zram instead and the 22MB case there is the only occurence of real swapping and also an 'Out of memory: Kill process' event has been logged with kernel 4.11, no idea what @op1tjaap did back then). IMO this justifies overthinking our approach especially on boards with low memory since zram is an alternative. Currently there are a few hundred Armbian installations out there running Jessie with Ubuntu's zram-config package installed (zero swap configured, vm.swappiness=0, zram-config defaults resulting in zram area half the size of physical available memory). Not a single complaint so far. But vm.swappiness=0 is a pretty bad setting for such a configuration since as we see above swapping will be avoided anyway if possible. When using vm.swappiness=100 available DRAM will be used way more efficient. But I've to admit that in my testings available memory has never been an issue anyway. So what about the following: add zram-config to Xenial default package list modify /etc/init.d/firstrun to skip swap file creation if this package is installed and branch=next|dev and set vm.swappiness=100 instead of vm.swappiness=0 This way we can collect within half a year some details about zram usage (count of complaints and again collecting free output through 'armbianmonitor -u' output) Edit: Added mainline kernel requirement