dolphs

Members
  • Content Count

    31
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by dolphs

  1. dolphs

    RockPi 4b 'board bring up'

    Hi - I would be happy to test Rockpi4A with accompanying heatsink, but it seems a bit expensive to order in EU ( EUR48,29 ) instead China (USD39) - once I received these items I like to contribute testing its stability at 2.0GHz. Anyway the heatsink looks decent to me and since it does not have to run 24/7 at 2.0GHz I am confident it can be "overclocked" to 2.0GHz for shorter periods, but I like to test that out for my use case ( ovpn with pi-hole ) . Applied similar tweaks recently overlocking the nano pi neo2 lts (v1.1), updating armbianEnv.txt and cpufrequtils . The key to this is temperature, based on current findings neo2 board runs for little while ( 10-15 minutes ) on 1.3Ghz which makes roughly a 10 degrees CPU increase within 6 minutes, but once it throttles back temp drops rapidly ( of course ) and as said I am condifent similar could be achieved with the Rockpi4...
  2. dolphs

    RockPi 4b 'board bring up'

    thanks very much - this makes me confident model A should be able to handle 2.02 as well although stated differently at their page " Dual Cortex-72, frequency 1.8GHz ", cheers
  3. dolphs

    RockPi 4b 'board bring up'

    Can someone show me the output of "cpufreq-info" please, wonder if model B ( and A ) have 1,8GHz freq limit or 2GHz like NEO4. thanks
  4. dolphs

    NanoPi NEO4

    bypassing ovpn tells me theoretically I should be able to reach +/- 240Mbit upload BTW as earlier I accused RCSRDS of setting a 100Mbit cap... " ~# iperf3 -4 -V -c DNS-entry -t 60 -b 0 -P 1 " <snip snip> - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 1.71 GBytes 245 Mbits/sec 87842 sender [ 4] 0.00-60.00 sec 1.70 GBytes 243 Mbits/sec receiver CPU Utilization: local/sender 2.8% (0.1%u/2.7%s), remote/receiver 15.4% (1.1%u/14.4%s) Although at a colleague board I found some more interesting details, however I'd be very interested if someone with at least 300Mbit upload/download can share these iperf results using ovpn 2.4.6 ( server/client ) on two NEO4 ( RK3399 ) please as with NEO2 LTS (1300) I was able to reach roughly 160Mbit on average, tops 200Mbit. thanks
  5. dolphs

    NanoPi NEO4

    The NanoPI NEO4 ( Rockchip 3399 ) might be an interesting upgrade after all as I was convinced there was a 100Mbit upload cap but "overclocking" the NanoPi NEO2-LTS gave me tops 200Mbit, 160Mbit average. Yet pity NEO4 comes with WLAN and BT, perhaps friendlyelec can release a "lite" version without these components as there is an alternative available, called "Rock Pi 4 Model A", just the size is a bit bigger: 85*54mm instead of 60*45mm ( neo4 ) thanks all will closely follow this !
  6. dolphs

    Nanopi NEO2 CPU frequency issue

    thanks a lot, it is highly appreciated: new values ( overclocked ) show: <snip snip> current policy: frequency should be within 408 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.30 GHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.38%, 240 MHz:0.19%, 480 MHz:59.06%, 648 MHz:0.41%, 816 MHz:0.06%, 960 MHz:0.05%, 1.01 GHz:0.07%, 1.06 GHz:0.05%, 1.10 GHz:0.07%, 1.15 GHz:0.24%, 1.20 GHz:0.04%, 1.22 GHz:0.03%, 1.25 GHz:0.01%, 1.30 GHz:39.35% (128) first board results :~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 15572277 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 12847235 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6787237 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 1024 size blocks: 2456283 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 353175 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 178446 aes-128-cbc's in 3.00s OpenSSL 1.1.1-pre9 (beta) 21 Aug 2018 built on: Tue Aug 21 19:00:17 2018 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-Z0GDqL/openssl-1.1.1~~pre9=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 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 83052.14k 274074.35k 581114.61k 838411.26k 964403.20k 974553.09k 2nd board ( of course similar results ): :~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 16151752 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 13172479 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6906353 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2458131 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 353291 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 178478 aes-128-cbc's in 3.00s OpenSSL 1.1.0j 20 Nov 2018 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 86430.78k 281012.89k 589342.12k 839042.05k 964719.96k 974727.85k
  7. dolphs

    NanoPi NEO4

    thanks a lot - it indeed shows the NEO4 ( RK3399 ) is about double ( 2Ghz ) of what I can squish out of the NEO2 currently (1). Which reminds me of the cpu discussion back then. In fact I owe two NEO2 LTS boards and these should be able to handle 1.3 ( instead of 1 ), hence v1.1. Both boards run currently as ovpn server/client on stable debian9, meaning kernel 4.19 ( armbian 5.73 ). Perhaps in referred topic you can guide me thru this on a running system as updating just "/boot/armbianEnv.txt " and MAX_SPEED=1300000 in /etc/default/cpufrequtils," is not sufficient at least I set it to: verbosity=1 console=both overlay_prefix=sun50i-h5 overlays=cpu-clock-1.3GHz gpio-regulator-1.3v usbhost1 usbhost2 rootdev=UUID=5455aad0-a830-48da-b4ba-18795372ece0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u thanks again!
  8. dolphs

    NanoPi NEO4

    Hello, Can someone show results of "cpufreq-info" ( both on kernel 4.4 ( stable ) and 4.20 ( dev )) just to determine how things look like, please? ... My NEO2's show 1.01GHz ( kernel 4.19 ) while the "new" NEO4 should be able to get to 1.8 if I am not mistaken. Therefore in near future might replace this NEO4 with my current NEO2 boards , mainly used for oVPN and Pi-hole. At this time I get +/- 100Mbit speeds over my VPN tunnel - which for my streaming needs is sufficient - but I am always interested to see if things can be improved. Also it appears the 100Mbit limit is set by my ISP (RCSRDS), lucky me, considering " asemenea viteaza de upload international s-a marit la 100Mbps. ". Yet quoting from a site " There’s a significant single-core performance boost (+73%), and lower multi-core delta (+30%) as expected since RK3399 has 2 fast Cortex A72 cores, 4 low power Cortex-A53 cores, against 4 fast Cortex-A17 cores for RK3288. If you look into the details AES is over 10 times faster on RK3399, so there must be some special instructions used here, or AES hardware acceleration. " Can one show me some results using ovpn 2.4.6 please as for oVPN use this "single core" and "AES" stuff is important and maybe moving to Rockchip RK3399 will be worth it. Perhaps forcing use of the Dual Core Cortex A72 and disable the Quad Core Cortex-A53 [ echo "0" > /sys/devices/system/cpu/cpu[2-5]/online ] would be another tweak to speed things up? Oh, inerested in " grep -m1 -o aes /proc/cpuinfo " as well " openssl speed -evp aes-128-cbc " and last but not least " iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1" #where IP is address neo4 My NEO2 reads": grep -m1 -o aes /proc/cpuinfo aes openssl speed -evp aes-128-cbc 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 53449.87k 172470.12k 364346.54k 527213.91k 606710.44k 613225.81k iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1 Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 734 MBytes 103 Mbits/sec 930 sender [ 4] 0.00-60.00 sec 727 MBytes 102 Mbits/sec receiver CPU Utilization: local/sender 1.6% (0.1%u/1.5%s), remote/receiver 31.5% (2.5%u/29.0%s) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 5] 0.00-60.11 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-60.11 sec 727 MBytes 101 Mbits/sec receiver tuned kernel settings: net.core.default_qdisc = fq net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 87380 16777216 net.ipv4.tcp_congestion_control = bbr net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_timestamps = 0
  9. dolphs

    VPN Server Questions

    Hi thanks sharing this with me. tried with both CBC and GCM ( last results ) and indeed interesting results also with GCM. Any kernel settings changed to get 160Mbit as I seem to get stuck around 110Mbit while in theory I should be able to get 300Mbit ( limit upload ) iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1 - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 795 MBytes 111 Mbits/sec 1190 sender [ 4] 0.00-60.00 sec 787 MBytes 110 Mbits/sec receiver CPU Utilization: local/sender 1.9% (0.1%u/1.7%s), remote/receiver 34.0% (2.6%u/31.4%s) - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 774 MBytes 108 Mbits/sec 2724 sender [ 4] 0.00-60.00 sec 766 MBytes 107 Mbits/sec receiver CPU Utilization: local/sender 1.9% (0.1%u/1.8%s), remote/receiver 30.9% (2.3%u/28.6%s)
  10. excellent news Igor, done well - highly appreciate all your efforts! ( and of course all others that contributed to this major )
  11. 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 )
  12. dolphs

    VPN Server Questions

    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 openvpn and 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 65535 If 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 ...
  13. 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.
  14. 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!
  15. 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
  16. OK meanwhile tried " Armbian_5.44.180510_Nanopineo2_Debian_stretch_next_4.14.40 " which can be dl-ed here and that one boots fine …
  17. 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
  18. dolphs

    Armbian for OrangePi PC2, AllWinner H5

    4.14.3 incorporated, well done guys ! Donation just sent to support the project: keep up the good work
  19. dolphs

    Armbian for OrangePi PC2, AllWinner H5

    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
  20. dolphs

    Armbian for OrangePi PC2, AllWinner H5

    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
  21. dolphs

    Armbian for OrangePi PC2, AllWinner H5

    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?
  22. 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
  23. For people using Linux Mint, please temporarily update your " /etc/lsb-release " to DISTRIB_CODENAME=xenial and things should roll
  24. 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.90k root@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
  25. dolphs

    nanopi neo 2 Running Debian 9

    thanks for clarifying Igor, will RTFM next time better ... Don't worry will try not to bug too much and build from scratch, as long I can use NanoPi NEO2 crypto engine Id be more than happy ;-)