dolphs
-
Posts
275 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by dolphs
-
-
hello all - trying to find out when v5.67 will be final having all these juicy bits from DEV incorporated,
in my case both NanoPi NEO2 ( older version ) and current LTS do work fine so far on this release.
then again I use the boards just for ovpn so nothing to fancy ( in terms of GPU, etc )
-
hi running armbian ( kernel 4.14 ) and ovpn 2.4.6 and both nanopi neo2 boards.
ovpn is configured with cipher AES-128-CBC and auth SHA256, following results can be seen:
top - 04:53:47 up 26 days, 11:42, 2 users, load average: 0.16, 0.16, 0.09 Tasks: 102 total, 2 running, 57 sleeping, 0 stopped, 0 zombie %Cpu0 : 1.0 us, 1.0 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 1.0 us, 2.0 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 20.7 us, 30.1 sy, 0.0 ni, 43.5 id, 0.0 wa, 0.0 hi, 5.7 si, 0.0 st %Cpu3 : 0.3 us, 0.3 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem : 494152 total, 128980 free, 92528 used, 272644 buff/cache KiB Swap: 247072 total, 229664 free, 17408 used. 382416 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1191 root 20 0 10180 6132 5324 R 59.1 1.2 137:16.90 openvpnand following with single thread " iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1 "
iperf 3.1.3 Linux vpn01 4.14.70-sunxi64 #274 SMP Wed Sep 19 12:09:30 CEST 2018 aarch64 Time: Sun, 09 Dec 2018 02:53:07 GMT Connecting to host 192.168.10.2, port 5201 Cookie: vpn01.1544323987.071807.somewhat TCP MSS: 1276 (default) [ 4] local 10.8.0.2 port 63472 connected to 192.168.10.2 port 5201 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 60 second test [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 9.07 MBytes 75.9 Mbits/sec 199 1.24 MBytes [ 4] 1.00-2.00 sec 8.75 MBytes 73.4 Mbits/sec 166 1.09 MBytes [ 4] 2.00-3.00 sec 12.5 MBytes 105 Mbits/sec 0 1.35 MBytes [ 4] 3.00-4.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.36 MBytes [ 4] 4.00-5.00 sec 7.50 MBytes 62.9 Mbits/sec 54 1.22 MBytes [ 4] 5.00-6.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.22 MBytes [ 4] 6.00-7.00 sec 7.50 MBytes 62.8 Mbits/sec 0 1.24 MBytes [ 4] 7.00-8.00 sec 8.75 MBytes 73.5 Mbits/sec 0 1.16 MBytes [ 4] 8.00-9.00 sec 8.75 MBytes 73.3 Mbits/sec 0 1.21 MBytes [ 4] 9.00-10.00 sec 11.2 MBytes 94.4 Mbits/sec 0 1.41 MBytes [ 4] 10.00-11.00 sec 8.75 MBytes 73.4 Mbits/sec 3 1.59 MBytes [ 4] 11.00-12.00 sec 7.50 MBytes 63.0 Mbits/sec 46 1.58 MBytes [ 4] 12.00-13.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.27 MBytes [ 4] 13.00-14.00 sec 7.50 MBytes 62.9 Mbits/sec 25 1.17 MBytes [ 4] 14.00-15.00 sec 11.2 MBytes 94.4 Mbits/sec 0 1.40 MBytes [ 4] 15.00-16.00 sec 11.2 MBytes 94.4 Mbits/sec 15 616 KBytes [ 4] 16.00-17.00 sec 6.25 MBytes 52.4 Mbits/sec 9 1.25 MBytes [ 4] 17.00-18.00 sec 8.75 MBytes 73.4 Mbits/sec 252 1.15 MBytes [ 4] 18.00-19.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.24 MBytes [ 4] 19.00-20.00 sec 10.0 MBytes 83.8 Mbits/sec 29 684 KBytes [ 4] 20.00-21.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.24 MBytes [ 4] 21.00-22.00 sec 7.50 MBytes 62.9 Mbits/sec 194 1.26 MBytes [ 4] 22.00-23.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.25 MBytes [ 4] 23.00-24.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.16 MBytes [ 4] 24.00-25.00 sec 12.5 MBytes 105 Mbits/sec 0 1.43 MBytes [ 4] 25.00-26.00 sec 6.25 MBytes 52.4 Mbits/sec 46 1.42 MBytes [ 4] 26.00-27.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.40 MBytes [ 4] 27.00-28.00 sec 8.75 MBytes 73.4 Mbits/sec 18 1.24 MBytes [ 4] 28.00-29.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.23 MBytes [ 4] 29.00-30.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.37 MBytes [ 4] 30.00-31.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.26 MBytes [ 4] 31.00-32.00 sec 8.75 MBytes 73.4 Mbits/sec 64 1.15 MBytes [ 4] 32.00-33.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.16 MBytes [ 4] 33.00-34.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.34 MBytes [ 4] 34.00-35.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.34 MBytes [ 4] 35.00-36.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.26 MBytes [ 4] 36.00-37.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.29 MBytes [ 4] 37.00-38.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.25 MBytes [ 4] 38.00-39.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.25 MBytes [ 4] 39.00-40.00 sec 10.0 MBytes 83.8 Mbits/sec 0 1.16 MBytes [ 4] 40.00-41.00 sec 11.2 MBytes 94.4 Mbits/sec 0 1.37 MBytes [ 4] 41.00-42.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.38 MBytes [ 4] 42.00-43.00 sec 7.50 MBytes 63.0 Mbits/sec 79 1.07 MBytes [ 4] 43.00-44.00 sec 8.75 MBytes 73.4 Mbits/sec 34 728 KBytes [ 4] 44.00-45.00 sec 7.50 MBytes 62.9 Mbits/sec 99 1.38 MBytes [ 4] 45.00-46.00 sec 7.50 MBytes 62.9 Mbits/sec 200 1.38 MBytes [ 4] 46.00-47.00 sec 8.75 MBytes 73.4 Mbits/sec 62 1.21 MBytes [ 4] 47.00-48.00 sec 7.50 MBytes 62.9 Mbits/sec 22 1.26 MBytes [ 4] 48.00-49.00 sec 8.75 MBytes 73.5 Mbits/sec 0 1.33 MBytes [ 4] 49.00-50.00 sec 8.75 MBytes 73.4 Mbits/sec 5 1.23 MBytes [ 4] 50.00-51.00 sec 7.50 MBytes 62.8 Mbits/sec 0 1.25 MBytes [ 4] 51.00-52.00 sec 10.0 MBytes 84.0 Mbits/sec 0 1.30 MBytes [ 4] 52.00-53.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.29 MBytes [ 4] 53.00-54.00 sec 8.75 MBytes 73.4 Mbits/sec 4 1.26 MBytes [ 4] 54.00-55.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.24 MBytes [ 4] 55.00-56.00 sec 8.75 MBytes 73.4 Mbits/sec 0 1.23 MBytes [ 4] 56.00-57.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.19 MBytes [ 4] 57.00-58.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.23 MBytes [ 4] 58.00-59.00 sec 7.50 MBytes 62.9 Mbits/sec 0 1.21 MBytes [ 4] 59.00-60.00 sec 6.25 MBytes 52.4 Mbits/sec 0 1.24 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 520 MBytes 72.7 Mbits/sec 1625 sender [ 4] 0.00-60.00 sec 514 MBytes 71.8 Mbits/sec receiver CPU Utilization: local/sender 1.5% (0.1%u/1.3%s), remote/receiver 3.5% (0.4%u/3.2%s) iperf Done.also did not tweak kernel settings too much atm - both ends read:
net.core.default_qdisc = fq_codel net.core.netdev_max_backlog = 1024 net.core.rmem_max = 33554432 net.core.wmem_max = 33554432 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.tcp_wmem = 4096 87380 33554432 net.ipv4.tcp_congestion_control = bbr # RETEST westwood OR cubic net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.ip_local_port_range = 9000 65535If you want a cheap and low wattage VPN consider H5 boards ( eg nanopi neo2 or orange pi zero plus2 ) that should handle proper TV streaming (15-20Mbit) over ovpn this is your option.
If speed will be most important consider other platforms, I'm currently looking in to the ASRock J4005B-ITX and should do 300Mbit ...
-
isn't jessie deprecated now anyway, since stretch came to life officially last year.
I am aware many are still on jessie as it will be maintained till 2020?
Anyway, DNS I assume in Stretch either " /etc/resolvconf/resolv.conf.d " or as it used to be ( thru /etc/network/interfaces ) in Jessie.
-
thanks a lot, this helped a lot.
I managed now by cleaning file " head " as that contained the google DNS entry I was looking for and is the primary entry.
The tool " nmtui " still can be used to add DNS entries, but instead I believe these can be added to " head " so no need to use the text user interface.
thanks again
-
Hi - I flashed a new nanopineo2 with debian9 ( Armbian_5.44.180510_Nanopineo2_Debian_stretch_next_4.14.40 ) and set this to stable build before updating to latest "stable".
Next step after reboot is to configure my static network ( eth0 ), but here things tend to be a bit different than previous flash ?
Previously in advanced I edited /etc/network/interfaces to add my DNS-servers but in this build it seems " Network is managed by NetworkManager " so I instea I used " nmtui " to set these for "Wired Connection 1". Unfortunately I still see in /etc/resolv.conf : " nameserver 8.8.8.8 " first before my entries. I like to get rid of this nameserver but I am unable to find it. Anyone please? TiA!
-
-
Hi - Just checked out latest greatest code from git to compile new stretch image for my NanoPiNeo2 ( Armbian_5.46_Nanopineo2_Debian_stretch_next_4.14.47 ) but seems it won't boot up.
Tried two SDcards and two different boards but same result. Tried both Etscher ( 1.4.4 ) and Rufus ( 3 ) but same result, any issue known that I missed ?
Please note I am building a standard image ( thus no customised settings ) also came to my attention the board becomes quite warm, this is unusual . Thanks
-
4.14.3 incorporated, well done guys ! Donation just sent to support the project: keep up the good work
-
Hi Igor,
In reply to your comment below I like to find out the status today in kernel 4.14.3 , thus if the patches meanwhile are adapted to the new LTS ?
I am just wondering since the kernel page says 4.14.3 is supported? thanks
On 13/11/2017 at 4:21 PM, Igor said:
When those 100+ patches are rebased on top of 4.14 from kernel.org ... few weeks/a month? Get our 4.13.y ... it has far more support (then upstream kernel) for the board you ask. In both cases, kernel remains flagged as testing while for A10 is stable for some time. -
looks like there was a game changer ... 4.14.1 released
Yet it seems also this board is supported by the kernel.
Kernel upgrade is scheduled for the stable images that got built with 4.13.x ?
IMHO 4.14 is the stable kernel now which has the " long term " status
-
Hi - I noticed for some boards kernel 4.14 is available to deploy ( eg Allwinner A10 ) already,
when can this be expected for Allwinner H5 boards ( eg nanopineo2 ) please?
-
For people using Linux Mint, please temporarily update your " /etc/lsb-release " to DISTRIB_CODENAME=xenial and things should roll
-
compiled today " ARMBIAN 5.32 user-built Debian GNU/Linux 8 (jessie) 4.12.0-odroidc2 " and outpur of " openssl speed -elapsed -evp aes-128-cbc " was a bit disappointing as it seems it does not use the hardware encryption. Just built the default, however might check later if module needs to be compiled in ( or modprobed )
root@odroidc2:~# openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 9017781 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 2785443 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 746427 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 189960 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 23811 aes-128-cbc's in 3.00s
OpenSSL 1.0.1t 3 May 2016
built on: Fri Jan 27 00:08:40 2017
options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr)
compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 48094.83k 59422.78k 63695.10k 64839.68k 65019.90kroot@odroidc2:~# openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 10634655 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 2917504 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 753598 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 190469 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 23818 aes-128 cbc's in 3.00s
OpenSSL 1.0.1t 3 May 2016
built on: Fri Jan 27 00:08:40 2017
options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr)
compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 56718.16k 62240.09k 64307.03k 65013.42k 65039.02k
root@odroidc2:~$ lsmod
Module Size Used by
cfg80211 282624 0
rfkill 32768 1 cfg80211
cpufreq_powersave 16384 0
cpufreq_userspace 16384 0
cpufreq_conservative 16384 0
meson_drm 45056 0
drm_kms_helper 172032 1 meson_drm
drm 393216 2 meson_drm,drm_kms_helper
meson_rng 16384 0
meson_gxbb_wdt 16384 0
rng_core 16384 1 meson_rng
fuse 98304 1
ipv6 401408 26
btrfs 962560 0
xor 20480 1 btrfs
zlib_deflate 28672 1 btrfs
raid6_pq 106496 1 btrfs
dwmac_generic 16384 0
realtek 16384 1
dwmac_meson8b 16384 0
stmmac_platform 20480 2 dwmac_generic,dwmac_meson8b
stmmac 110592 3 stmmac_platform,dwmac_generic,dwmac_meson8b
According to my info crypto engine has AES block cipher with 128/192/256 bits keys, standard 16 bytes block size and streaming ECB, CBC and CTR modes.
( Paragraph 3.3 Crypto Engine ). So I upgraded debian jessie to stretch ( which has openssl1.1.0f instead of openssl1.0.1t ) and yet the hardware seems to do some acceleration but still hoped for more ...
openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 8240239 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 2872650 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 802740 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 206766 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 26072 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 13041 aes-128-cbc's in 3.00s
OpenSSL 1.1.0f 25 May 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\""
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 43947.94k 61283.20k 68500.48k 70576.13k 71193.94k 71221.25k
root@odroidc2:/home/ykoot# openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 9273969 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 2507648 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 645224 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 162484 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 20352 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 10176 aes-128 cbc's in 3.00s
OpenSSL 1.1.0f 25 May 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\""
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 49461.17k 53496.49k 55059.11k 55461.21k 55574.53k 55574.53k
-
Hi - I am trying to find out from the fora topics here as well the technical details page if the ODROID-C2 has an extension to the ARMv8 instruction set to improve the speed of applications, like openssl/openvpn, performing encryption and decryption. On the intel platforms this feature is known as AES-NI. Therefore is similar hardware on board and if so, which kernel module enables this feature please?
Also when will " Armbian " stretch be available ( 17 July just like debian 9? ). Cheers
Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party
in Advanced users - Development
Posted
excellent news Igor, done well - highly appreciate all your efforts! ( and of course all others that contributed to this major )