Jump to content

vlad59

Members
  • Posts

    180
  • Joined

  • Last visited

Posts posted by vlad59

  1. I just did a armbian-config -> System ->  Firmware : run apt update & apt upgrade. It went fine.

     

    I'm not sure it worked though (u-boot stayed with 20.02.5 and not 20.02.7 with label 2019.10)  :

     

    root@minus:~# dpkg -l | grep linux-
    ii  binutils-arm-linux-gnueabihf       2.30-21ubuntu1~18.04.2              armhf        GNU binary utilities, for arm-linux-gnueabihf target
    ii  linux-base                         4.5ubuntu1.1                        all          Linux image base package
    ii  linux-bionic-root-current-bananapi 20.02.5                             armhf        Armbian tweaks for bionic on bananapi (current branch)
    ii  linux-dtb-current-sunxi            20.02.7                             armhf        Linux DTB, version 5.4.28-sunxi
    ii  linux-image-current-sunxi          20.02.7                             armhf        Linux kernel, version 5.4.28-sunxi
    ii  linux-libc-dev:armhf               4.15.0-91.92                        armhf        Linux Kernel Headers for development
    ii  linux-u-boot-bananapi-current      20.02.5                             armhf        Uboot loader 2019.10

    is there a quick way to check the uboot installed in the SD (I'll hook a HDMI monitor and see if the version is show there) ?

  2. I use docker 24/7 for my home automation for at least 2 years (almost 3). First on a banana pi and since 3 months on a Orange Pi +2E (I switched for the 2Gb of RAM).

     

    I have a dozen of small containers (many small home made python script, mqtt server, nzbget, home assistant, traefik, ...) running all the time and it works great.

     

    I don't know what to say specifically as it's been working mostly good. The only caveat I have is that sometimes docker bridge network get stucked and I have to reboot to get it back but it happened 3 times over 2 years.

  3. I also did the test with wget (on a SSD) :

     

    wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.5.tar.xz
    --2019-12-19 09:17:14--  https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.5.tar.xz
    Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176
    Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 109435988 (104M) [application/x-xz]
    Saving to: ‘linux-5.4.5.tar.xz’
    
    linux-5.4.5.tar.xz                     100%[=========================================================================>] 104,37M  15,1MB/s    in 6,9s
    
    2019-12-19 09:17:21 (15,1 MB/s) - ‘linux-5.4.5.tar.xz’ saved [109435988/109435988]
    

     

  4. Nope the Bpi M1 can do much more, see here :

     

    Your test file is not so quick to download :

     

    root@minus:~# curl -o /dev/null https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.5.tar.xz
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100  104M  100  104M    0     0  13.0M      0  0:00:07  0:00:07 --:--:-- 13.4M
    root@minus:~# curl -o /dev/null http://test-debit.free.fr/1048576.rnd
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
     32 1024M   32  332M    0     0  93.6M      0  0:00:10  0:00:03  0:00:07 93.6M^C

    The slowing factor is often the disk.

  5. Hi,

     

    I just had a huge boost on my Internet speed (1Gbs down / 600Mbps up), it's a good thing but it showed that many of my SBC that are running 24/7 are not ready to handle such high bandwidth.

     

    In each case running a curl outputting to /dev/null -> I almost top out the Gigabit interface -> 99Mo/s.

     

    When I test download speed (while saving on disk) :

     * Old Banana pi running kernel 4.14.18-sunxi (armbian of course but not updated with stretch) with an Kingston SSD on the SATA port -> cannot go over 12~14Mo/s (Mo/s not Mb/s)

     * Orange Pi +2E running 4.19.62-sunxi (armbian with ubuntu Bionic) with a Sandisk SSD on usb2 with a UAS adaptor -> cannot go over 35~37Mo/s.

     

    I have updated another Banana pi with latest Armbian (Bionic / kernel 5.3.X), it includes the patch to fix SATA write speed still with a SSD -> 37Mo/s using wget and 44Mo/s using aria2c (with a single connection)

     

    Each test was done with HTTP download from a VPS I own with 1Gb/s interface and plenty of bandwidth. I'll make other test with NFS later.

     

    So far the lesson I learned -> update Armbian more often ;) !

     

    I'll debug more to see if I can tweak some interrupts / mtu / disk parameter to get a few % more. If you have some idea please share !

  6. Hi all,

     

    I have a Tanix TX6 4Gb/32Gb on the way. I hope to use it with armbian (if that does not work, I'll use libreelec but I'd prefer having a generic linux). Is there a step by step guide on how to build an armbian image. I read the whole thread and saw that megous tree is almost good to go especially with 5.4 that got a lot of patch included. It's less clear for uboot, is latest uboot good to use or is there some patch to use.

     

    Is there a fork of armbian/build with everything included maybe ?

     

    Thanks in advance for any help

  7. A little late but it's working fine

     

    root@pine64:~# uname -a
    Linux pine64 5.3.1-sunxi64 #5.97 SMP Mon Sep 23 18:28:48 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux
    root@pine64:~# ethtool eth0
    Settings for eth0:
            Supported ports: [ TP MII ]
            Supported link modes:   10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Half 1000baseT/Full
            Supported pause frame use: Symmetric Receive-only
            Supports auto-negotiation: Yes
            Supported FEC modes: Not reported
            Advertised link modes:  10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Half 1000baseT/Full
            Advertised pause frame use: Symmetric Receive-only
            Advertised auto-negotiation: Yes
            Advertised FEC modes: Not reported
            Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                                 100baseT/Half 100baseT/Full
                                                 1000baseT/Half 1000baseT/Full
            Link partner advertised pause frame use: Symmetric Receive-only
            Link partner advertised auto-negotiation: Yes
            Link partner advertised FEC modes: Not reported
            Speed: 1000Mb/s
            Duplex: Full
            Port: MII
            PHYAD: 1
            Transceiver: internal
            Auto-negotiation: on
            Supports Wake-on: d
            Wake-on: d
            Current message level: 0x0000003f (63)
                                   drv probe link timer ifdown ifup
            Link detected: yes
    root@pine64:~#

    for now my patch is in `userpatches/kernel/sunxi-dev/`. If I understand correctly I just have to move the patch to `patch/kernel/sunxi-dev/` and make a PR, right ?

  8. @martinayotte@Igor

    I finally found where I read about problem on some pine64+ for ethernet, it was in Librelec forums and Jernej added a patch fixing that a few weeks ago : https://github.com/LibreELEC/LibreELEC.tv/blob/9d68e4ba191d7b0bd319e1e254610917e69526e0/projects/Allwinner/devices/A64/patches/linux/03_pine64_plus_ethernet_fixes.patch

     

    The last part of the patch is interesting (= could fix my problem) and was queued for kernel 5.4 : https://lkml.org/lkml/2019/9/18/714

     

    Grepping for `config-magic-for-pine64` or `regulator-enable-ramp-delay = <100000>` inside armbian build source return nothing so I guess that can be it.

     

    I'll try a dev build with this patch tomorrow and report here either way.

  9. That's strange indeed,

    I'll try a new build in a few days (it's currently building and uploading new arm64 docker images 24/7)

     

    It was perfectly working with a dev build between the end of july and the beginning of august. I had many problem with date jump in 2114 so I tried updating yesterday (apt-get update && upgrade) and had the problem with eth0. I then tried a full install and I had the same problem.

     

    As I said I still have a few days of work for the pine64 and I'll retry a new build

     

     

  10. @eyatsko

    What is the total cable length for your 6 sensors ? Do you use CAT5 / CAT6 ?

     

    5 or 6 years ago, I tried to add 4 sensors in each of my first floor rooms (in the ceiling) -> 4 * 4 = 16 DS18B20 but it was way too much cable length (even with cat5) to have a consistent sensor read. I often had only 8 or 9 sensor available (and sometimes to whole bus disappeared). I tried lowering the pullup, it helped. I tried replacing my only pullup with 3 (and even 4) 15k (distributed along the cable) : it also helped but it was never perfect.

     

    Finally I ended up with 4 buses of 4 sensors using 4 pins and it was flawless.

     

    Less interesting for you but now I have a single ESP8266 for each room with a some i2c sensors (SI7021, ...). All my DS18B20 were donated or binned.

     

    Hope this helps

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines