Olivier Wenger

Swisseurobot et Eurobot 2010

Lollipop dans toute sa splendeur

Je profite d’un peu de temps (sic) libre dû à la météo pour tenter de rattraper le retard.

La coupe Swisseurobot puis Eurobot a eu lieu du 27 au 30 mai 2010 à Rapperswil-Jona (SG, Suisse) et j’y étais avec le CVRA et notre robot Lollipop (que nous aurions en réalité dû appeler Pac-Man (ça semble logique lorsqu’on le voit en action)).

Notre robot

Assemblage 3D

Lollipop est pour nous un robot de transition, nous avons en effet abandonné nos classiques pour utiliser de nouvelles techniques et technologies, tout reprendre à zéro. Cela représente un gros challenge, surtout si l’on ajoute à la recette un réglement qui change sans cesse. Ces modifications ont d’ailleurs dû décourage nombre d’équipes puisqu’au final seules 8 équipes Suisse ont passés l’homologation… Le défi a finalement été relevé avec brio pour finir avec un des robots les plus compétitifs aussi bien par rapport aux équipes Suisse (record Suisse du score d’ailleurs) qu’Européennes. Malheureusement comme nous utilisions de nouvelles technologiques et accumulé du retard dans le développement à cause du réglement nous avions peu de temps pour combler aux bugs inhérent au nouveau langage du robot (URBI de Gostai) ce qui nous a fait échouer quelques matchs et surtout le quart de final ce qui est évidemment éliminatoire.

Résultats Swisseurobot 2010

Quelques nouveautés 2010 :

• Ordinateur embarqué sur Linux avec URBI pour la gestion du robot
• Nouvelle carte moteur 3 axes
• Amélioration du soft de nos balises laser (bonne précision de la position du robot, de celle de l’adversaire mais notre position était extrêmement fiable grâce à notre odométrie)
• Utilisation de pièces imprimées en 3D
• Etc…

Voici quelques vidéos :

http://www.youtube.com/view_play_list?p=84D8A43875C42643

La vidéo de présentation du robot

L’adresse du club CVRA : http://www.cvra.ch

Benchmark ou comment tester un serveur

Il m’arrive régulièrement de devoir tester un serveur pour connaitre ses capacités, évaluer l’utilisation possible, etc… il existe plusieurs méthodes. Je vais en décrire quelques-unes simple à mettre en place.

Je traite ici d’un serveur sous Debian.

Voici quelques critères :

• Mesurer les performances CPU
• Tester la mémoire ram
• Débit et latence au disque dur
• Tester la connexion réseau (débit et latence)
• Stabilité du système (test sur plusieurs heures ou jours)

Monitoring

La première étape est de pouvoir superviser les tests et avoir un aperçu aussi bien en temps réel que dans le temps. Pour cela il y a plusieurs outils de monitoring :

En console

top : Le classique top est toujours pratique pour superviser l’état général du serveur en temps réel et contrôler que les tests en cours.

top - 17:47:54 up  2:15,  3 users,  load average: 0.18, 0.17, 0.09
Tasks: 194 total,   2 running, 192 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.1%us,  2.0%sy,  0.2%ni, 95.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3095720k total,  1045784k used,  2049936k free,    62580k buffers
Swap:   907632k total,        0k used,   907632k free,   440860k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1413 root      20   0  202m  64m  13m S    3  2.1   7:35.45 Xorg

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  1   0  86  13   0   0| 148k  346k|   0     0 | 326B  706B|  25    42
  2   0   0  98   0   0|1867k   27k| 108B  232B|  12k    0 |  56    66
  2   0   0  97   0   0| 630k   46k|   0     0 |   0     0 |  42    47
  2   0   0  98   0   0|1074k   43k|   0     0 |   0     0 |  46    50

slurm : Un petit outil pour surveiller les interfaces réseaux.

      Active Interface: eth0                    Interface Speed: unknown

      Current RX Speed: 20464.52 KB/s          Current TX Speed: 448.83 KB/s
    Graph Top RX Speed: 20464.52 KB/s        Graph Top TX Speed: 648.21 KB/s
  Overall Top RX Speed: 20464.52 KB/s      Overall Top TX Speed: 648.21 KB/s
      Received Packets: 495542060           Transmitted Packets: 723671597
       GBytes Received: 139.571 GB           GBytes Transmitted: 821.331 GB
   Errors on Receiving: 0                Errors on Transmission: 0

Graphiques via HTTP :

Pour superviser les tests au fil du temps il est utile sinon indispensable d’avoir recours aux graphiques dans le style RDDTools. Il y a évidemment le classique mrtg mais j’ai une préférence pour munin qui est beaucoup plus puissant, précis sans être beaucoup plus lourd.

