Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Posts posted by tkaiser

  1. 1 hour ago, el_pablo said:

    Knowing that Microchip is very reliable

     

    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.'

  2. 1 minute ago, chwe said:

    It may work with https://github.com/armbian/build/pull/824 by changing the defaults from 0.1 to something more realistic

     

    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.

  3. 2 hours ago, DaveKimble said:

    armbianmonitor -m 1

     

    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)

  4. 20 minutes ago, TonyMac32 said:

    4x drives is getting to serious supply territory, I would guess 60 Watts or so (total, not just drives) without actually doing any math (so margin of error probably decently high).  Without driving significant cost I wonder about all of that fitting on a hat comfortably.  (I'd also love to see it, do not misunderstand)

     

    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.

  5. 8 hours ago, TonyMac32 said:
    10 hours ago, tkaiser said:

    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)

    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.

  6. 2 hours ago, sfx2000 said:

    zram.sh - put this over in /usr/bin/zram.sh and make it executable

     

    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)

  7. 2 hours ago, DaveKimble said:

    I can't see any logic that would produce this output

     

    1. Why don't you use armbianmonitor -m to monitor (-m 1 if you want output every second)
    2. 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)
    3. 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)
    2 hours ago, DaveKimble said:

    Is the temperature control working?

     

    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.

  8. 3 hours ago, emk2203 said:

    I tried to run the setup you suggested; my SoC won't heat up beyond 69 °C. The temperature fluctuates between 67 and 69 °C, but never reaches 70 °C. Took it off the table and put it back in the box it came in, but this accounts only for 1 K difference

     

    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.

  9. On 9/16/2018 at 9:34 AM, esbeeb said:

    That is to say, which "Supported" Armbian boards have true SATA (not behind USB), and have Gigabit Ethernet?

     

    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)
  10. 23 hours ago, esbeeb said:

    I would want this sort of assurance before trusting any "stable" board for being suitable for a simple NAS, having rock solid stability for disk I/O.

     

    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).

  11. 9 minutes ago, emk2203 said:

    Yes, I have noticed the differences in compiler versions etc., but that you get 8.7 kH/s in CPUMiner and I get  10.6 kH/s is quite a difference - more than 22%

     

    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)

     

    12 minutes ago, emk2203 said:

    My system also has  a copper shim (15x15x1.0mm) and reaches only 66.1 °C after cpuminer. The version is also 1.3.3, same as you used

     

    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.

  12. 37 minutes ago, Igor said:

    If we are going to add FAT partition, we need to think over and test it profoundly. Perhaps at the end if 1st is not FAT already and remove it the rootfs resize process?

     

    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.

     

    33 minutes ago, lrrr said:

    seems like this thread is going in different direction.  Have fun... but FAT?!?

     

    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)

  13. 57 minutes ago, Igor said:

    Perhaps even make armbian-config command line friendly & more modular and get rid of this as well?

     

    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.

  14. 2 hours ago, botfap said:

    I was trying to keep its mechanism separate from Armbians so as to not break things but I gather this is something you would like to see integrated into Armbian? Is that correct?

     

    Yes, I think this stuff should go into /usr/lib/armbian/armbian-firstrun-config

     

    2 hours ago, botfap said:

    I dont want my kernel and boot config files on a fat32 partition. The extra step of moving a 32mb volume in the rootfs resizing is minimal

     

    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)

  15. 6 hours ago, root said:

    If you want more speed out of OpenVPN, the only choice is a better CPU. The performance scales pretty much linearly.

     

    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.

  16. 16 minutes ago, peter12 said:

    is it possible (if yes, how or what are available parameters) to run nand-sata-install from command line "one liner" - I mean without going to programm GUI?

     

    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.

  17. 22 minutes ago, botfap said:

    a fat partition with config and help is the best solution but putting it at the start is a pain and I suspect requires lots of framework changes

     

    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.

  18. 3 minutes ago, jmandawg said:

    I think the only way to truly test openvpn speed would be on your internal network

     

    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.

  19. 9 hours ago, MadMax said:

    Is there a difference between installing Armbian and then OMV via Softy vs the OMV images?

     

    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.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines