wtarreau

  • Content Count

    40
  • Joined

  • Last visited

Reputation Activity

  1. Like
    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!
  2. Like
    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.
  3. Like
    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.
  4. Like
    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.