• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    devman reacted to beni0664 in cryptsetup - supporting no_read_workqueue/no_write_workqueue on SSDs   
    Dear Armbian community,
    although I'm using Armbian a lot, I never had to submit anything to this forum (fortunately, because it works so well :-)),
    On my PC I've experienced lags on heavy IO operations. After a short dig into available information,
    I found a useful Cloudflare article on Kernel queues together with dm-crypt.
    A good & short summary on possible actions for users can be found here:

    Enabling the no-read-workqueue & no-write-workqueue options helped a lot!
    As I'm using a RockPi4 with the NVMe SSD with encryption, I thought this should apply to my SBC as well.
    Unfortunately, Armbian/Debian Buster uses cryptsetup v2.1.0
    which does NOT support these options.
    According to the changelog, this option was introduced in v2.3.4:
    As Armbian uses a kernel > 5.9, the kernel infrastructure should be available.
    Fortunately, crypsetup v2.3.4 exists in the buster-backports repo:
    # sudo apt install cryptsetup/buster-backports
  2. Like
    devman reacted to Werner in Crude NAS with local caching   
    You all know the problem: You have a spare SBC (with USB3) laying around catching dust, a spare SSD or other hard drive and for whatever reason some (terabyte?) space in whatever cloud on the planet and have no idea what to do with it.
    Well here is what I came up with to solve this struggle

  3. Like
    devman got a reaction from gprovost in All SATA drives down after (coincidental?) update   
    @gprovostHit up the local computer mall for a replacement power supply.  Closest they had was 12v 10A to barrel, and then a barrel to 4-pin adapter.
    Anyways, everything checked out correctly, and no more errors.  Thanks!
  4. Like
    devman reacted to TRS-80 in Self-hosting micro- (or regular) services, containers, homelab, etc.   
    I wanted to share an article I came across, I thought was pretty good.  Keep in mind I am starting from zero with Docker recently, if you are already familiar, this article might be too basic for you.  The article walks you through several of basic Docker tasks (create, run, inspect, ssh into, etc.) on command line:
    Getting started with Docker for the Inquisitive Mind
    They have other related content on their site as well which I have only skimmed so far, but it looks pretty good.  I always appreciate websites with clean looking CSS that work well (including mouseover effects) without requiring JavaScript to be enabled (which I block by default). 
    What's everyone else been up to?  Come on, don't be shy now. 
  5. Like
    devman reacted to TRS-80 in Self-hosting micro- (or regular) services, containers, homelab, etc.   
    I have been having some long running, on and off discussion with @lanefu in IRC (and elsewhere), because I know this is his area of expertise.  However he is busy, and I can appreciate he might not want to spend his free time talking about stuff he gets paid to do M-F. 
    Then I also realized, certainly I am not the only one interested in Armbian in order to be doing such things.  So I thought I would make a thread about this, instead, to open the discussion to a larger group people here in the broader community.
    I have my own thoughts, concerns, things I want to do, and have already done, but I thought I would make a more general thread where like minded people can discuss their experiences, what has worked (or not), what services you might be running (or would like to), etc.
    I guess I will begin by saying I have been running some services for family and friends, first on a Cubietruck since maybe 2017 (or earlier?) and then later on some ODROID-XU4 in addition.  I run XMPP server (Prosody) which has been very hassle free "just works" as well as some experiments into Home Automation and other things which have had some, well let's just say mixed results. 
    Currently my interest is in containers and like technologies, but I am very new to it.  I been reading a lot, but there is so much to know and I can't help but feel I am a bit late to the game.  That's by design though, as I don't like being (too) early of a technology adopter, generally speaking.  Well, certainly not with such "hyped" technologies like containers, anyway.
    In fact I thought it was a bunch of baloney and hype for a long time, but even cranky old cynic like me now sees some advantages of abstracting things, changing servers/services from "pets" to "cattle" if you will, for reproducibility, redundancy, and other reasons.
    Anyway, I am prone to walls of text of idiotic ramblings, so I will stop here and give some others a chance.    Hope everyone is enjoying their holiday weekend so far. 
  6. Like
    devman reacted to Werner in Helios4 Support   
    As announced Kobol got a dedicated place for their producs. Therefore it is no longer necessary to have one hugh thread collecting everything related to this particular board.
    Now you can create new topics for each new issue/problem/question which greatly will increase readability and overall clarity.
    This topic is being archived and locked.
  7. Like
    devman reacted to JMCC in SBC with proper software support for hardware video transcoding   
    Good news! I got to compile a highly optimized ffmpeg binary from a current git, with XU4 tweaks, that is able to encode two simultaneous 1080p@25, as long as the source bitrate is not excessive.
    You can download and give it a try from here. It is completely static, so you can install it on any distro. It will install the binary in "/opt/ffmpeg-xu4/bin/ffmpeg", and a symlink "/usr/local/bin/ffmpeg-xu4". Therefore, it can be installed along the system ffmpeg without conflicts.
  8. Like
    devman reacted to JMCC in SBC with proper software support for hardware video transcoding   
    TL;DR: Odroid XU4/HC1/MC1

    Sorry, I didn't see this post before. I have a jellyfin server on a Odroid HC1, working like a charm since long ago. HW transcoding can do 1080p with no problem. I have special ffmpeg packages for Armbian buster, in case you want them.

    Enviado desde mi moto g(6) plus mediante Tapatalk

  9. Like
    devman reacted to Letterus in /proc/cpuinfo show only .LITLLE cores on Odroid-HC1 - hints appreciated   
    jshc1: I've no problem with loosing 200Mhz (the cooling plate still gets quite hot sometimes), but I would have if the system uses the wrong cores for the hard work.
    Thanks to your hint I detected htop was set up wrong. I don't know how this happened, but hinstead of showing CpuFreq1 to 8 it was showing the variable CpuFreq (without any number) 8 times. CpuFreq only showed the "little" CPU freq.
    So, thanks to this hint, I consider this issue solved. :-)
  10. Like
    devman reacted to sgjava in Java Periphery released!   
    Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
    Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
    Nano Pi Duo
    13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
    15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second  
  11. Like
    devman got a reaction from manuti in Big sale on Odroid MC1   
    Probably, depending on your content type and target device.  I did some rudimentary testing with transcoding on the NanoPi M3, and it technically worked. 
    I had stability issues though, so I switched to a small/cheap x86 box that supported hardware transcoding.
  12. Like
    devman got a reaction from gounthar in Big sale on Odroid MC1   
    Mine arrived a few days ago.  Still need to scrounge up an appropriate power supply, fan and hub. 
    Thanks for the heads up, @gounthar!
  13. Like
    devman reacted to gounthar in Big sale on Odroid MC1   
    I don't know where to write it, but if there is someone looking for MC1 at discount price, there is a big sale going on.
    I took 5 of them to build a h.264 encoding farm.
  14. Like
    devman reacted to Igor in Armbian 19.11.y release notes   
    Release details
    Upgrading your Armbian to v19.11.y
    This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
    apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
    Choose latest version of 19.11.x and select upgrade according to this scheme:
    Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:

    Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
    Main build system changes
    Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
    LIB_TAG="v19.08" to your build config file which by default is:
    userpatches/config-default.conf Then run your script as you did before.
    Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.

    In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.

    Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
  15. Like
    devman reacted to Igor in NanoPi NEO Air v1.1 no wlan0 after install   
    Miracles are usually made by bad/cheap powering.
    If your powering is on the edge, this is the case.
  16. Like
    devman got a reaction from markbirss in OrangePi Zero H2 Ram Upgrade   
    Actually, nothing is wrong. You got exactly what you should expect.  The K4B4G1646E-BYMA is a 4 gigabit ram module.
    BTW: impressive that you can resolder a BGA at home. Congrats.
  17. Like
    devman reacted to mu-b in Espressobin support development efforts   
    Well I've fixed my instability issue. The root cause was the same as, and it was power related. The fix was to replace the 470uf/16V capacitor (component EC1 on the schematic) sat immediately behind the 12V DC jack which under testing leaked under certain temperature conditions (variations). As such the board is now stable and has been running OpenWRT 18.06.2 for 24 hours with memtester and stress running continuous during that entire time.
    I'll leave it a few more days, after that I'm going to assume that its fixed and that is what NetGate were referring too when they mention 'a power related component'.
    And GlobalScape will not tell you, they know of the problem, in a reply from Kevin Liu he says 'Yes, I do have knowledge regards the power related component issue.' when I asked which component it was so i could attempt to replace myself.
  18. Like
    devman got a reaction from gounthar in La Frite (AML-S805X-AC)   
    Yeah, no tracking number here either.  My order just appeared via local courier on Monday.
    They said they'd have an OS image up by (last) Wednesday, but nothing yet.
  19. Like
    devman got a reaction from gounthar in La Frite (AML-S805X-AC)   
    FYI, the Kickstarter rewards are starting to arrive. 
  20. Like
    devman got a reaction from gounthar in Which boards to get a VPN server and a VPN client?   
    heh, sorry, I mean that the neo2 has no wifi.  It's a ethernet-only board, and (without breaking out the pin header) only one usb-A port soldered.
    The neo plus 2 might be closer to what you're looking for, but it's not a board I have.  Should be very, very similar in performance though.
  21. Like
    devman got a reaction from gounthar in Which boards to get a VPN server and a VPN client?   
    I'm running wireguard on a pair of nanopi neo2's, and iperf is giving me >200mbps throughput at ~40% load
  22. Like
    devman reacted to Igor in Monitoring your system health with HTOP (big.LITTLE)   
    ... and I have build it and pushed to Armbian stable repository (Stretch, Xenial and Bionic; armhf+arm64). First boot scripts also creates CPUfreq config based on CPU count. More can be added if there is an interest ... Package can be installed via apt update and upgrade while auto config feature will work only on self made images.
  23. Like
    devman reacted to @lex in Monitoring your system health with HTOP (big.LITTLE)   
    Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
    You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
    HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
    DEB package and source code in case you want to extend or fix things.
    Be aware the process list and task can be very intrusive if you want to monitor many things at once.
    It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.


  24. Like
    devman reacted to chwe in Daily (tech related) news diet   
    You probably should link to the original post cause the Register tends to be a bit....;curpostid=183486
    His statements in the whole context sound a way more reasonable:
    besides a few SBCs, ARM SoCs are 'only' found in Android, where power-consumption matters a way more (it matters for servers as well but it's not the 'main' thing, whereas for mobiles it is).. Routers etc. are mostly driven by MIPS. Intel tried once (with throwing a bunch of money into it) to enter the android world but they horribly failed and canceled more or less their low consumption small chips...
    and that is actually true, Armbians buildscript is also x86 only, cause it might be hard to find good build servers to natively build our images on ARM.
    Price matters.. The more volume, the lower the price.. See (android) TV-boxes.. where intel has no chance to enter the market..
    well, I quoted this one just cause it's funny.
    I programmed once my calculator, it was painful cross-platform an on itself.. But that's more related to the capabilities of it.. I think @JMCC is one of the few here who compiles debian packages on the SBCs itself (except @wtarreau)..
    and followup:;curpostid=183500
    make a nice case and don't tell him that there's a pinheader on it, maybe he don't see a difference..
    Don't get me wrong, willy's buildfarm ( is great, but not everyone wants to build such a farm just to avoid cross-compiling.
    besides merging he probably never contributed a single bit to ARM development on Linux (I could be wrong here, I don't have record on which sub-systems he contributed in the beginnings). But as he stated multiple times, he's more 'kernel manager' and gate-keeper than programmer.. Just read through a few speaks from him to get a clue about his job in kernel development.

    It's not that he dislikes arm.. There are multiple statements where he was in favour for an arm based machine (especially during the spectre/meltdown phase he made some of them). But where others try to be as polite as possible, he prefers a rather strong wording to make his points clear. And I would say he has enough valid arguments to point out why arm is nowhere on server at the moment.

    IMO not at all, development of linux on arm won't stop cause Linus says that he doesn't think that arm will make it on the server market.. All our SBCs (except maybe the SolidRun) aren't server SoCs. We deal mostly with TV-box SoCs here.. As long as they push their stuff upstream and the code quality is good, he will merge it.. He just points out clearly why (in his opinion) arm won't enter the server market.. There aren't (m)any affordable workstations nor notebooks nor simple desktop computers based on arm, so that people deploy stuff on ARM. Even on bigger distros (Debian, Ubuntu, Suse etc.) arm is only the side-kick of x86 or AMD64. I don't think that this will change soon. Just look at commercial binary only software... If there's Linux support for it, it's mostly x86 only.. More or less nobody provides arm64 or armhf packages of their binaries..
  25. Like
    devman got a reaction from lanefu in Is Mali GPU driver available in Mainline for H3?   
    I remember reading the history of the Lima project a while ago, and it basically comes down to that ARM doesn't WANT an open-source implementation of the graphics drivers, as they make a not-insignificant amount of money licensing theirs.