Graphique mémoire de Munin

Connexion réseau

Il importe ici de connaitre la connectivité du serveur à internet ainsi que la qualité du réseau (temps de latence, paquet perdu,.. ).

Débit

Pour connaitre le débit de la connexion internet en download vous pouvez télécharger un gros fichier :

wget http://test-debit.free.fr/image.iso
--2010-01-24 17:56:02--  http://test-debit.free.fr/image.iso
Résolution de test-debit.free.fr... 212.27.60.49
Connexion vers test-debit.free.fr|212.27.60.49|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 678526976 (647M) [application/x-iso9660-image]
Saving to: `image.iso'

100%[======================================>] 678 526 976 11,2M/s   in 58s     

2010-01-24 17:57:00 (11,1 MB/s) - « image.iso » sauvegardé [678526976/678526976]

N’oubliez pas de supprimer l’image téléchargée afin de ne pas trop encombrer votre espace disque. Ensuite il ne faut pas oublier que ce test de débit est fait principalement pour tester les connexions ADSL > 20 mbps, hors il n’est pas rare de disposer d’une connexion de 100 mbps voir 1 gbps. Il faudra donc trouver quelque chose de plus costaud et effectuer plusieurs tests en parallèle.

En upload il suffit de récupérer ce fichier en ftp depuis un autre serveur par exemple.

Latence et réseau

Pour connaitre la qualité du réseau, les outils classiques comme ping ou encore traceroute sont là.

Performances des disques durs

Vous pouvez vérifier le débit avec hdparm :

hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   9790 MB in  2.00 seconds = 4900.65 MB/sec
 Timing buffered disk reads:  702 MB in  3.01 seconds = 233.54 MB/sec

Pour des données plus précises il y a tiobench :

No size specified, using 512 MB

Unit information
================
File size = megabytes
Blk Size  = bytes
Rate      = megabytes per second
CPU%      = percentage of CPU used during the test
Latency   = milliseconds
Lat%      = percent of requests that took longer than X seconds
CPU Eff   = Rate divided by CPU% - throughput per cpu load

Sequential Reads
                              File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier                    Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64     512   4096    1  ###### 99.60%     0.002        0.04   0.00000  0.00000  1662
2.6.32.2-xxxx-grs-ipv6-64     512   4096    2  ###### 396.8%     0.003        0.04   0.00000  0.00000   621
2.6.32.2-xxxx-grs-ipv6-64     512   4096    4  ###### 1599.%     0.006        0.06   0.00000  0.00000   163
2.6.32.2-xxxx-grs-ipv6-64     512   4096    8  ###### 6369.%     0.020        0.13   0.00000  0.00000    24

Random Reads
                              File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier                    Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64     512   4096    1  ###### 126.1%     0.002        0.01   0.00000  0.00000  1302
2.6.32.2-xxxx-grs-ipv6-64     512   4096    2  ###### 472.4%     0.002        0.01   0.00000  0.00000   651
2.6.32.2-xxxx-grs-ipv6-64     512   4096    4  ###### 503.1%     0.003        0.01   0.00000  0.00000   977
2.6.32.2-xxxx-grs-ipv6-64     512   4096    8  ###### 6713.%     0.005        0.01   0.00000  0.00000    81

Sequential Writes
                              File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier                    Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64     512   4096    1   63.19 19.50%     0.009        0.26   0.00000  0.00000   324
2.6.32.2-xxxx-grs-ipv6-64     512   4096    2   58.85 62.44%     0.016        0.27   0.00000  0.00000    94
2.6.32.2-xxxx-grs-ipv6-64     512   4096    4   53.21 201.5%     0.033        0.40   0.00000  0.00000    26
2.6.32.2-xxxx-grs-ipv6-64     512   4096    8   60.62 1229.%     0.129       19.86   0.00000  0.00000     5

Random Writes
                              File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier                    Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.6.32.2-xxxx-grs-ipv6-64     512   4096    1   56.77 13.08%     0.004        0.03   0.00000  0.00000   434
2.6.32.2-xxxx-grs-ipv6-64     512   4096    2   23.68 16.37%     0.005        0.03   0.00000  0.00000   145
2.6.32.2-xxxx-grs-ipv6-64     512   4096    4   13.86 17.74%     0.007        0.04   0.00000  0.00000    78
2.6.32.2-xxxx-grs-ipv6-64     512   4096    8   57.53 254.8%     0.019        0.05   0.00000  0.00000    23

Tester le cpu

Vous pouvez faire des tests de courtes durées comme chronométrer un décompression ou de longue durée (calculs). Voici quelques exemples :

Super PI

C’est une méthode qui va permettre de mesurer les performances du cpu sur une durée plus ou moins longue. C’est une application qui calcule les décimales du nombre Pi. Cette application est en 32 bits donc elle ne mettra pas à profit un cpu 64 bits (si vous le faite tourner sur une distribution 64 bits il faut installer ia32-libs ).

wget ftp://pi.super-computing.org/Linux/super_pi.tar.gz
tar xzf super_pi.tar.gz
./super_pi 20
------ Started super_pi run : Fri Jan 22 18:12:00 CET 2010
 ------ Ended super_pi run : Fri Jan 22 18:20:53 CET 2010
 Version 2.0 of the super_pi for Linux OS
 Fortran source program was translated into C program with version 19981204 of
 f2c, then generated C source program was optimized manually.
 pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the
 compilation.
 Start of PI calculation up to 16777216 decimal digits
 End of initialization. Time=       6.704 Sec.
 I= 1 L=       0        Time=      19.333 Sec.
 I= 2 L=       0        Time=      22.057 Sec.
 I= 3 L=       1        Time=      21.969 Sec.
 I= 4 L=       2        Time=      21.889 Sec.
 I= 5 L=       5        Time=      21.961 Sec.
 I= 6 L=      10        Time=      22.017 Sec.
 I= 7 L=      21        Time=      21.917 Sec.
 I= 8 L=      43        Time=      23.137 Sec.
 I= 9 L=      87        Time=      22.309 Sec.
 I=10 L=     174        Time=      21.897 Sec.
 I=11 L=     349        Time=      21.957 Sec.
 I=12 L=     698        Time=      23.033 Sec.
 I=13 L=    1396        Time=      22.265 Sec.
 I=14 L=    2794        Time=      22.045 Sec.
 I=15 L=    5588        Time=      21.957 Sec.
 I=16 L=   11176        Time=      22.109 Sec.
 I=17 L=   22353        Time=      22.225 Sec.
 I=18 L=   44707        Time=      22.349 Sec.
 I=19 L=   89415        Time=      21.913 Sec.
 I=20 L=  178831        Time=      22.061 Sec.
 I=21 L=  357662        Time=      22.745 Sec.
 I=22 L=  715326        Time=      21.429 Sec.
 I=23 L= 1430652        Time=      19.389 Sec.
 End of main loop
 End of calculation.    Time=     525.037 Sec.
 End of data output.    Time=       1.680 Sec.
 Total calculation(I/O) time=     526.717(     108.831) Sec.

Selon le nombre de décimales calculées (et surtout selon le cpu) le test durera de quelques minutes à quelques heures.

Temps de compression/décompression

cd /dev/shm;
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.31.5-ovh.tar.gz -O linux-2.6.31.5-ovh.tar.gz;
time gzip -d linux-2.6.31.5-ovh.tar.gz -c > /dev/null;
for i in ` seq 1 4` ; do time gzip -d linux-2.6.31.5-ovh.tar.gz -c > /dev/null & done

MySQL

mysql> SELECT benchmark(100000000,1+2);

Sinon vous pouvez essayer de manipuler de grandes quantités de données en regardant les temps d’exécution des requêtes.

Mettre la ram à vif

Un utilitaire pratique pour tester les performances des différentes mémoires du serveur (L1, L2, RAM, ..) est bandwidth :

wget http://home.comcast.net/~fbui/bandwidth.tar.gz
tar xzf bandwidth.tar.gz && chmod +x bandwidth bandwidth64
./bandwidth
L1 cache sequential read 8022.07 MB/sec
L1 cache sequential write 7524.32 MB/sec
L2 cache sequential read 6862.73 MB/sec
L2 cache sequential write 6318.39 MB/sec
Main memory sequential read 2207.22 MB/sec
Main memory sequential write 1602.92 MB/sec

Conclusion

Évidemment cela ne sert à rien de bourriner sur tout ce qui passe sous la main, ces tests sont à adapter à l’utilisation envisagée. Cela vaut la peine de pousser un peu pour bien se rendre compte des limites et ainsi avoir en tête le contexte et l’évolution de son utilisation à moyen terme.

Si on en a la possibilité, installer l’application voulue et la tester, ce sera le test le plus adapté. Le test le plus important sera celui du point faible du serveur ou de l’infrastructure, par exemple si le serveur est situé géographiquement loin ou encore si les données sont sur un SAN accessible en iSCSI, etc…

Si vous avez d’autres habitudes, propositions vous pouvez les indiquer en commentaire, je complèterai l’article en conséquence.