dolphs

  • Content Count

    247
  • Joined

  • Last visited

About dolphs

  • Rank
    Elite member

Profile Information

  • Gender
    Male
  • Location
    Netherlands

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. tried my rockpi4a , similar results ( bad ) as H5 and H6. Once switched to legacy 4.4 kernel, things rock and faster results again. really wonder what is causing this: patch, kernel realtek driver, both / something else : lost?!
  2. well I decided to bring in the r4s and flashed latest dev image ( 5.10.9-rockchip64 ). Long story short .. using westwood both ways seem to be meeting my needs, using bbr to site is also fine - but from site to home bbr is rubbish below results: - fresh dev image built r4s , connected to " enp1s0 " and results below - without changing anything: iperf3 -4 -c somewhere.dynu.net -t 300 -b 0 -P 1 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 5.10 MBytes 42.8 Mbits/sec 501 391 KBytes [ 5] 1.00-2.00 sec 3.7
  3. at this stage I have continuous 40Mbit upload ( RPi4 ) and other way round ( H6 or H5 board ) : site to my Rpi4 disappointing speed using only these "tweaks" net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr [ 5] 0.00-1.00 sec 1.76 MBytes 14.8 Mbits/sec 0 110 KBytes [ 5] 1.00-2.00 sec 440 KBytes 3.60 Mbits/sec 0 102 KBytes [ 5] 2.00-3.00 sec 440 KBytes 3.60 Mbits/sec 0 93.5 KBytes [ 5] 3.00-4.00 sec 440 KBytes 3.60 Mbits/sec 0 96.2 KBytes [ 5] 4.00-5.00 sec 879 KBytes 7.20 Mbits/sec
  4. hmm, this needs further analysis. It appears if I upload from my side ( where I currently reside ) to my remote site I get awful upload speeds on the H6 ( and H5 ) : ( no congestion even set ) and no VPN even : [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.57 MBytes 13.2 Mbits/sec 2 20.5 KBytes [ 5] 1.00-2.00 sec 440 KBytes 3.61 Mbits/sec 0 45.1 KBytes [ 5] 2.00-3.00 sec 880 KBytes 7.21 Mbits/sec 0 62.9 KBytes [ 5] 3.00-4.00 sec 880 KBytes 7.21 Mbits/sec 3 47.9 KBytes [ 5] 4.00-5.00
  5. hmm , recently it came to my attention bbr between both wireguard servers is doing a very bad job: :/etc/sysctl.d# iperf3 -4 -c 192.168.10.2 -t 300 -b 0 -P 1 Connecting to host 192.168.10.2, port 5201 [ 5] local 192.168.20.2 port 41804 connected to 192.168.10.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.29 MBytes 10.8 Mbits/sec 0 112 KBytes [ 5] 1.00-2.00 sec 502 KBytes 4.11 Mbits/sec 0 104 KBytes [ 5] 2.00-3.00 sec 753 KBytes 6.17 Mbits/sec 0 98.9 KBytes [ 5] 3.00-4.00 sec 753 KByte
  6. Device with housing arrived today, cannot wait to deploy armbian on it :-), but will need to have some more patience Once image is ready ( to be build ) and entered matured state will swap it with my OpiOnePlus as I'll solely use it for wireguard ( and ddclient / chrony )
  7. done a few more ( approx 6 ) till now and all looking good, will start with cold boot early morning to see how things go and give a few more reboots after that. but seems to be fine on this H6 board, over to topic : OrangePi3 [EDIT] Meanswhile executed reboots and cold starts, OPiOnePlus came back OK all the time ( kernel 5.9.16 ) [/EDIT]
  8. my spare OpiOnePlus has been upgraded , dont have Opi3 either. Anyway to see if the OPiOnePlus is unaffected will reboot few times today and see if it comes back online normally ....
  9. looks like 5.9 images are being published as recommended, therefore suppose fix/workaround is in place ? That would be very nice!
  10. Ordered 1Gb version incl housing just now , let's hope at least WIP status will appear next few months for this one.
  11. Looks like updating " /etc/default/keyboard " would be sufficient then to roll things back : " sed -i 's/us,ro/us/g' /etc/default/keyboard ". I'd propose to have this manually controlled ( thru personal settings in armbian-config ) and leave "us" default. cat /etc/default/locale # looks fine default # File generated by update-locale LC_MESSAGES=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LANG=en_US.UTF-8
  12. Hi - Is following new in Tamandua ( and images that are built from scratch currently ) ? Any flag to disable this so US would be default ( as it used to be ) and thus following won't be asked/ set? New to Armbian? Documentation: https://docs.armbian.com Support: https://forum.armbian.com New root password: ******** Repeat password: ******** Detected timezone: Europe/Bucharest (EET, +0300) Generating locales: ro_RO.UTF-8 Adding console keyboard layout: ro Creating a new user account. Press <Ctrl-C> to abort
  13. there is indeed the culprit
  14. certainly', this due @Igorwaving is magic wand :-)
  15. Well , it seems the 5.9.8 image I just downloaded ( Armbian_20.11.0-trunk.41_Nanopineo2_buster_current_5.9.8.img.xz ) did boot ok. Therefore spun up a fresh 5.9.10 build to see how that went ... Alas no go ... Yet trying to rule things out , but looks like it is my build environment as I seem to have issues with other boards too ( or flags I am using ) , thus apologies polluting this thread - once sorted will report back 5.10 should build fine imho - ./compile.sh BRANCH=current RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no E