tkaiser

Is that the same company responsible for the new RPi 3 B+ not even able to do a fallback to Fast Ethernet with older or broken network cables unlike every other GbE NIC out there? 'Sadly, as far as we know, the LAN7800 chip doesn't support a fallback mode to 100Mbit/s should the extra pairs not be available. There is still an open enquiry with Microchip over this. If you are missing the pairs then the link will simply not come up.'

armbianmonitor -m does a renice to lowest value and with appropriate cpufreq governor settings running this alone should never be responsible for an increase in clockspeeds. If clockspeeds increase by just running armbianmonitor in monitor mode then this is a clear indication that there's something wrong with cpufreq scaling but since none of the developers is interested in such low-level stuff we need to accept that Armbian is simply broken with more recent kernels in this area (no idea whether this commit is part of the images users play with, no idea whether these settings are appropriate with all kernels on all SoC families -- I simply don't care any more about this since nobody else cares as well -- we need to accept that this forum starts to get flooded with recommendations like switching to conservative or powersave governor since Armbian doesn't care about such things) That's the facts and I'm too tired to repeat the same stuff over and over again. The way 'we' develop in Armbian simply sucks. This project lacks an agreement on project goals and this will never change.

This is so hilarious: BPi product manager @Nora Lee and SinoVoip CEO @Lion Wang proudly announcing their latest GPL violations not just in their own forum but spamming other forums as well to do more harm to their project... LMAO!

Is not a great idea since this monitoring stuff generates some light load itself which might already trigger cpufreq rising. Better always use armbianmonitor -m (this defaults to 5 seconds which gives a more realistic picture). The last column shows 'cooling state' so you get an idea how the board settings define that. Some cooling states should invoke a fan, others should result in lowered cpufreq -- it's a complex thing with mainline kernel and I totally lost track how both upstream contributors define it per board and SoC family and what Armbian might have changed (my personal interest in anything Allwinner other than H6 dropped close to zero in the meantime and since all this stuff with H5 is still 'work in progress' upstream it became just a waste of time trying to keep up). For long term monitoring maybe use screen to always run 'armbianmonitor -m' in an own session or install RPi Monitor (easy to use with Armbian but might require tweaking templates for H5 -- at least I will never touch this)

Well, since I've not the slightest idea about electronics (software guy) I never thought about that. But my naive assumptions as follows: 12V is 'pass thru' since this is something only the spinning motors on 3.5" HDD need. There's a high peak consumption when drives spin-up, once the platters rotate this current on 12V rail can be pretty low 12V --> 5V needed for the board itself (15W?) and for the HDD's 5V input (logic and stepper motors to move the heads). No idea what's the highest 5V current specified by any 3.5" HDD datasheet but what I looked into not exceeded 0.7A. So most probably talking about 30W for DC-DC circuitry? The Helios4 ships with an 12V/8A PSU, DC-DC conversion happens on the mainboard and at least I'm not aware of any power related issues yet.

Uhhh, give me a few days. :-) Of course that is one hell of a wishlist you've got there. Why? In fact currently only boards with mPCIe would qualify (there you can add a SATA mPCIe card which will always be bottlenecked by the single PCIe lane) or maybe M.2 key M. I found such a M.2 key M SATA card but there are three issues: stuff on the bottom PCB side making it impossible to insert it into a M.2 SSD slot due to height constrains, those SATA cards are shorter than 80mm and then still powering attached disks is needed. So as already suggested: Such a HAT for the M4 would contain the PCIe attached SATA controller and 12V/5V DC-DC circuitry. And currently NanoPi M4 is the only board where something like this could work since SoC fast enough (hopefully also with HW accelerated transcoding support soon) PCIe x2 available on pin header SoC on the correct side of the PCB so no heat issues unlike on all the other RK3399 boards It's not only about 'true SATA' (as many call it -- though native SATA like on EspressoBin, Clearfogs and Helios4 is something different than PCIe attached SATA here) but the main point is if attached drives can be powered reliably. 2 x 3.5" with RK3399 is already covered by RockPro64 (there is a 5V/12V power header on the board for disks), NanoPi M4 could make this possible for up to 4 3.5" HDD.

For anyone else reading this: do NOT do this. Just use Armbian -- we care about zram at the system level and also set vm.swappiness accordingly (low values are bad)

Why don't you use armbianmonitor -m to monitor (-m 1 if you want output every second) If you did not change cpufrequtils settings then you're running with ondemand cpufreq governor and this mechanism tries to keep clockspeeds at the minimum and only increases them when needed (e.g. a script running every second keeping clockspeeds up) We had recently an issue with ondemand behavior and recent kernel versions that kept cpufreq high all the time. No idea whether you're affected by this but to get an idea visit https://www.armbian.com/#search and enter sampling_rate (with underscore!). No idea what's happening since contributing to Armbian in this area totally sucks (0% feedback from users, other devs care about whatever else, we have no project goals) Temperature control would only lower cpufreq when the board overheats. The mechanism to increase cpufreq 'on demand' is implemented inside the ondemand cpufreq governor that tries to up the clockspeeds as long as temperature control allows it.

Interesting. The thermal compound I used is +30 years old so maybe I should buy a new one (or search for the stuff laying around here anyway somewhere ) and try again.

USB in an 'controlled environment' isn't necessarily a bad thing. Take a look at ODROID HC1 and HC2. Both networking and SATA is USB3 based but no cable/contact hassles any more since the chips are on the PCB and with HC2 also powering problems are gone (due to 12V powering). The boards I personally consider for NAS and small server use cases are Olimex Lime2 (slow but the 'true UPS mode' is a big plus -- just add a battery and your whole server with connected 2.5" SATA disk runs for hours even if disconnected from mains) NanoPi NEO2 or Orange Pi Zero Plus are both fine if you don't need high performance and use the vendor's NAS add-ons (then you get no USB contact/cable hassles and powering also is no problem) ODROID HC1 or HC2 EspressoBin (though still not totally convinced since at least my board shows an idle consumption that is IMO way too high) Clearfogs Base/Pro and Helios4 RockPro64 NanoPC-T4 NanoPi M4 (especially if @mindee starts to evaluate a 'NAS HAT' allowing to power the board + 4 3.5" disks with a 12V PSU and there's a 4 port SATA PCIe controller on this thing) NanoPi NEO4 (more 'pocket server' than NAS of course)

How should this help with headless boards especially those where no one wants to buy a serial console (e.g. ODROID HC1 and HC2)?

Since I know you're coming from the worst SBC for the NAS use case possible (something called Raspberry Pi) let me elaborate why this device is so lousy and why (former) RPi users think 'if it's running with ARM it's unstable as hell' (which is the reason why I call the RPi a shame for the whole ARM ecosystem since you can not convince professional users to stop wasting energy with huge x86 server boxes and switch to energy efficient ARM designs since they all had already experiences with these crappy RPi toys and think the RPi experience would apply to all ARM boards) The Raspberry Pi hardware is a total fail if you want to do anything related to storage or network with this thing. The 'engineers' chose the most crappy way possible to power the board (Micro USB) which in itself is responsible for a huge amount of instability reports. Use an average charger and an average MicroUSB cable and some increased load will result in your RPi toy freezing or shutting down. The problem is usually called 'voltage drop' and affects connected peripherals as well (a host powered 2.5" disk usually doesn't like it when available voltage drops below 4.75V) All RPi are based on a SoC which is no real ARM SoC but a VideoCore IV with some crappily integrated ARM cores. This also affects USB functionality since the single USB controller is part of the VideoCore and it required huge amounts of fancy workarounds to get USB working in Linux 'reliable' or at least at all Since there's no network and only one USB2 USB OTG port on all those RPi with network and USB-A receptacles everything is behind an internal USB hub that also integrates Ethernet. You can't implement it 'better' if your goal is 'as unrealible as possible'. But that's all what the RPi Trading guys had since they chose the wrong SoC in the first place (most probably since Mr. Upton worked in the BroadCom division that was responsible for these obsolete VideoCore IV SoCs back then) Can it get worse? Sure, since there are not only voltage drops leading to problems but also undercurrent is a typical phenomenon with Raspberries. There are current limiters in place which cut power to here and there if this or that happens. See the great example of their new PoE HAT which is such a bizarre fail from an electronics point of view that I miss words. Since we're already at QA: remember how they decided to implement Gigabit Ethernet on their latest RPi 3 B+? By not testing anything prior to product launch and later immediately blaming the supplier they chose instead of admitting that the designer is to blame for choosing inappropriate components that then receive zero testing? What can we learn from this RPi fail? Reliably powering the device(s) is the most important part. MicroUSB is crap for this purpose since it encourages users to run into undervoltage and undercurrent problems. With USB-C it starts to be the same depending on the implementation. 5V and high currents --> voltage drop resulting in unreliable operation USB storage is unreliable by definition. USB3 and especially the USB3-A receptacle made this even worse. If you love cable and contact problems, only then USB3 with USB3-A receptacles is for you. Adding to this the USB3/XHCI implementations in most ARM SoCs are somewhat crippled and there exists a bunch of problematic USB gear out there that causes trouble (e.g. Seagate USB3 disk enclosures -- this problem is solved in Armbian but x86 Linux users suffer from the same shitshow again and again --> recent example) So what to choose if you're after reliable NAS operation? Avoid stuff that wants to combine high currents and low DC-IN voltages. Boards with 12V or wide range input are more reliable Avoid USB, especially USB3 and there especially storage interconnects using crappy USB3-A (due to ultra tiny SuperSpeed contacts inside jack and receptacle) If you want to choose a SoC that's only capable of USB then at least avoid cable/contact issues (see how ODROID HC1 and HC2 solved this problem) If you want to rely on USB storage avoid hubs in between host and disks (I've tested just recently one board that at least with only one disk behind the hub operates well, all other tests in the past were simply horrible) Once you followed this list you don't need to worry about stability. Linux is stable, it runs on tons of servers. But those things use appropriately sized and stable PSUs and not crappy phone chargers that were bought as cheap as possible and are connected with tiny wires. They use storage implementations that do not suck (no USB and especially no crappy connectors involved and no complex topology like USB hubs in between).

Sorry, 'recipes are just an inspiration' I only follow them when it's about making dough. And then I totally lack English kitchen vocabulary (only fluent in German, Italian and a bit French in this area) and it won't get better than http://kaiser-edv.de/tmp/senigallia/Sabato.html anyway...

Just had a look when I did Knöpfle the last time: over 11 years ago. Delicious taste, bad 'look&feel'. Never did them again

The higher available cpufreq OPP are distro independent. It's just the linux-dtb-* package that contains now also the 1.5GHz OPP (no idea whether this is already available via official apt.armbian.com or you need to switch to beta repository)

As expected, see the first 3 NanoPC-T4 numbers in my list: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md (it's just GCC 6.3 vs. 7.3 vs. 8.2 that's responsible for this benchmark number variation. Should be a reminder why updating software is a good idea in general -- and why using Debian/Ubuntu or any other 'everything outdated as hell' distro is sometimes so annoying) The sbc-bench -t and -T modes provide different results (and possible insights) since the purpose of this test is to use -T as first run to heat up the board to +70°C for sure, then with the -t 50 you allow the board to cool down to 50°C which means in this mode the thermal mass of the huge heatsink plays an important role. A normal sbc-bench run starts from low load to high load so the heatsink's temperature is constantly rising but always below the SoC temperature and the final temperatures will be lower compared to the situation when the heatsink is in fact hotter than the board when the 'sbc-bench -t 50' run starts. Would be really interesting if you run with your setup 'sbc-bench.sh -T 70 ; sbc-bench.sh -t 50' as well.

I'm fine with that. The config file should be overwritten from /dev/urandom (to prevent recovering contents later) and then the partition can simply be deleted. We're thinking about a mechanism that allows average Armbian users to edit 'first boot' behaviour. Experts and users of the build system don't need anything of this since they can customize things already. It's just about a somewhat standardized way to provide a config file that's suitable for Windows and macOS users as well (and that requires a filesystem accessible by those OS)

I don't get it. You want to drop armbian-config? Or what is 'this' you're talking about? Or do you want to add CLI parameters to armbian-config so it could be called automatically and finish the tasks? Anyway: I think what's needed is some rudimentary way to configure a few items that modify default Armbian behavior on first boot. The current https://github.com/armbian/build/blob/master/packages/bsp/armbian_first_run.txt.template version is broken by design since config file would be on an ext4 partition so isn't accessible by vast majority of users anyway and the few 'tweaks' there are of not much use anyway (why should Ethernet and wireless be mutually exclusive?!). Only real interesting one there are wireless credentials. IMO we should focus on @botfap's list for now.

Yes, I think this stuff should go into /usr/lib/armbian/armbian-firstrun-config We also don't want this stuff on a FAT partition and that's why the 'old' way to use a FAT partition for /boot is marked deprecated. Until now I didn't care about position of such a new FAT32 partition but thought it would be better to have at the beginning since I feared rootfs resizing hassles (and never looked into this in detail so if you say it's an easy task then I would prefer the FAT32 partition after rootfs and then moved as part of image resize on first boot)

Why?

That's why I asket for the iostat 5 output. This is what happened in @jmandawg's test: avg-cpu: %user %nice %system %iowait %steal %idle 1.46 0.00 0.57 0.18 0.00 97.79 1.81 0.00 0.50 0.00 0.00 97.69 1.81 0.00 0.60 2.36 0.00 95.23 1.46 0.00 0.57 0.18 0.00 97.79 8.30 0.00 1.06 0.00 0.00 90.64 6.78 0.00 6.93 0.35 0.00 85.93 6.64 0.00 7.14 0.35 0.00 85.87 5.07 0.00 4.00 0.30 0.00 90.63 3.10 0.00 3.71 0.36 0.00 92.83 2.32 0.00 1.82 0.35 0.00 95.51 Not a general CPU bottleneck to spot but of course switching back and force between userspace and kernel.

Nope. Since if you're able to provide the appropriate parameters and did the prerequisits (device nodes, creating partitions) you can also call the few commands nand-sata-install uses internally. So by tweaking the script you get such a CLI parametrization but are on your own to get there.

Why? FAT support is part of Armbian though deprecated. In the past there existed options to create /boot on a small FAT partition -- that's also the way DietPi used Armbian's build system for some time -- but we don't want /boot on a FAT partition since dpkg on FAT is a mess. But asides that I would believe it's as easy as adding this small partition at image creation time.

But if the use case is called 'accessing the Internet' how should this test relate to reality? You get low download bandwidth 'from the Internet' if roundtrip times are too high. That's why I was asking for ping output. There's a relationship between latency and bandwidth most Internet users are not aware of.

https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44168 Since we switched to zram based swap in Armbian recently (will be rolled out with next major release) there are no real differences any more. Please note that OMV can only be installed on Debian Stretch but not Ubuntu.