Jump to content


  • Posts

  • Joined

Posts posted by tkaiser

  1. 2 hours ago, malvcr said:

    I have it running very well now (without antivirus support that always kill the machine)


    Somewhat unrelated but I really hope you're aware that with most recent Armbian release you're able to do MASSIVE memory overcommitments and performance will just slightly suck?


    I'm running some SBC for test purposes as well as some productive virtualized x86 servers since some time with 300% memory overcommitment. No problems whatsoever.

  2. Latest RK3399 arrival in the lab. For now just some q&d photographs:






    @wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here! :)


    A quick preliminary specifications list:

    • RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens)
    • 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149)
    • Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB)
    • Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed)
    • Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board)
    • Serial console available via Micro USB (there's an onboard FTDI chip)
    • 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe)
    • Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures)
    • SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only)
    • 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller)
    • Gigabit Ethernet and separate Fast Ethernet port for the BMC
    • Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1)
    • USB-C port with USB3 SuperSpeed and DisplayPort available
    • eDP and HDMI 2.0
    • USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub
    • USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub
    • 96boards Low Speed Expansion connector with various interfaces exposed
    • 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below)
    • S/PDIF audio out
    • 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed



  3. 3 hours ago, SMburn said:

    Generic Amazon mSATA M.2


    Please be very careful with these wordings. M.2 is not mSATA. M.2 is just a mechanical connector able to transport a bunch of different protocols. In case you have no other device suited for an M.2 SATA SSD you might want to have a look at https://jeyi.aliexpress.com/store/group/USB3-0-USB3-1-Type-C-Series/710516_511630295.html for external USB3 enclosures (to get a bulky but ultra fast 'USB pendrive'). But since a 'generic' 60 GB SSD will perform crappy anyway and you talked about Amazon the best you could do is to return such a thing right now.

  4. 3 hours ago, Faber said:

    I already knew about that

    Great. So you got the 'you can run FreedomBox on any computer that you can install Debian on'. Now you just need to know what Armbian is (Ubuntu or Debian userland with optimized kernel and optimized settings), then as long as you are able to accept running an Armbian Debian flavor is in some way comparable to 'running Debian' you can start. If Armbian is not for you for whatever reason simply wait a few months or years until upstream support for recent/decent ARM hardware arrived in Debian.


    In case you choose Armbian you need to ensure to freeze kernel and u-boot upgrades since otherwise you use a stable distro on an unstable basis (it seems stuff like this needs to happen from time to time for reasons unknown to me).

  5. 3 minutes ago, Jason Law said:

    how will this connect to the M4?


    It's a HAT so you simply mount in on top of the NanoPi using 4 spacers so GPIO headers make contact. Since NanoPi M4 is one of the few SBC that have the SoC on the appropriate side of the PCB (the lower one) attaching HATs does not negatively affect heat dissipation.


    (still hoping that the final version of the HAT will also use a 40 pin male header so the GPIOs on this header can still be used)

  6. 13 minutes ago, NicoD said:

    Weird numbers


    Nope, everything as expected. The M4 number in the list https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md has been made with mainline kernel which shows way higher memory bandwidth on RK3399 (check the other RK3399 devices there). Cpuminer numbers differ due to GCC version (Stretch ships with 6.3, Bionic with 7.3 -- see the first three Rock64 numbers with 1400 MHz in the list -- always Stretch but two times with manually built newer GCC versions which significantly improve cpuminer performance)


    If you love performance use recent software...

  7. Orange Pi R2 announced to be available back in April might be ready in November: https://www.cnx-software.com/2018/09/23/realtek-rtd1296-u-boot-linux-source-code-rtd1619-cortex-a55-soc/#comment-556261


    I wonder whether the board is still at $79 as announced back in April... BPi people charge $93 for their BPi-W2 but there you need to acquire a Wi-Fi/BT combo card that fits into the M.2 Key E slot separately (and by reading through this mess here choosing Bpi's own RTL8822 card seems to be the best idea -- most probably this chip is part of RealTek's reference design)


    BTW: SinoVoip is about to throw out a few new and of course totally incompatible boards soon just to ensure software support situation will be the usual mess :) Watch them here already: http://www.banana-pi.org 

  8. 5 hours ago, sfx2000 said:

    There was a ticket open over on ChromiumOS


    The important part there is at the bottom: the need to 'NEON-ize lz4 and/or lzo' which has not happened on ARM yet, that's why lz4 outperforms lzo on x86 (SIMD instructions used) while on ARM it's the opposite.


    Once some kernel developer will spend some time to add NEON instructions for the in-kernel code for either lzo or lz4 (or maybe even a slower algo) I'll immediately evaluate a detection routine for this based on kernel version since most probably this also then outperforming any other unoptimized algorithm that in theory should be more suited.


    Missing SIMD optimization on ARM are still a big problem, see for example https://www.cnx-software.com/2018/04/14/optimizing-jpeg-transformations-on-qualcomm-centriq-arm-servers-with-neon-instructions/

  9. 48 minutes ago, Jason Law said:

    Has anyone tried a 2 or 4 port SATA controller in the M.2 slot? Does it work?


    Nope and I don't think so. I wanted to try the same, did some research and ended up with an Amazon review from someone trying this with the Firefly RK3399 saying the Marvell 9235 adapter he had has some components on the bottom that make it impossible to use it on the board without shorting something. These things look like this:




    And then on NanoPC-T4 there are only mounting holes for 2280 while the SATA adapters are all 2242. So unless you get a PCIe extender somewhere the M.2 slot is 'SSD only'.


    Are you aware that FriendlyELEC will provide the below for NanoPi M4 soon (also solving the powering problem):




  10. Ok, this is pure madness here. Won't look into this thread for some time.


    @ag123 it's really nice that you're creative and able to develop theories about Linux being broken in general (breaking the system by swapping out important daemons -- I guess you also think kernel developers behave that moronic that they allow to swap out the kernel itself?). It also is nice that you ignore reality (@Moklev having reported a system freeze and not sshd being unresponsive). It also doesn't matter that much that you create out of one single report of 'freezes since some time' for reasons yet unknown a proof that there's something wrong with the new vm.swappiness default in Armbian and talk about 'related issues surfaced currently' (issues --> plural).


    I simply won't read these funny stories any more since they're preventing time better spent on something useful.


    Here are the download stats: https://dl.armbian.com/_download-stats/ Check when 5.60 has been released, count the number of downloads, count the reports of boards freezing/crashing in the forum and you know about 'issues surfaced currently'. 



  11. 5 minutes ago, ag123 said:

    i think for the time being selecting a vm.swappiness in a mid range between 0 to 100 seem to alleviate related issues surfaced currently


    Are you trolling? Which 'related issues'? I only know of one overheating Orange Pi Zero that for whatever reasons is/was unstable. Zero useful efforts taken to diagnose this single problem other than a huge waste of time right now.

  12. Let's stop here. I won't further waste my time with this 'report' (which is just a bunch of theories, assumptions and a weird methodology to back an idea).


    @Moklev: I was asking for armbianmonitor -u output but got only a redacted/censored variant (the line numbers are there for a reason). I was asking for what's the output of 'free -m' NOW. As in 'with your vm.swappiness=30 or 60 setting). Instead you rebooted (why?! You can adjust vm.swappiness all the time, no reboot needed).


    Providing 'free -m' output directly after a reboot is pointless as you see ZERO swapping happened. And providing a log containing information from 14.36.28 until 14.53.31 is pointless too.


    14 minutes ago, Moklev said:

    With wm.swappiness=100: system work fine for a random time (3-12 h), then hang with ... rpi monitor web pages unreachables



    On 9/26/2018 at 10:19 AM, Moklev said:

    Yes, I've starting monitoring...


    Yesterday you started monitoring. Now you report having switched from vm.swappiness=30 to 100. But you're able to report that with 100 settings your board froze and even RPi Monitor web page not being accessible. So you tested within the last 29 hours already twice with 100 settings and were able to report your board crashing (since you talk about '3-12 h' -- if these 3-12h is some anecdotical story from days ago I'm not interested in. It's only relevant what happens now with some monitoring installed able to provide insights).


    I'm interested in resolving real problems if there are any. What happens here is developing weird theories and trying to back them. Unless I get data I won't look any further into this.


    If you had RPi-Monitor running the graphs are available even after a reboot so you can share them focussing on the last hour prior to latest crash (Cpufreq, temperature, load). Also if 'ssh unreachable, yellow ethernet led fixed on, pihole/motioneye/rpi monitor web pagesunreachable' is the symptom then you report your board having freezes or crashed (and not sshd not being responsive any more).

  13. 26 minutes ago, Igor said:

    As you can see I manually tested most of the boards and already that was on the edge what I can do "by the way". I am not sure I will do that ever again and certainly not within the next 6 months. It's painful, time wasteful and it goes by completely unnoticed.


    So what?


    Armbian supports too many boards for us to handle. Nothing new.


    The interesting question still is: how do we provide something that could be called 'stable'? It's simply unacceptable that a simple 'apt upgrade' bricks boards or removes basic functionality (which is not the case here now as I understand -- still wondering why there's a comment reading 'network sometimes doesn't work properly' -- but at the beginning of this year we had a bunch of such totally unnecessary issues caused by untested updates rushed out).


    If it's not possible to prevent such issues (and clearly separating playground area from stable area) the only alternative is to freeze u-boot/kernel updates by default and add to documentation that users when they want to upgrade u-boot and kernel they're responsible for cloning their installation before -- good luck! -- so they can revert to a working version if something breaks.

  14. 2 minutes ago, Igor said:

    My C2 is working without any issues: http://ix.io/1nGc


    So where did your comment 'usb hotpluging and network sometimes doesn't work properly' originates from then?


    I'm not sure whether you get my point: I want Armbian to be a stable distribution. I do not rely unnecessarily on either Debian or Ubuntu with all their 'outdated as hell' software packages if there wouldn't be that great promise of 'being stable'. If I pull in updates I expect that afterwards my device still works. With the userland this is pretty much the case (upstream Debian or Ubuntu) but wrt kernel/u-boot (the Armbian provided stuff) it seems this is impossible.


    Why did you write 'network sometimes doesn't work properly' in your commit message and especially why did you allow a kernel update for ODROID-C2 that is then supposed to break basic functionality? As already said: I'm fine with USB hotplug issues since USB devices connected at boot are fine for 'stable' use cases. But if there are network issues to be expected I really don't get it why then such a kernel update will be rolled out and not skipped this time?


    It's about the process! If an update is to be expected to break functionality then why enrolling it?


    Is it possible to move from playground mode to stable mode? What's the dev branch for when testing obviously also happens in the next branch?

  15. 17 minutes ago, ag123 said:

    i think the issue about the vm.swapiness is that some of the processes, e.g. sshd after it is swapped out i.e. not resident in memory, may not respond or respond too slowly to connects over the network


    WTF? Can we please stop developing weird theories but focus on what's happening (which requires a diagnostic attempt collecting some data)? Without swap it could be possible that the sshd gets quit by the oom-killer (very very very unlikely though because the memory footprint of sshd is pretty low) but if it would be possible that swapping in Linux results in daemons not responding any more or not fast enough we all would've stopped using Linux a long time ago.


    And can you please try to understand that we're not talking about 'swap on crappy storage' (HDD) any more but about zram: that's just decompressing swapped out pages back into another memory area which is lightning fast compared to the old attempts with swap on HDD.

  16. 10 minutes ago, Igor said:

    A network was working OK for some time and at the time of testing but it is possible that one wrong patch finds its way upstream


    Seriously: I don't get this policy. But I think any more discussion is useless and Armbian can just not be considered a stable distribution. Or at least people who are interested in stable operation need to freeze kernel and u-boot updates since otherwise updating the software means ending up with a bricked board or some necessary functionality not working any more (and based on Armbian's origin I consider fully functioning network to be the most basic requirement of all -- but I might be wrong and Armbian in the meantime focuses on display stuff trying to compete with Android)


    I thought once there was a next branch available for ODROID-C2 this could be considered 'stable' (since there's still the 'dev' branch for development and testing). But it seems I've been wrong and we have no definition of 'stable' if it's possible that updates are provided that destroy functionality that has been working flawlessly before.


    So by accident 'default' seems to be the only stable branch in Armbian for the simple reason no kernel development happens there.

  17. 25 minutes ago, ag123 said:

    i think the somewhat elevated temperatures of say 70-75 deg C on H3 socs can be tolerated


    Huh? Can we please stay focused here on an Armbian release upgrade and potential show-stoppers? You brought up the claim that vm.swapiness settings cause crashes without any evidence whatsoever. Let's focus now on collecting some data related to this and keep temperature babbling outside.


    We all know that certain boards report wrong temperatures anyway (OPi Zero rev 1.4 for example) and the only area where this gets interesting is whether those wrongly reported temperatures cause an emergency shutdown (the kernel's cpufreq framework defines that at a specific critical temperature a shutdown is initiated). So obviously with wrong thermal readouts as we experience on some sunxi boards/platforms we get a 'denial of service' behavior under load.


    Using the wrong hardware for specific purposes is not the focus of this thread (e.g. using a board with just 512 MB for desktop linux -- that's not a 'use case', that's just plain weird)

  18. 14 minutes ago, Moklev said:
    zram0             0,00         0,01         0,00          4          0
    zram1             0,00         0,00         0,00          0          0


    Sorry, this thing is doing nothing and especially not swapping. And I'm really not interested in what a MicroServer somewhere on this earth is doing. It's only about Armbian and the claim vm.swappiness=100 would crash your board.


    So as already said, it would be great if you can provide output from the two commands I asked for now

    1 hour ago, tkaiser said:

    So can you please provide output from both 'free -m' and 'armbianmonitor -u' now?


    Since after switching back to vm.swappiness=100 your board is supposed to crash then afterwards it gets interesting to have a look at the two logs (submitted via pastebin.com or some similar online pasteboard service).

  19. 23 hours ago, Moklev said:

    Yes, I've starting monitoring...


    So can you please provide output from both 'free -m' and 'armbianmonitor -u' now? Once you switch back to vm.swappiness=100 the VM monitoring script should be adjusted to

    while true ; do
        echo -e "\n$(date)" >>/root/free.log
        free -m >>/root/free.log
        sleep 60

    (same with iostat -- also switching from 600 seconds to 60. And then the 'sync' call above is very important since with default Armbian settings we have a 600 second commit interval so last monitoring entries won't be written to disk without this sync call happening)

  20. 7 hours ago, sfx2000 said:

    Swappiness=0 didn't really disable swap, it just makes the kernel very aggressive not wanting to swap




    https://forum.armbian.com/topic/7819-sbc-bench/?do=findComment&comment=62802 (


    Less swap activity with vm.swappiness=1 compared to vm.swappiness=0. So again, this is something that needs further investigation. We can not trust in stuff 'Everyone on the Internet' is telling (like lz4 being better than lzo since at least with ARM it's the other way around).


  21. Is this https://forum.openmediavault.org/index.php/Thread/24299 a known issue with 5.60?


    In https://github.com/armbian/testings it's written that 'USB hot plugging' doesn't work which is something I'm fine with. But what does 'networking sometimes doesn't work' means exactly?


    @Igor since I've seen you submitted the test report. What does that mean wrt networking? Isn't the next branch meant as a 'stable' branch where basic functionality has to work flawlessly? Did networking work prior to 5.60 release?

  • Create New...