tkaiser

Can you do the following test please? Reimage SD card with Debian_stretch_next.7z, boot, apply all updates, shutdown, connect the SSD, then turn the board back on again. Then please provide output from armbianmonitor -u No further steps needed at this moment.

@Da Xue are you able to provide the DRAM initialization stuff and appropriate .dts files for 4.4 and mainline?

You were talking about OMV? It's irrelevant how 'fast' the installation media is since with our ARM OMV images this simply doesn't matter. If you want to spend more money on more expensive storage, that's fine too. Though my personal recommendation for this use case if you can get SanDisk Ultra A1 would be the 32GB variant (since best capacity/price ratio)

Then any SD card will do since performance of the rootfs is not relevant at all. Buy one of the great SanDisk A1 cards and don't skip the necessary tasks to check for counterfeit/fake SD cards, then do a TRIM and then write the OMV image with Etcher. On the OMV ARM images the 'flashmemory plugin' is already active so your SD card will last most probably indefinitely. HDDs are on either USB2 or USB3 so there's no 25MB/s limitation. Simply take care that you get a good USB-to-SATA bridge (eg. those referenced here)

The SD card interface on ROCK64 is limited to DDR50 which not just limits sequential transfer speeds to around 23 MB/s but also affects random IO performance with data chunks of 16KB or more: https://forum.armbian.com/topic/954-sd-card-performance/?page=3&tab=comments#comment-49811 (search for SDR104 there) So even the slower FORESEE eMMC modules should always be faster than a high performing SD card on Rock64 (since DDR50 mode is the bottleneck). This is not true for other SBC, we support a few boards that come with pretty slow soldered eMMC where good SD cards can outperform the eMMC at least with sequential writes.

