tkaiser Posted October 18, 2017 Posted October 18, 2017 2 hours ago, malvcr said: the MT7623 has 1 Gbps crypto engine for VPN, or 500 Mbps crypto engine suite (in case these are different things) You should keep in mind that you're playing early adopter. MTK's first 'open source' MT7623 device is this BPi R2 so I would assume you need a lot of patience until such 'special' stuff is properly supported especially given that such basic stuff like cpufreq scaling still isn't working.
malvcr Posted October 18, 2017 Posted October 18, 2017 You are right ... priorities. In fact, I would prefer to have the cpufreq type of things ready than the 'special' stuff. So ... today. 1) It is not possible to have high throughput on sequential cryptography networking involving only the CPU. 2) Plain networking (no linear CPU processing involved) is OK. 3) It is not possible to play with the CPU frequency. 4) Disk it is not tuned, and has the PCIe-line bandwidth limitation. USB3 speed it is not good at all. Then ... por specialized programming "today" 1) To increase "protected" networking speed, some sort of multithreading/multiprocessing must be used (at least there are 4 cores), or playing around with the cryptography algorithms to let the CPU to breath. 2) JIT processing it is not a good idea when dealing with lots of data. Better prepare what you can in advance when the CPU it is idle. 3) As the machine hast 2 GB RAM, it is important to use that 'asset' to reduce I/O latency. 4) Don't use USB for disks. Keep SATA and, "maybe", an extra adapter in the PCIe slot.
tkaiser Posted October 18, 2017 Posted October 18, 2017 4 minutes ago, malvcr said: 1) It is not possible to have high throughput on sequential cryptography networking involving only the CPU. No idea if that's really true since the SoC is said to support proprietary MTK crypto extensions. So once MTK demonstrates how to use this stuff (in a reasonable way, you want this functionality available in a way that later kernel updates don't break everything) you could ask them for the output of for i in 128 192 256; do openssl speed -elapsed -evp aes-${i}-cbc ; done Also I don't agree on the conclusions wrt disk/USB performance since you can test for this stuff only with great performing devices (SSDs that are known to exceed 500 MB/s in every situation eg. Samsung Pro 850 with at least 256 GB -- the 128GB variant has lower write performance). Anyway: it was such a sh*t show getting any information about R2 since the 'sinovoip team bpi' guy actively blocked everything, it seems this still continues and playing early adopter is always just a great recipe to waste your own time... feel free to continue here but please don't expect further feedback
malvcr Posted October 18, 2017 Posted October 18, 2017 I will give a try to what Gary Wang described here (http://forum.banana-pi.org/t/is-it-possible-to-have-the-crypto-extensions-working/4034). ... could be possible that thing is ready? In case I have good news I will share them :-)
zador.blood.stained Posted October 18, 2017 Posted October 18, 2017 4 minutes ago, malvcr said: could be possible that thing is ready? cryptodev is just a "bridge" between kernel and userspace (and it needs recompiling OpenSSL with cryptodev support to be of any use, AF_ALG is a better alternative AFAIK). To check if hardware crypto is supported you need to check the device tree, kernel config and possibly /proc/crypto
tkaiser Posted October 18, 2017 Posted October 18, 2017 34 minutes ago, malvcr said: could be possible that thing is ready? Ask Gary? Two questions (for him): How does openssl performance look like using the standard benchmark above? How do they want to move from PoC to productive? Seems the current MTK vendor kernel does not receive frequent updates (still at 4.4.70), how should users cope with cryptodev if they need to compile the stuff themselves and out-of-tree and will BPi then provide rebuilt openssl packages to make use of the engine?
malvcr Posted October 19, 2017 Posted October 19, 2017 I am writing to Gary ... but in the while, I built everything and the crypto driver really works. These are the numbers: Without the driver (standard openssl): for i in 128 192 256; do openssl speed -elapsed -evp aes-${i}-cbc ; done You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 4140500 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 1196387 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 312026 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 78846 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 9886 aes-128-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 22082.67k 25522.92k 26626.22k 26912.77k 26995.37k You have chosen to measure elapsed time instead of user CPU time. Doing aes-192-cbc for 3s on 16 size blocks: 3626398 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 1028081 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: ^[[A266479 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 67186 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 8426 aes-192-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-192-cbc 19340.79k 21932.39k 22739.54k 22932.82k 23008.60k You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 3258679 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 910552 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 235055 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 59249 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 7422 aes-256-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 17379.62k 19425.11k 20058.03k 20223.66k 20267.01k With the driver ( to do this I had to compile kernel, cryptodrv and openssl ... with some quirks here and there ): for i in 128 192 256; do ./openssl speed -elapsed -evp aes-${i}-cbc ; done You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 97341 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 83631 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 74013 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 73826 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 45441 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 16384 size blocks: 31972 aes-128-cbc's in 3.00s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -march=armv7-a -Wa,--noexecstack 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 519.15k 1784.13k 6315.78k 25199.27k 124499.22k 174609.75k You have chosen to measure elapsed time instead of user CPU time. Doing aes-192-cbc for 3s on 16 size blocks: 96073 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 84094 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 74714 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 74362 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 43467 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 16384 size blocks: 29992 aes-192-cbc's in 3.00s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -march=armv7-a -Wa,--noexecstack The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-192-cbc 512.39k 1794.01k 6375.59k 25382.23k 118693.89k 163796.31k You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 95306 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 84143 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 74296 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 73367 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 41361 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 28101 aes-256-cbc's in 3.00s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -march=armv7-a -Wa,--noexecstack The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 508.30k 1795.05k 6339.93k 25042.60k 112943.10k 153468.93k So ... with the R2 I "must" use the hardware help. I will check AF_ALG ... but today hours were not enough ;-)
malvcr Posted October 19, 2017 Posted October 19, 2017 Detail .... that hardware engine seems to work better with more than 1024 bytes. Something to take into consideration (although I need to check openssl compiling parameters with more care).
tkaiser Posted October 19, 2017 Posted October 19, 2017 4 hours ago, malvcr said: that hardware engine seems to work better with more than 1024 bytes Well, obviously the overhead trashes performance with small chunks. When comparing the numbers with another Cortex-A7 then it's again an indication that the MTK SoC is clocked with just 1040 MHz (I would assume it's 1042). I added the numbers to our list: https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829
malvcr Posted October 19, 2017 Posted October 19, 2017 I checked interrupts, by Rider.Lee in BPI forum recommendation ... and when using the extensions there is a big quantity of them ( openssl speed -evp aes-128-cbc ). First run (with cryptodev) Total change for mtk-aes: 394682 Total change CPU : 2260 + 14616 + 14895 + 22625 = 54396 Second run (without cryptodev) Total change for mtk-aes: 0 Total change CPU : 1710 + 4332 + 4860 + 4357 = 15259 Right now I repeated the test checking the CPU. In the first case the CPU arrived at most to 50% - with cryptodev In the second case went to 100% (one core) - without cryptodev Would be interesting to go directly to the kernel interface. I don't know if openssl or even cryptodev way to do things could be wasting some CPU. My next test would be to replace the basic infrastructure to see how is the behavior with sftp. Previously I only was able to obtain 14 MB/s but this was limited by the CPU.
zador.blood.stained Posted October 19, 2017 Posted October 19, 2017 2 hours ago, malvcr said: My next test would be to replace the basic infrastructure to see how is the behavior with sftp. Previously I only was able to obtain 14 MB/s but this was limited by the CPU. For this you may need to recompile some stuff. Even in Debian Stretch openssh-server still is compiled against OpenSSL 1.0.x, and hardware acceleration (lke cryptodev or AF_ALG) AFAIK requires OpenSSL 1.1 or newer. Not sure if you will need any special configuration to make libssl use HW crypto with different applications by default.
malvcr Posted October 19, 2017 Posted October 19, 2017 Not so easy to do ... Latest ssh version (cloned with git from official site): checking OpenSSL library version... configure: error: OpenSSL >= 1.1.0 is not yet supported (have "10101000 (OpenSSL 1.1.1-dev xx XXX xxxx)"). And, of course, when I replace the OpenSSL many things are broken. I will need to figure a different approach. There is a Fedora patch for 1.0, but I think that to make that to work involves more work than to do something from scratch (and will be over when openssh be updated to openssl 1.1.0).
zador.blood.stained Posted October 19, 2017 Posted October 19, 2017 12 minutes ago, malvcr said: I will need to figure a different approach. Maybe find a different/3rd party SFTP server that supports newer OpenSSL? Something like vsftpd or ProFTPd
malvcr Posted October 19, 2017 Posted October 19, 2017 I have been thinking in some combination as OpenVPN (recompiled for cryptodev) with rsync or a type of simple plain data transmission. What I don't know is how will be the overhead ... if it is very high then I will need to process big chunks of data by myself. But, in general, it is a good thing to test :-)
malvcr Posted October 20, 2017 Posted October 20, 2017 Making some tests ... rsync uses ssh or rsh (that for some reason it is worse) ... openssl with cryptodev it is fast on big files. There is no rcp (was replaced by scp that is part of ssh set). Then ssh it is in many important places in a regular distribution. I still must make more precise tests, but sending a file with ssh was around 3 minutes ... but encrypting it with openssl (aes - 256) took around 37 seconds and transmitting it with a simple perl script around 12 seconds. I know I can do better by saving one disk reading in the processing phase by moving to C or C++. But this shows that it is possible to obtain more from this machine without using the "normal" options.
Lion Wang Posted October 21, 2017 Posted October 21, 2017 I've test the AP mode, find it works fine, please follow my steps to enable it. Firstly please install Ubuntu 16.04 image, and then: 1,Remove pkg wpasupplicant(apt-get remove wpa_supplicant) if you're using Ubuntu 16.04 image 2,Comment out echo 1 > ${{WIFI_DEV} in /etc/init.d/wifi_enable if you're using Ubuntu 16.04 image 3,Reboot 4,Run command "echo A >/dev/wmtWifi" 5,Run comand : hostapd -dd -C /etc/hostapd/hostapd.conf Below is an example of hostapd.conf: hw_mode=g interface=ap0 driver=nl80211 channel=1 auth_algs=1 ssid=test Also the patch @BitMaster provided is delivered to github. Thanks a lot, BitMaster. https://github.com/BPI-SINOVOIP/BPI-R2-bsp/commit/219be3221aadb2d316557df8064bb231ca46ed51
zador.blood.stained Posted October 21, 2017 Posted October 21, 2017 I don't remember anyone linking the mainline DT for this board, so here we go: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f4ff257cd1607ef79f6647a633d6cc495529cbff It's interesting to see a CPU operating points table there (so DVFS should work already), looks like Ethernet (with DSA), USB and basic peripheral interfaces (I2C, CIR, I2S, PWM, GPIO, ...) should be supported too, but don't see anything that would represent SATA or PCIe yet. 1
malvcr Posted October 22, 2017 Posted October 22, 2017 It is good to know that the R2 it is being taken seriously. This machine has important things and, although there are very good alternatives, it has a market place. I have been sending maybe 100 times by now an 825 megabytes ubuntu iso file from one R2 to another and between an R2 and a Mac Mini machine, testing different types of configurations (in the while I am creating the system I will use the R2 for). Here there have some numbers that could be useful: (AES 256 bit): without /dev/crypto 100% CPU max - real 0m53.189s - user 0m44.210s - sys 0m8.030s with /dev/crypto 75% CPU max - real 0m27.015s - user 0m2.290s - sys 0m17.750s Checking at this test alone, it is clear that with the cryptodev driver active (and with the right openssl compiled for it), the machine it is faster processing. And then it is the top 100% capacity when using only the CPU ... I was trying to figure how to test that remaining 25% ... so, I made a multithread program that received the data (running in a R2), and executed 4 parallel sets of openssl+sending data from the other R2. The "general "throughput" for all the "bundle" gives around 45.8 MB/s. This is much higher than the around 17 MB/s I can have with only one similar session. The issue here is that the final speed can't be calculated only taking into consideration the crypto engine. A final test would need software designed for this, because when I cypher with openssl and then send the file on ethernet, I need to "write" the file to disk and to re-read it, and the DISK is a key factor on the overall transmission speed. An extra write is really heavy here. So, if I like to see a wonderful speed without sacrificing the machine, the disk must speed up. The final numbers for secure transmission of data must involve all the key factors : CRYPTO+DISK+NET+CPU. But ... in general, I think it is good enough for my purposes. When I have a better software platform to test all together (without punishing any of the factors), I will come to show my numbers. 1
Ryder.Lee Posted October 23, 2017 Posted October 23, 2017 On 10/21/2017 at 8:48 PM, zador.blood.stained said: I don't remember anyone linking the mainline DT for this board, so here we go: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f4ff257cd1607ef79f6647a633d6cc495529cbff It's interesting to see a CPU operating points table there (so DVFS should work already), looks like Ethernet (with DSA), USB and basic peripheral interfaces (I2C, CIR, I2S, PWM, GPIO, ...) should be supported too, but don't see anything that would represent SATA or PCIe yet. PCIe: https://www.spinics.net/lists/arm-kernel/msg613482.html Some display stuff (e.g. HDMI /MIPI DSI) will be supported in v4.15.
Ryder.Lee Posted October 23, 2017 Posted October 23, 2017 10 hours ago, malvcr said: It is good to know that the R2 it is being taken seriously. This machine has important things and, although there are very good alternatives, it has a market place. I have been sending maybe 100 times by now an 825 megabytes ubuntu iso file from one R2 to another and between an R2 and a Mac Mini machine, testing different types of configurations (in the while I am creating the system I will use the R2 for). Here there have some numbers that could be useful: (AES 256 bit): without /dev/crypto 100% CPU max - real 0m53.189s - user 0m44.210s - sys 0m8.030s with /dev/crypto 75% CPU max - real 0m27.015s - user 0m2.290s - sys 0m17.750s Checking at this test alone, it is clear that with the cryptodev driver active (and with the right openssl compiled for it), the machine it is faster processing. And then it is the top 100% capacity when using only the CPU ... I was trying to figure how to test that remaining 25% ... so, I made a multithread program that received the data (running in a R2), and executed 4 parallel sets of openssl+sending data from the other R2. The "general "throughput" for all the "bundle" gives around 45.8 MB/s. This is much higher than the around 17 MB/s I can have with only one similar session. The issue here is that the final speed can't be calculated only taking into consideration the crypto engine. A final test would need software designed for this, because when I cypher with openssl and then send the file on ethernet, I need to "write" the file to disk and to re-read it, and the DISK is a key factor on the overall transmission speed. An extra write is really heavy here. So, if I like to see a wonderful speed without sacrificing the machine, the disk must speed up. The final numbers for secure transmission of data must involve all the key factors : CRYPTO+DISK+NET+CPU. But ... in general, I think it is good enough for my purposes. When I have a better software platform to test all together (without punishing any of the factors), I will come to show my numbers. Try to route AES interrupts to different CPUs (smp affinity).
Lion Wang Posted October 24, 2017 Posted October 24, 2017 Image --------------------------- New test images(kernel and root.squashfs) are available:http://pan.baidu.com/s/1nuXrUTb How to program both uImage and root file system ---------------------------- 1. Copy both uImagelede and root.squashfs to tftp server 2. Run below command to program uImagelede > tftp 84000000 uImagelede > mmc dev 0 > mmc write 84000000 1000 6000 3. Run below command to program root.squashfs to EMMC: > tftp 84000000 root.squashfs > mmc dev 0 > mmc write 84000000 20A00 6000 4. Run command: boot 5. Configure an available IP address and then run below commands when entering OS > opkg update > opkg install luci-theme-bootstrap > opkg install luci-mod-admin-full 6. Connect R2 board via web
tkaiser Posted November 6, 2017 Posted November 6, 2017 Too funny: BPi R2 users buying USB WWAN modems in mPCIe form factor just to realize later that they can't use the cards since SinoVoip 'forgot' to connect pins 36/38 on the mPCIe header (pins 36/38 on mPCIe compliant devices carry the USB2 data lines necessary for all 3G/4G modems in mPCIe format)
tkaiser Posted November 7, 2017 Posted November 7, 2017 8 hours ago, tkaiser said: Too funny: BPi R2 users buying USB WWAN modems in mPCIe form factor just to realize later that they can't use the cards since SinoVoip 'forgot' to connect pins 36/38 on the mPCIe header (pins 36/38 on mPCIe compliant devices carry the USB2 data lines necessary for all 3G/4G modems in mPCIe format) @Lion Wang This is a benchmark. How you as the CEO take it seriously that you hired an absolute idiot providing your 'technical documentation'
tkaiser Posted November 7, 2017 Posted November 7, 2017 As a reference: mPCIe specification. USB2 is part of the interface.
guidol Posted November 7, 2017 Posted November 7, 2017 20 minutes ago, tkaiser said: As a reference: mPCIe specification. USB2 is part of the interface. here V2.0 - but only viewable. not downloadable without accounthttps://de.scribd.com/document/237650383/PCI-Express-Mini-CEM-2-0-pdf But the Pinout is already in the Wikipedia: ( pins 36/38 on mPCIe compliant devices carry the USB2 data lines )https://www.crypt.space/freewiki/?query=mini PCI Express &lang=de
Tido Posted November 7, 2017 Posted November 7, 2017 I hope you wrote that in the http://forum.banana-pi.org/c/news/BPI-product-news as well ? In a nice way of course.
Lion Wang Posted November 28, 2017 Posted November 28, 2017 BPI-R2 new image : ubuntu 16.04 V1.2.1 BT and WIFI AP mode are working fine 2017-11-27 http://forum.banana-pi.org/t/bpi-r2-new-image-ubuntu-16-04-v1-2-1-bt-and-wifi-ap-mode-are-working-fine-2017-11-27/4291
tkaiser Posted July 29, 2018 Posted July 29, 2018 50 minutes ago, malvcr said: Other day I can check with the R2 1.1 version ... is that the machine it is not in working order right now :-) ... also, I will do it without RAID-1 and using a SSD disk instead of regular hard disks Thanks a bunch for the results. No need to re-test since everything fine ('neon' or not seems to make no difference on armhf -- most probably compilation breaks). The benchmark was running all the time at 1300 MHz and this value is true: Cpufreq OPP: 1300 Measured: 1298.347/1297.092/1298.054 Also no need to re-test with different storage since the benchmark does not access the disk (only if swapping would've occured). See the '%io' column: no %iowait so everything fine. The wrong thermal readout is most probably due to my script choosing wrong thermal source (never dealt with a MediaTek SoC/kernel so far). Can you run the following please: find /sys -name "thermal_zone*" | while read ; do echo "${REPLY}: $(cat ${REPLY}/type) $(cat ${REPLY}/temp)" done
malvcr Posted July 29, 2018 Posted July 29, 2018 There is something strange with OpenSSL used with the benchmark and the R2 machine. Last year I made some tests with a rebuilt OpenSSL using cryptodev, and these were the numbers (I must clarify, that this was with an 1.1 R2 version): First, with the "standard" OpenSSL distributed with the base Linux: openssl speed -evp aes-256-cbc type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 17362.04k 19427.14k 20057.77k 20213.76k 20258.82k Here are then numbers with the special OpenSSL version (compiled by me): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 30397.60k 271372.80k 637806.93k 7580876.80k infk 7676723.20k The crypto engine works but not with the standard software. I need to check how you are running OpenSSL and what I can do to it, to see if it is possible to measure the crypto engine in the R2 machine from the benchmark. Right now I am working with ALF_ALG instead of cryptodev for not to deviate from the standard software and to quit me some burdens dealing with cryptographic libraries. It is fast, although I still need to have numbers at hand (a lot of work these days).
malvcr Posted July 29, 2018 Posted July 29, 2018 Results from the thermal script ... /sys/devices/virtual/thermal/thermal_zone0: cpu_thermal 0 /sys/class/thermal/thermal_zone0: cpu_thermal 0 cat: /sys/kernel/debug/tracing/events/thermal/thermal_zone_trip/type: No such file or directory cat: /sys/kernel/debug/tracing/events/thermal/thermal_zone_trip/temp: No such file or directory /sys/kernel/debug/tracing/events/thermal/thermal_zone_trip: mmm ... don't think that what you are looking for is there. There are some already made improvements that I need to check but I am not so sure the temperature control it is one of them. By now, and as I am working in an enclosed case for this "hot" machine, I am using active cooling. But this is for an environment that typically will need it... some day ... this could work and I can improve my setting.
Recommended Posts