tkaiser

This should be avoided unless you really know your 'router' is in fact acting then just as a switch (since otherwise most probably the router is the real bottleneck). Better advise: use a GbE switch connected to the router (so stuff like DCHP works) and connect NEO2 and your client to the switch. If you've never tested the switch's throughput (must be +940 Mbits/sec) then this is of course also useless. Anyway: Jean-Luc already tested with FriendlyELEC's OMV and published results on CNX. Since he's quick and smart I don't know whether he added some more OMV/Armbian tweaks based on my comments to his OMV installation or not and was just curious when I heard your low NAS performance scores. Maybe just focus on thermal results first if you test with 'our' OMV image now and postpone the performance stuff for later...

Please don't get this wrong... but since I asked you already over at OMV forum and still miss the answer (or might have overlooked it): What do you need a RTC for on a NAS? The N in NAS is 'Network' just like in NTP (Network time protocol -- active by default on OMV and usually providing exactly the same correct time than RTC which is needed on systems w/o network connections)

Well, if throwing in that many components you simply don't know what you're testing. Is it the NEO 2 and it's NAS implementation or your home network? Such tests can only work if all potential bottlenecks are known and if you want to get results with some meaning bottlenecks that can invalidate test results have to be eliminated before.

Just as a short reminder (for whoever feels concerned): Current boot.cmd for EspressoBin should not be able to work with a btrfs rootfs (or any other sort of image using a separate boot partition) since there are fallbacks from 'boot/' to '/' missing everywhere. Generated two OMV images today with both kernels, searched again for my EspressoBin in the lab, thought a bit about the potential showstoppers, didn't found the board, gave up.

This differentiation makes no sense since OMV sits on top of a Debian (be it Armbian or the Debian image FriendlyELEC uses -- main difference is most probably that the Armbian variant contains a lot more performance and other tweaks) This OMV here https://sourceforge.net/projects/openmediavault/files/Other armhf images/OMV_3_0_90_Nanopineo2_4.13.10.img.xz/download is based on latest Armbian Jessie with pretty recent u-boot and kernel while FriendlyELEC's OMV uses stuff from the beginning of this year. Maybe that's the difference? In case you've another SD card I would be really interested in results from our new OMV image since also your NAS performance numbers are horribly low. Please be aware that for SSH login to be enabled for root you need to use OMV web UI (either 'permit root login' on the SSH service tab or create a new users in the UI being member of sudo and ssh groups)

Thank you for testing! I would keep the box closed since it shows excellent heat dissipation (25"C less than VIM2 with same load -- that's really impressive). Out of curiousity: what material is the enclosure made of and does it feel warm(er)? @balbes150: Do you have a pillow at home to throw on the VIM2? I can't understand that no one is able to get the S912 throttling!

Well, if your MacBook is somewhat recent then it has at least 3 antennas and this combined with a 802.11ac MIMO capable AP with same count of antennas or more... good wireless performance (same here, Fast Ethernet almost feels broken) Your SSD is not the bottleneck, the 3 first runs tried to simulate what LanTest was doing and even with 128KB blocksize write performance is at least 200 MB/s. Overall performance of this Intel thing is still pretty fast: random random kB reclen write rewrite read reread read write 307200 128 232575 275415 194252 188408 307200 128 233562 275463 195358 201862 307200 128 201101 244803 174815 178310 102400 4 18686 30697 35260 35643 23840 32454 102400 16 65864 103817 98304 98915 73120 103304 102400 512 276280 344878 229520 229880 218717 344584 102400 1024 330431 318705 227095 237980 236421 360159 102400 16384 307209 318521 228364 228928 229110 318783 In case you didn't disable Wi-Fi completely when doing the wired tests this would be worth a try (since macOS' configd and/or the AP might have different views about which interface packets should take)

No, you were bottlenecked by either using the wrong storage port combined with the wrong device (pendrive on USB2) or the wrong filesystem (NTFS). When using the SATA port, a capable HDD exceeding 150 MB/s and appropriate Samba settings the network will be the bottleneck on EspressoBin.

If the description is exact (I hope not) then we or at least our users will have another reason to complain soon (since last OPi Plus 2E batch has RTL8189FTV and Aliexpress lists RTL8189ETV instead now).

First part of the journey happened here: https://forum.openmediavault.org/index.php/Thread/20464-Problem-installing-Rtc-shield-Hardkernell-on-Openmediavault-Erasmus/?postID=159296#post159296 IMO it's just fdtput not doing what it should for reasons I haven't checked (since not using C2 anyway). To proceed it would help if @marcellom would put the result of 'dtc -I dtb -O dts -o meson64_odroidc2.dts meson64_odroidc2.dtb' to an online pasteboard service like pastebin.com. Just paste meson64_odroidc2.dts to it and post the link.

I expected that already but since the numbers were a bit too good I didn't asked already. Now with wired connection write speed is still at 14.2 MB/s so I would strongly suggest to do a local storage test now (since old SSDs are often funny SSDs). Please do a cd to the SSD's mountpoint in question and then for i in 1 2 3 ; do iozone -e -I -a -s 300M -r 128k -i 0 -i 1 ; done sleep 240 ; iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Please post the results via pastebin.com or something similar.