Just for the record: This (using the OMV RPi image and removing the OMV parts) will not result in an Armbian installation (I'm aware that you've written about 'Armbian a like', just want to further clarify). It's just a Debian Jessie armhf rootfs generated by Armbian's build system that has been slightly adjusted and manually combined with RPi Foundation's kernel packages and the proprietary, closed sourced RPi stuff (ThreadX on the /boot partition and some proprietary userspace binaries to interact with VideoCore/ThreadX, most importantly to report/detect under-voltage). Armbian is about: bootloader and kernel optimizations (first not possible since closed source ThreadX, latter not reasonable/needed on Raspberries) optimized settings to improve performance, consumption and thermal behaviour (not possible on RPi since done entirely on the VideoCore by ThreadX) to improve security situation building an entire OS image from scratch so no one has fiddled around so far (if you use our build system and let it debootstrap a fresh Armbian image you know no one logged in so far and planted backdoors or stuff like that) So the OMV image is just a modified piece of data that was falling out of Armbian's build system (the rootfs) manually adjusted to be combined with the proprietary and closed source stuff that still makes up the whole 'RPi experience' (for the majority of RPi users I personally know the Pi is just a KODI and retrogaming box and without the proprietary video decoding and 3D acceleration stuff on the VideoCore they would have to throw it away) So all you get by using this OMV image is the illusion wrt 3) above (clean rootfs) but thinking this would enhance security or prevent you from being backdoored is just... an illusion. The main CPU of every RPi is still the outdated VideoCore from 2009 (this chip contains not only GPU, VPU and multiple QPU cores but also an ordinary dual core CPU inside running the closed source RTOS called ThreadX). The ARM cores running any secondary OS are just guests. Since Raspberries are popular for stuff like Tor end nodes or VPN gateways who knows whether GCHQ already ordered the Foundation to ship their ThreadX with an universal backdoor to allow agency access?) Anyway: maybe the OMV image's only real advantage is that it's Jessie based but still gets RPi Foundation's kernel updates (we do this via apt pinning since for whatever reasons someone at the Pi Foundation decided last year to cut off all their Jessie users from future kernel updates, weakening the security of all these installations). But if you're not running OMV (where OMV releases are bound to the underlying Debian release -- OMV 3 needs Jessie and OMV 4 simply wasn't ready last year) then why not using Stretch anyway? Raspbian isn't bad, it's just somewhat bloated. As usual the 2 most important things you can do to improve general RPi performance/responsiveness is Checking whether your powering is sufficient, you need to call perl -e "printf \"%19b\n\", $(vcgencmd get_throttled | -f2 -d=)" and have a look at the left whether there is a '1' (explanation). If you see there a 1 you're running 'frequency capped' at 600 MHz when performance would be needed. You must call vcgencmd since the usual ways to query CPU clockspeed are all fake (don't tell it over at the RPi forum -- for this you will get censored and banned ) Throwing away your old and slow SD card and start with a new, genuine and A1 rated SD card of at least 16 GB in size (I would go with an A1 Extreme and not an A1 Ultra for the simple reason that most probably RPi folks with their next 'incremental Pi update' next year will finally implement SDR104 to speed up SD card access. This and better Wi-Fi is almost all they've left to once again sell their fanboys an 'improvement') Please note that both 'performance tweaks' are hardware and not software fixes.

BTW: People interested in a decent arm64 Debian Stretch running on RPi 3 or 3+ could try this on a PC running a 64-bit Ubuntu or Debian with Docker: git clone --depth=1 -b linux-4.14 https://github.com/ThomasKaiser/pi64 pi64 cd pi64 And then follow the instructions. Using the original Github repo should work too but there the 4.14 branch misses the routine to copy wireless firmware for the new board (PR not merged yet). Personally I think running a 64-bit OS on SBC with that low amounts of DRAM as the Raspberries is not worth a try.

Oh, yes. Really nice 'solution'. But if you lived only in Raspberry country you would already know that barrel plugs can't work and Micro USB is superiour.

Nice place over there BTW So can not help any further diagnosing why Gigabit Ethernet with the new RPi 3 B+ is slower compared to Fast Ethernet

No. It's uninteresting for these reasons: RPi is a closed source platform, the main operating system bringing up and fully controlling the hardware (ThreadX running on the dual core VideoCore IV main CPU) can not be altered since... closed source and proprietary. All the relevant stuff happens completely there (DVFS for the ARM CPU cores, video decoding and so on) and the secondary OS running on the ARM cores has not even an idea what's going on (see for example all those RPi installations that constantly suffer from 'frequency capping'). All we as Armbians could do is to fiddle around with a secondary OS running on the 'guest' ARM CPU cores while everything interesting happens solely on the proprietary and closed source VideoCore. The community driven tries to replace ThreadX with something open sourced have stopped since the developers involved lost interest (some details) The new board is a power hog able to consume close to 1800mA by running some CPU intensive stuff alone (see at the bottom of this nice review). In the past due to poorly-designed power circuitry an RPi 3 was not able to exceed ~1.5A anyway (voltage drops then occured and under-voltage 'protection' kicked in). Now this has improved but unfortunately the Pi is still equipped with a Micro USB port to be powered (rated for 1800mA maximum!) so even more users will run into underpowering hassles. Headless RPi users are usually not even aware that they run under-volted (example, example, example, example) and if even under-voltage 'protection' (frequency capping turning the RPi into a 600 MHz board) doesn't help crashes, freezes, kernel panics occur that are usually considered 'software issues' (example). I believe the RPi people are well aware that powering with Micro USB is a shitty idea. But they do a great job masquerading the problem and try really hard to keep their users clueless (see this funny 'Micro USB powering' thread and how it ended -- archived version here, they love to censor over in their forum). TL;DR: it's not fun but simply boring to bring Armbian to the RPi and support situation for both users and us here will be a nightmare (users expecting everything Raspbian compatible while we would have to deal with the results of crappy Micro USB powering being reported as software bugs and users miseducated by RPi people not able to realize that under-voltage is the problem and their '3A PSU' won't help here anyway. RPi folks really try hard to let their users focus on BS amperage ratings instead of explaining the real problem. BTW: I know a bit what I'm talking about since having maintained an OS image for RPi 2, 3 and 3+ that gets downloaded +10,000 times each month.

Since we already trashed the whole thread with all this thermal babbling... Pi 3 B+ without heatspreader: https://youtu.be/4LtL9e7JqxE?t=3m10s

Which 'outsourcing'? Allwinner sells hardware. Cheap hardware for special markets. Android tablets back then, $something in between, now smart speakers, dashcams, retro gaming stuff, again tablets and TV boxes. Nintendo's NES Classic sold 2.3 million units in no time. Using a boring A33 SoC with technology from 5 years ago running a smelly 3.4.39 kernel from 5 years ago. Their customers (that's not us) do not care so why should Allwinner care so far? They enable device manufacturers to throw out cheap hardware with somewhat working software with ok-ish margins (their main market) or sometimes enable their customers like Nintendo to sell insanely overpriced/overhyped products where again no-one cares about kernel, software or anything else we would be interested in. For Allwinner there's still no 'Linux market'. Though things might change in the future. But unless there's an incentive to mainline their own hardware and submit code upstream (good luck given the BSP code quality) I doubt anything will change soon or at all. But of course I highly appreciate that they now contribute and react in a very responsive way. As @jernej pointed out in the meantime many requests will be answered positively (and I always chuckle seeing wink, the Allwinner guy, directly contributing to linux-sunxi wiki now -- I never thought this would happen)

In fact one more problem: Gigabit Ethernet, crappy network equipment and ignorance: https://forum.openmediavault.org/index.php/Thread/18991-New-approach-for-Raspberry-Pi-OMV-images/?postID=171017#post171017

Yeah, but that's all just due to some of my personal superheroes doing such a great work (talking about especially icenowy and you right now). Thank you BTW But still it's a huge problem with Allwinner SoCs that we can't use what board or chip makers provide (at least not without wasting insane amounts of time to turn Allwinner's BSP crap into something useful like longsleep did two years ago). And then there's the insanely time consuming mainline upstreaming process...

