APU1C sur le banc de test

19 août 2014

Avant d'acheter l'APU1C pour remplacer mon Alix 2D13, je me suis demandé quel trafic elle pouvait supporter sans flancher. Ce n'était pas une condition nécessaire à son acquisition, puisqu'elle ferait toujours mieux que l'Alix, mais la curiosité m'a poussé à tester ses limites.

On trouve sans effort de nombreux tests sur internet, cependant la méthodologie utilisée laisse souvent à désirer et la métrique, le megabit par seconde, est difficilement transposable à différents réseaux. Mais surtout aucun jusque là n'a été mené avec OpenBSD comme système cible.

Protocole

Pour avoir une véritable idée des performances d'un routeur, la convention est de mesurer le nombre maximal de paquets transférés par seconde. Cela implique de ne pas lancer le test sur l'APU elle-même (cela biaiserait les résultats), de générer beaucoup de paquets de petite taille, et bien évidemment de pouvoir les compter.

Pour générer et recevoir les paquets, mais surtout les compter, j'ai emprunté du matériel de R&D au travail, deux R210 II avec un chipset réseau Broadcom NetXtreme II (driver bnx2 sous Linux). Malheureusement, l'un d'eux était en cours d'utilisation et j'ai dû le remplacer par mon ordinateur portable avec un chipset Intel 82579LM (driver e1000e sous Linux). Avant de solliciter l'APU, j'ai donc mesuré combien de paquets par seconde mon ordinateur portable (sur secteur afin que les options d'économie d'énergie n'interfèrent pas) pouvait générer : environ 320 000. On est loin des 1.488Mpps d'un lien Gigabit line-rate avec la plus petite taille de paquet possible, mais cela n'empêche pas de continuer le test, car la capacité de transfert de l'APU sera probablement inférieure.

Voici le schéma du montage de test :

                                                                                
                              +-------------------------------+                           
                              |              APU              |                           
                              |      [re1]         [re2]|     |                      
                              |192.168.13.1/24  172.16.13.1/24|         
                              +-------------------------------+                           
                                       |             | 
                                       |             |                            
                   [Portable]----------+             +----------[R210 II]                
                192.168.13.10/24                             172.16.13.10/24

Il reste encore quelques routes à ajouter pour que les paquets soient dirigés vers la bonne interface de chaque machine.

Sur l'ordinateur portable :

# route add -net 172.16.13.0/16 gw 192.168.13.1

Sur le R210 II :

# route add -net 192.168.13.0/16 gw 172.16.13.1

Sur l'APU :

# route add -inet 192.168.0.0/16 192.168.13.10
# route add -inet 172.16.0.0/16 172.16.13.1

Le générateur de paquets sur l'ordinateur portable va servir à envoyer le maximum de datagrammes UDP possible sans données utiles (afin d'avoir les plus petits paquets) à destination d'adresses aléatoires du réseau 172.16.14.0/24 :

# timeout 30 hping3 -I eth0 --flood -2 --rand-dest 172.16.14.xx

Les paquets transférés par l'APU sont relevés sur le R210 II en lisant directement les compteurs du noyau :

# cat /sys/class/net/eth0/statistics/rx_packets
6733506
# cat /sys/class/net/eth0/statistics/rx_packets
11912856

En comparant le nombre de paquets reçus avant et après chaque test, on peut facilement calculer la vitesse de transfert moyenne de l'APU :

(11912856 - 6733506)/30

RĂ©sultats

Après plusieurs tests de 10, 30 et 60 secondes chacun, et en ayant redémarré l'APU plusieurs fois, le taux de transfert moyen avec Packet Filter désactivé est de 172kpps avec le noyau MP et de 184kpps avec le SP. La bonne surprise c'est que ce résultat est légèrement supérieur à celui obtenu avec FreeBSD (154kpps) habituellement réputé pour être plus performant. Cela aurait pu s'expliquer par un meilleur driver "re" sous OpenBSD, mais il semble justement qu'il soit un port de celui utilisé par FreeBSD.

Compte tenu de la puissance du CPU (AMD T40E) et de la consommation annoncée, ce résultat est très correct. Bien sûr avec un trafic composé uniquement de paquets de petite taille il ne sera pas possible d'atteindre plus de quelques centaines de megabits par seconde, mais en usage domestique ou bien pour un petit bureau, cela devrait suffire. À titre d'exemple, le trafic typique à mon domicile est distribué ainsi :

  • 36% de paquets infĂ©rieurs Ă  80 octets
  • 3% de paquets compris entre 80 et 160 octets
  • 56% de paquets supĂ©rieurs Ă  1280 octets
  • Et les 5% restants pour les autres tailles

Avec une telle répartition, 1Gbps représente à peu près 165kpps, un peu moins que le maximum supporté par la carte. Mais il reste encore à étudier l'impact de Packet Filter qui n'est pas négligeable.

Référence(s)