Hmm... http://linux-sunxi.org/index.php?search=RTL8211E-VB-CG&title=Special%3ASearch suggest that's copy&paste from http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2 -- so if FriendlyELEC would've written just 8211E, then this would also be listed that way in the wiki. In fact I'm thinking about editing it there Edited it and linked to normal RTL8211E entry. Seriously: please always test from bottom to top first. In networking such 'link down, link up' problems happen most of the times at layer 1 so please check this first (also testing between your two NEO2). Few months ago the PSU of my old lab switch died (a dumb ALLNET Gbit switch) and in the meantime I had to send two cables to the trash already since with the replacement switches ('smart' ones from HP and Netgear) strange problems occured sometimes but in some combinations always (eg. ROCK64 not negotiating an GbE link at boot).

The driver used is the same as on all other H3, H5 and A64 devices with Armbian's mainline kernel now and not just me tested extensively with the new driver variant already on various devices. How many different Ethernet cables did you try?

Thank you. I was looking for some network manager / systemd / udev / whatever problems but dmesg output at the bottom seems to indicate a connector / cable problem (AKA hardware).

No, the 'dependency' stuff was meant to explain that RAID6_PQ might get activated by other stuff too. Personally I would prefer to simply patch away the btrfs RAID6_PQ dependency on all Armbian kernels since it makes absolutely no sense and means just allowing users doing stupid things (playing btrfs RAID5/6 which is still considered experimental and makes exactly no sense at all on all boards except maybe Helios4)

Maybe it's normal behaviour, without armbianmonitor output not easy to tell. You would need to run 'sudo armbianmonitor -m' in another terminal while running benchmarks (to see when throttling occurs) and if this does not explain the 'performance' (which is not bad, it seems this is just the device throttling down to 648MHz at the end of the sysbench run) then 'sudo armbianmonitor -u' is needed anyway. Policy is to remain at 240 MHz as long as the box is idle, then clock up to the maximum until throttling jumps in. Since heat dissipation doesn't look that great judging by the pictures I would assume 'everything as expected'

It's a dependency problem explained already in the link above (at the bottom): https://github.com/armbian/build/issues/696#issuecomment-307873342

Please provide output from 'armbianmonitor -u'

Well, haven't thought about this. Then we'll live with it since initrd support came this year but we had reports from people relying on btrfs for rootfs already before.

So when do you start to implement this? You won't just like no one else will anytime soon or ever and if this is the requirement to switch from swap to zram (as it seems) then it's as I already said: Since it seems I'm the only one interested in improving DRAM usage on small boards and wasted already way too much time on this approach I've just given up. And if you have to ask the question you asked I can only recommend to read the thread you posted to since it's explained in detail.

h3disp is only supported and needed with H3 legacy kernel. I started with this stuff a while before Armbian supported H3 boards so it's meant to work on all legacy kernel based OS images everywhere (even on really old OS images for Orange Pi from 2015). We kept the code this way to search for the file to patch so it's ensured it can still work everywhere (though then also needing our modified HDMI driver for legacy kernel with the additional modes patched in). That said h3disp code works fine on all community H3 images I ever tested, on community developed H3Droid (a better Android for H3 devices), on all FriendlyELEC and Xunlong images for these boards. Just one fruit pi vendor (the one who never listens) managed to move this file to a location where it can't be found (told them multiple times, got ignored multiple times)

@zador.blood.stained thinking about this again: would it be possible now with initrd support to build btrfs as module and get rid of this boot delay?

Just read through this thread, there are several people having reported this working. Since in your log appears 'ext2' multiple times... did you chose that when running nand-sata-install when transferrring to eMMC?

This is something that could really happen on Raspberry Pis when powering is insufficient since the firmware can do frequency capping in such a situation (then a RPi 3 is being forced to 600 MHz while it still happily lies to you it would run at 1200 MHz but everything is half as fast). Fortunately Armbian does not Raspberries and clones We have on every board three different stages where CPU clockspeeds are set. Sunxi next example below: u-boot: defaults or per board CONFIG_SYS_CLK_FREQ setting (here you could get 480 vs 1008 MHz depending on default or not) kernel: depending on what's configured wrt default cpufreq governor (CONFIG_CPU_FREQ_DEFAULT_GOV_*) either u-boot settings are still active or now the cpufreq OPP defined in the device-tree if existing and working cpufreq driver applied to kernel will take over depending on the chosen governor (with performance you would be now at 1200 MHz, with powersave at 240 MHz and with other governors somewhere in between) As soon as the cpufrequtils service is started the settings that are in Armbian's build system defined are applied At early boot we're talking about stage 2 above so there are a lot of possibilities why performance differs a lot within the first seconds when kernel has just been started.

Doesn't mean something on our devices, that's just a side effect of btrfs enabled. What are the differences between the builds and which board are you talking about?