dolphs

cheers for that martinayotte, I was just wondering if this red light has some functional meaning ( eg. undervolt )? If it really has no function except for " powered on " indeed I could disable things this way.

Meanwhile built an image with 4.19 few times, but seems the board does not boot up, is this known at current stage (Armbian_5.77_Orangepioneplus_Debian_stretch_next_4.19.25.img), also seems revision 4.9.31 is available, therefore would it be possible to bump to this kernel please?

hi - thanks for that suggestion, going to try some of these. Finally 1st board arrived and herewith my early ovpn testst ( 15 minutes tcp iperf dump ) running kernel 5.0.2 without heatsink and without fan running at 1,8GHZ: ovpn@orangepioneplus:~# cpufreq-info | grep current current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). These are promising and interesting results, to be honest I am actually somewhat surprised - unless I am monitoring wrong values: ovpn@orangepioneplus:~# paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/' cpu_thermal 53.7°C gpu_thermal 47.8°C Once board is back to idle I am reading results below: dropping 10 degrees initially, which then drops further down to +/- 32C once fully idle. That means when the ondemand governor set CPU frequency back to 480 MHz : 1/ once iperf stopped cpu_thermal 42.4°C gpu_thermal 43.7°C 2/ 5 minutes later cpu_thermal 32.9°C gpu_thermal 34.3°C In two weeks I will be on the other end so I can test two H6 boards ( currently H6 and H5 ) Two things prevent me from switching over, mainly it seems u-boot currently randomize its MAC address, resulting in a different IP once rebooting. Perhaps this is WIP due to the " reboot " issue experienced on H6 boards? Less annoying is I noticed is the crazy bright RED light that pops up and stays on, maybe a 5V3A adapter should be used instead or this has nothing to do with it and therefore the red light can be dimmed/ shut off setting somewhere a 0 ( off )? Ideally I connect it to my USB2.0 port of my fritzbox so I won't need an additional adapter, but as said least worry

still awaiting this board which also has an allwinner H6 chip and comes from same factory. Hope the chips can be cooled down properly for production purposes ( 24/7 ) especially when speed will be increased to 1,8GHz as vendor does not supply a decent cooling solution as far I can see things.

the results are really nice and similar to what Werner posted earlier ( reveal hidden contents ). Once boards are hooked up on the proper locations and can be acceed through a oVPN tunnel I should be able to provide you with some nice " iperf " results sending TCP packages. But I am not sure if I can do that before Easter, depends on my " heatsink " case

Still awaiting my boards to arrive, like to test it with latest 5.x dev kernel by then to see when it throttles sending " iperfs " over the VPN tunnel. Not sure if the governor works on " conservative ' ( instead of ondemand ) that way it increases slowly from lowest frequency ( 888 ? ) to 1,8GHz so I should see an increase of data being sent thru the tunnel once CPU frequency increases. Moreover I like to experiment building a custom kernel ( without driver support for bluetooth, wifi, sound/multimedia etc ) as board will be solely used for VPN purposes ( as well pi-hole ). Still did not decide how to deploy the H6, sure will start without any custom solution and will add the default "Heat Sink" as supplied by Shenzhen Xunlong (though I do not think it is suitable for this Orange Pi One Plus H6 board). So in the end either deploy with case and cooling ( as shown earlier in this thread ) or add 3M 8810 tape with a proper copper heatsink. It is sad there is no clear 1-way-solution provided by vendor and people need to trial-and-error to get this board in to production with proper cooling so it can cope with environments where 40-45 degrees Celcius room temperature is possible in summer. As a side note the dimensions supplied are: CPU: 4*14MM/ H6: 15*15MM/ 1GB LPDDR3: 11.5*10.5MM. Last but not least comparing the H5 to H6 ... My H5 board can run from 120MHz minimum to 1,3GHz tops, although 480MHz is the lowest value it is been using when in idle mode. Can someone tell me pls if there is a noticable increase of power consumption when you compare both boards (neo2-lts vs Opi One Plus)? I would like to know how much this board consumes when in idle mode and also when it is running at max speed. I assume there is 1-2watts difference, but once the boards arrive I can verify using my wattage meter.

hi Werner, again appreciate your quick response :-). Sure I'd like to try with and without a heat sink to see how things go. However note environment board is being used in, can be +/- 45 in summer and past year I learnt on current devices temperatures measured can be easily around 70C. Therefore a decent heatsink in an effort cooling things down is on my wishlist, current temperatures of current devices used list "31" and "34"C BTW. But as mentioned seeking dimensions of the V200-AWIN H6 CPU/GPU chip, as well for the memory chip (1GB LPDDR3) would be nice. I did find a topic here, but that regards the OPi lite2 which should have similar dimensions ( 37*37*24mm ) that apply for the One Plus IMHO (Allwinner H6). If I am unable to cool it properly I am considering the Acrylic Case with Fan Kit attached to this message, but the amount of dB is something that is of utmost importance, if <=15dB I'm ok ;-) ... Anyone tested temperatures ( running 1,8GHz approx one hour ) with this housing and fan? Cheers!

cheers - Last but not least, which heatsink can be used? Although I won't be using it 24/7 on 1,8Ghz ( most of time idle in fact ) I like to add a heatsink. As I noticed a 3M heatsink sticker is sold only with a housing , I like to add a heatsink element to it but should have the measurements of the H6 CPU/GPU chip used, please? TiA!

thanks a lot these are nice figures, so kernel 4.20 does magic after all to this board ( in terms of cpu speed )

> Edit: Oops, I did these tests on the wrong board which still running on kernel 4.17.14. Other board is capable to run at 1.8GHz, so the results should be even better. thanks for your response. If I understand you correctly never revisions of the board can indeed run on 1,8GHz ( overclocking )? In other words if you acquire a board from " Shenzhen Xunlong Software CO.,Limited " now it should be fine. Output looked already promising (1,5GHz), but don't think kernel >=4.20 ( thus also 5.0.x ) will make much difference rgd OpenVPN, AES. As far I can read stuff GPU and HDMI are being enhanced at this stage, or am I wrong?

What about a heat sink for cpu/gpu? Will it happily run without one when all cores will be clocked to 1,8Ghz and running a desktop environment (gpu)?

Hi - can one do a " cpufreq-info " please? Although this board is still in WIP, I was just wondering if it is stable for ovpn ( stretch server/headless ) purposes running kernel >= 4.20 ? Also in terms of speed, can it be " overclocked " similar idea like the H5 (NEO2-LTS v1.1) and last but not least wonder about its speeds, eg: " openssl speed -evp aes-128-cbc " TiA!

moved to this section

hmm what about 1.3.6-4? https://packages.debian.org/sid/proftpd-basic to be added, eg: cat sid.repo deb http://httpredir.debian.org/debian sid main contrib non-free cat upgrade.sh #!/bin/sh cat sid.repo >>/etc/apt/sources.list apt-get update apt-get -t sid install -y proftpd-basic sed -i '$d' /etc/apt/sources.list

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

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

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

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

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 !

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

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!

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

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)

excellent news Igor, done well - highly appreciate all your efforts! ( and of course all others that contributed to this major )

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 )