sfx2000

No doubt... Allwinner is interesting, but the chips are cheap, relatively fast, and the HW community offers a rich diversity of platforms... Did some work on the H3 based Beelink-X2 a couple of years back - was always impressed by that big hunk of steel on the two I picked up in Shenzen - why use aluminum or copper when one has... no wonder they ran warm, but even then, once heat soaked, they were at least consistent. It had a decent amount of RAM and the eMMC - nice TV box...

It's on my to-do list... I'm not holding for much bigger numbers though - as OpenSSL is only one part of the picture... I've found that some crypto blocks can throw big numbers for kb/sec on openssl speed, but one also needs to keep in mind the number of blocks processed - one has to look at the "Doing <cipher> for 3 s on <x size> blocks: number of <cipher> in <time>" - and sometimes the SW implementation is actually more efficient, the crypto block reduces load on the cores - depends on the platform, but HW accel doesn't always provide faster results, although they may be better overall in a task context...

Understood - time and resources... Always appreciate the efforts of the team here across the supported platforms.

working with a guy on the renegade - so at least one person cares... challenge is the upstream at the moment, but it's a decent board, and early work shows it's a good performer -- https://www.phoronix.com/scan.php?page=article&amp;item=libre-computer-renegade&amp;num=1 Libre Computer there is spreading their efforts with the tritium allwinner devices... https://www.phoronix.com/scan.php?page=article&amp;item=libre-computer-tritium&amp;num=1

I'd suggest keep the rk-armv7a's as one... both the little and big cores - the intrinsics are well understood, and most are mainline these days... Upcoming stuff - the 3328 and 3399 are all armv8, and 3399 is big.LITTLE, so there's a fair amount of concern there - but the little cores generally need to match big cores there for features... Should be impressive performers across the board....

Kind of... rk_crypto as a kernel module is built and loaded... Doesn't mean it's all that fast, just saying, but one also has to look at the API's exposed - cryptodev or af_alg for OpenSSL userland - not seeing this at present with the stock packages - yes, there are patches avail for OpenSSL, and most folks on distro's decline to patch it for obvious reasons... one does not play dice with security. Just wandering into this thread as part of a discussion somewhere else about crypto accel on the rockchips - if one looks at openssl as delivered on armbian, the only engine that is avail is "dynamic" - so it's all core there. In any event - max expected potential OVPN thruput on the rk3288-tinker is right around 160 Mb/Sec running on cores as it stands.. it's not low, it's actually pretty good. 3200/time = throughput in Mb/Sec sfx@tinker:~$ openvpn --genkey --secret /tmp/secret sfx@tinker:~$ time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc Fri Sep 21 16:19:38 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode Real 0m19.924s user 0m19.858s sys 0m0.062s sfx@tinker:~$ openssl engine (dynamic) Dynamic engine loading support

Agree - that we can that we're both concerned about the memory manager in general - and the zram.sh script is something that's been tuned for quite some time and experience across multiple archs/distros... I'm more for not aggressively swapping out - the range is Zero to 100 - looking at the rk3288-tinker image, it's set to 100, which is very aggressive at swapping pages... keep in mind that the default is usually 60 My thought is that lower values are better in most cases - the value of 10 is reasonable for most - keeps pressure of the swap partitions which is important if not running zram, as going to swap on SD/eMMC is going to be a real hit on performance, and even with zram, we only want to swap if we really need to as hitting the zram is going to have a cost in overall performance.

@Igor @tkaiser beat me to the punch on the initramfs 'glitch'... but it's an easy fix edit (if the file isn't there, create it) /etc/initramfs-tools/conf.d/resume add/modify the line there - can do none, or push it to another location other than zram RESUME=none then refresh the initramfs update-initramfs -u -k all

Hi folks... Looking at RK3288 on Armbian and the power/thermals - which are considerable considering SBC's like tinkerboard and miqi Currently - looks like all cores are following the same power/time domain - so one core goes fast, and the others follow, so sucks power and raises temps, and we get heat soaked quickly... Looking at the Rockchip docs, it does look like the RK3288 does have PD's for each core along with other logic... Six separate power domains for every core to support internal power switch and externally turn on/off based on different application scenario * PD_A17_0: 1st Cortex-A17 + Neon + FPU + L1 I/D Cache * PD_A17_1: 2nd Cortex-A17 + Neon + FPU + L1 I/D Cache * PD_A17_2: 3rd Cortex-A17 + Neon + FPU + L1 I/D Cache * PD_A17_3: 4th Cortex-A17 + Neon + FPU + L1 I/D Cache * PD_SCU: SCU + L2 Cache controller, and including PD_A17_0, PD_A17_1, PD_A17_2, PD_A17_3, debug logic One isolated voltage domain to support DVFS Is this valid - and this might be helpful... or is this a dependency on upstream and not implemented. thx!

oh hai! noob here - but zram is interesting... zram-config is always good, as it kinda sorts things, but looking at distro's where that's not available as a package simple short shell script (cribbed this somewhere else, forget where)... Anyways - just needs to ensure that zram is enabled in the kernel config. zram.sh - put this over in /usr/bin/zram.sh and make it executable...then add it to /etc/rc.local - add to /etc/sysctl.conf the vm.swappiness = 10 to keep pressure off unless it's needed memory manager sorts things out here, and this is a good item for small mem devices,