If you want a KODI box why not asking the KODI guys? Bootlin is today working on Allwinner SoCs that are horribly outdated (A33 being the only expection somehow, the others are A10, A13 and A20 from 5 to 8 years ago). They're all ARMv7 and support for Allwinner SoCs that are just outdated (A64 and H5) will come later. According to their Kickstarter page at the end of Dec 2018 if they succeed. Welcome to the Allwinner reality. Get the hardware, be able to use only a shitty Android or crappy Android/Linux hybrids, wait for software support becoming mature (100% relying on community) and use the hardware as intended when it's already obsolete.

I know: https://forum.armbian.com/topic/1580-nanopi-neo-air/?do=findComment&comment=14045 But the situation is different. On the NanoPi the thermal pad will be used on the PCB side where the SoC is so it mostly transfers heat directly from SoC to their large heatsink. I'm talking about boards where the SoC is on the wrong side (upper) and such a 2mm thermal pad can only be used to try to transfer the heat away from the whole PCB. So the effect is quite different especially with load peaks. Talking about NanoPi. Their heatsink is somewhat efficient (especially without an enclosure!) but an aluminium enclosure design using just a thin thermal pad or even thermal paste to connect the SoC to the enclosure will work way more efficient dissipating heat away from the SoC.

Replacing the .dtb file contents with the one for PineH64 works somewhat (at least the kernel uses the updated .dtb -- see the gmac-power0, gmac-power1 and gmac-power2 entries in serial console output). But then with the Xunlong image PineH64 panics: https://pastebin.com/h9G1kRQx Same modified image boots on an OPi Lite2 but... this Allwinner BSP crap is that horrible that it's really not worth a look (at least for the stuff I'm interested in). UAS is not supported, quick USB3 storage 'performance' test results in 40/45 MB/s read/write with an EVO840 SSD, no drivers included for any of the popular USB Ethernet dongles. I had the idea to do some tests with the BSP to get some baseline numbers but in this state this is all just a waste of time...

Sure, this is how it should work. Great that now even the RPi folks got it Yesterday I 'unboxed' Orange Pi Lite 2 (Allwinne H6). As small as the H3 Lite but extra thick PCB. After 10 minutes of idle operation the whole PCB including all receptacles is warm so the groundplane efficiently spreads the heat away from the SoC. I put 3 low performing heatsinks on SoC, PMIC and DRAM and reported SoC temperature went down from 49°C in idle to 46°C (after waiting the same 10 minutes or until temperature is stable). So still curious how efficient a 2mm thermal pad between PCB lower side and an aluminium enclosure would work (to transport heat out of an enclosure). To be clear: I'm talking about something like this (and am not willing to spend my own time on such tests any more since done with the low consumption/thermal stuff) Testing such stuff with enclosures that already exist seems impossible. The FLIRC is constructed wrongly and to buy the Wicked you must be mad.

