wtarreau
-
Posts
41 -
Joined
-
Last visited
Reputation Activity
-
wtarreau got a reaction from tkaiser in Random thoughts, opinions and well known facts about PCB and heatsinks
I totally agree, I've been pissed off by many boards on which it was not possible to have correct heat dissipation due to too large the distance between the CPU and the top of the enclosure. With the NEO/NEO2 now you can simply press the PCB (hence the CPU) against a thermal pad touching the enclosure and you're done. It's in fact one of the very rare board capable of spreading the heat outside of the enclosure and not to slowly heat its own environment.
I wish other vendors would realize this as well. And yes, I know it's difficult and expensive to make dual-side BGA designs so that will probably limit the possible candidates here. I would have had a much easier design for my MiQis if the RK3288 had been on the other side!
-
wtarreau got a reaction from tkaiser in Nanopi Neo 2
It's an over-simplification. The die technology and etching resolution matters a lot as well. And my NanoPI-M3 with 8xA53 at 1.4 GHz disagrees with you, just like my Odroid-C2 at 1.536 GHz which stays really cool to the touch at full speed. Some A53 run pretty fine at 2 GHz. You'd better say that A53 is mostly used in cheap devices and that cheap devices don't scale well above 1 GHz due to the cheap technologies involved, that would be more accurate.
-
wtarreau got a reaction from Igor in Armbian on MiQi SBC hardware ?
I've just tested on my MiQi and got about 2% higher performance at 1.8 GHz :
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 80197.72k 87590.12k 91353.34k 92255.91k 92520.45k
bf-cbc 52186.86k 59762.60k 62007.89k 62678.36k 62876.33k
At 2.0 GHz I get this :
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 88145.11k 97268.91k 101094.74k 102091.43k 102386.35k
bf-cbc 57751.12k 66213.18k 68619.26k 69361.66k 69580.12k
My openssl is build in thumb mode with the following options under linaro gcc-4.7.4 :
armv7thf-gcc47l_glibc218-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=cortex-a9 -mlittle-endian -O3 -fomit-frame-pointer -march=armv7-a -D__ARM_MAX_ARCH__=7 -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
Given that most AES code is written in asm, this 2% performance gain likely comes from the rest of the code and could be caused by the mcpu=cortex-a9 build options, I'm forcing it everywhere as I found it to perform better on the RK3288 than mcpu=cortex-a17 on most programs. I suspect that the A17 core in the RK3288 is more of an A12 (as reported in cpuinfo) hence closer to A9 than what the A17 was supposed to be before ARM decided that both were the same.
-
wtarreau got a reaction from tkaiser in Armbian on MiQi SBC hardware ?
I've just tested on my MiQi and got about 2% higher performance at 1.8 GHz :
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 80197.72k 87590.12k 91353.34k 92255.91k 92520.45k
bf-cbc 52186.86k 59762.60k 62007.89k 62678.36k 62876.33k
At 2.0 GHz I get this :
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 88145.11k 97268.91k 101094.74k 102091.43k 102386.35k
bf-cbc 57751.12k 66213.18k 68619.26k 69361.66k 69580.12k
My openssl is build in thumb mode with the following options under linaro gcc-4.7.4 :
armv7thf-gcc47l_glibc218-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=cortex-a9 -mlittle-endian -O3 -fomit-frame-pointer -march=armv7-a -D__ARM_MAX_ARCH__=7 -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
Given that most AES code is written in asm, this 2% performance gain likely comes from the rest of the code and could be caused by the mcpu=cortex-a9 build options, I'm forcing it everywhere as I found it to perform better on the RK3288 than mcpu=cortex-a17 on most programs. I suspect that the A17 core in the RK3288 is more of an A12 (as reported in cpuinfo) hence closer to A9 than what the A17 was supposed to be before ARM decided that both were the same.