Sure, RPi Trading's mission is to sell mediocre hardware to clueless people. And the forum serves as a way to keep customers dumb. All perfectly fine since their mission is to get money for education and charity and so on. I understand that. Let's look at the thermal image from new RPi 3+ again: In RPi forum the censors do not only censor but also spread BS. Users are told that the HDMI cable acts as an efficient heatsink (well Google image search suggest something else but hey). But if we look at how all modern SBC (now Pi 3+ included) do it then wouldn't it be a good idea with an aluminium enclosure to use a full size conductive thermal pad between enclosure and PCB? In those aluminium enclosures today there's usually air or isolating foam: https://youtu.be/mBSfb6vlfKo?t=1m46s Wouldn't a 2mm thermal pad improve things?

Sure. Better results compared to the board lying flat on a pillow Since latest RPi 3+ from last week now also started to copy what those cheap Orange Pi do since years (using the PCB ground plane as massive heatsink) I suggested this test over at RPi forum: https://archive.fo/6kzg0 ... and (not so) surprisingly the post got censored: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=207863&start=225#p1286503 -- they really don't like it over there their users could get the idea that there grows more than Raspberries on this earth BTW: really impressive how inefficient the old RPi 3 was and is from a thermal point of view: vs.

But since it's so inefficient (again: https://youtu.be/mBSfb6vlfKo?t=6m37s ) at least it will fit on the new RPi 3 B+. The FLIRC ruins the thermal efficiency of the enclosure material with a huge gap between chips and enclosure filled with thick thermal pads. Since the BCM2387B0 on the new Raspi is higher they'll start to put two thermal pads to the package soon. The old thick and inefficient one for BCM2387 (overheating SoC needing good heat transfer) and a much thinner one for the new board that doesn't need a heatsink anyway. Well done or... it's just a typical 'Rasperry Pi product'. Eye candy and a good feeling and real result inefficient.

https://youtu.be/mBSfb6vlfKo?t=6m37s Can only be used with one specific board since onboard components on predecessors or successors have partially different position and height. If SBC vendors would start to do it less weird they would put the SoC and other parts that generate heat (eg. SATA controllers or PMICs) on bottom PCB side so that they're the highest and add some thermal compound. If case designers then would simply combine one somewhat thick aluminium base plate with a plastic top the problem would already be solved. Not even heatsink fins necessary. I tested this with those boards where it works this way: Banana Pi, Banana Pro, NanoPi NEO[2], ODROID HC1 and HC2 (the RK3328 Cloudmedia Transformer never arrived here unfortunately). Large aluminium surface to spread the heat is all it needs.

And when air flow 'in the open variant' differs. And when throttling differs e.g. power consumption And when thermal readouts aren't correct You got the reason I was asking for 'stress -c 4' and not 'a miner' since lightweight enough to not totally trash the whole idea. And yeah, 'air flow' in the open variants is what's to be expected. This is not that interesting than the comparison between 'enclosure with lots of vents' and 'same enclosure with venths covered' but it's always a nice reminder that approx. 100% of enclosures increase heat since almost all SBC are constructed wrongly.

Since when conducting some own tests almost 3 years ago (just to realize that tons of small vents resulted in no difference compared to no vents) I would be interested in a real 'thermal performance' comparison. Ensure that ambient temperature is the same. Boot the board, wait 5 minutes and monitor idle temperature (10 lines from 'armbianmonitor -m' are sufficient). Let armbianmonitor continue to run and start in another terminal 'stress -c 4'. Wait until temperature doesn't further increase (10 min should usually be sufficient). Then put board into enclosure and repeat the whole test. If board has a lot of vents repeat the test again covering all vents so no airflow possible. Provide average temperature values from last 10 armbianmonitor lines for each idle and 'light load' (stress) for each situation. Pro variant: Repeat all tests with board/enclosure standing upright instead of lying flat on a surface. And of course the whole test is a joke when ambient temperature is not exactly identical

https://forum.odroid.com/viewtopic.php?f=154&t=30280&view=unread#p218515