{"id":2709,"date":"2012-07-09T07:00:58","date_gmt":"2012-07-09T06:00:58","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=2709"},"modified":"2012-11-30T13:35:31","modified_gmt":"2012-11-30T12:35:31","slug":"la-pandaboard-au-poteau-de-torture-4-timers-xenomai","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2012\/07\/09\/la-pandaboard-au-poteau-de-torture-4-timers-xenomai\/","title":{"rendered":"La Pandaboard au poteau de torture – 4 – Timers Xenomai"},"content":{"rendered":"

\"La<\/a>Dans les pr\u00e9c\u00e9dents articles nous avons observ\u00e9 les limites de performance des timers Linux<\/a> et Linux-rt<\/a> sur une Pandabaord. Cette fois nous allons comparer ces r\u00e9sultats avec ceux que nous obtenons sous Xenomai.<\/p>\n

Aurons-nous une meilleure stabilit\u00e9 des t\u00e2ches p\u00e9riodiques ?<\/p>\n

\n\n<\/p>\n

Environnement d’exp\u00e9rimentation<\/h1>\n

Nous devons tout d’abord compiler un noyau Linux pour la Pandaboard apr\u00e8s lui avoir appliqu\u00e9 le patch Xenomai. Ceci est relativement simple, je l’avais d\u00e9j\u00e0 d\u00e9crit dans un article pr\u00e9c\u00e9dent<\/a>.<\/p>\n

Voici bri\u00e8vement les \u00e9tapes \u00e0 suivre, nous consid\u00e9rons que la partition de boot de la Pandaboard est mont\u00e9e dans notre arborescence dans \/media\/Boot<\/code> et sa partition racine dans \/media\/Root<\/code>.<\/p>\n

          T\u00e9l\u00e9charger Xenomai<\/em>\n[~]$ git clone http:\/\/git.xenomai.org\/xenomai-2.6.git xenomai<\/strong>\nCloning into 'xenomai'...\n  [...]\n          T\u00e9l\u00e9charger et d\u00e9compresser Linux<\/em>\n[~]$ wget http:\/\/www.kernel.org\/pub\/linux\/kernel\/v2.6\/linux-2.6.38.8.tar.bz2<\/a><\/strong>\n  [...]\n[~]$ tar xjf ~\/Data\/Repository\/linux-2.6.38.8.tar.bz2<\/strong>\n\n          Appliquer le patch Adeos sur Linux<\/em>\n[~]$ xenomai\/scripts\/prepare-kernel.sh --linux=linux-2.6.38.8\/ --ipipe=xenomai\/ksrc\/arch\/arm\/patches\/adeos-ipipe-2.6.38.8-arm-1.18-08.patch --arch=arm<\/strong>\npatching file arch\/arm\/Kconfig\npatching file arch\/arm\/boot\/compressed\/head.S\n  [...]\n\n          Configurer et compiler Linux et ses modules<\/em>\n[~]$ cd linux-2.6.38.8<\/strong>\n[linux-2.6.38.8]$ wget http:\/\/www.blaess.fr\/christophe\/files\/article-2012-07-09\/config-linux-2.6.38.8-xenomai<\/a><\/strong>\n  [...]\n[linux-2.6.38.8]$ mv config-linux-2.6.38.8-xenomai .config<\/strong>\n[linux-2.6.38.8]$ make ARCH=arm oldconfig<\/strong>\n  [...]\n[linux-2.6.38.8]$ make ARCH=arm CROSS_COMPILE=~\/cross-panda\/usr\/bin\/arm-linux- uImage<\/strong>\n  [...]\nLoad Address: 80008000\nEntry Point:  80008000\n  Image arch\/arm\/boot\/uImage is ready\n[linux-2.6.38.8]$ make ARCH=arm CROSS_COMPILE=~\/cross-panda\/usr\/bin\/arm-linux- modules<\/strong>\n  [...]\n  IHEX2FW firmware\/keyspan_pda\/keyspan_pda.fw\n  IHEX2FW firmware\/keyspan_pda\/xircom_pgs.fw\n[linux-2.6.38.8]$ \n\n        Copier le noyau sur la partition de boot de la Pandaboard<\/em>\n[linux-2.6.38.8]$ cp arch\/arm\/boot\/uImage \/media\/Boot\/<\/strong>\n\n        Copier les modules sur la partition racine de la Pandaboard<\/em>\n[linux-2.6.38.8]$ make ARCH=arm INSTALL_MOD_PATH=\/media\/Root  modules_install\n  [...]\n  INSTALL \/media\/Root\/lib\/firmware\/keyspan_pda\/keyspan_pda.fw\n  INSTALL \/media\/Root\/lib\/firmware\/keyspan_pda\/xircom_pgs.fw\n  DEPMOD  2.6.38.8-xenomai\n[linux-2.6.38.8]$ \n\n        Compiler et installer les biblioth\u00e8ques de Xenomai<\/em>\n[linux-2.6.38.8]$ cd ..\/xenomai<\/strong>\n[xenomai]$ PATH=$PATH:~\/cross-panda\/usr\/bin\/<\/strong>\n[xenomai]$ .\/configure --prefix=\/media\/Root\/usr\/xenomai --host=arm-linux CFLAGS='-march=armv7-a' LDFLAGS='-march=armv7-a' --enable-smp<\/strong>\n  [...]\nconfig.status: linking .\/include\/asm-generic to src\/include\/asm-generic\/xenomai\nconfig.status: executing depfiles commands\nconfig.status: executing libtool commands\n[xenomai]$ make<\/strong>\n  [...]\n[xenomai]$ make install<\/strong>  (peut n\u00e9cessiter les droits root)<\/em><\/pre>\n
Avant de d\u00e9marrer notre Pandaboard sur Xenomai, il nous faut un outil de test des timers. Voici un programme, calqu\u00e9 sur celui<\/a> que nous avons employ\u00e9 pour Linux et Linux-Rt, qui emploie l’API native de Xenomai.<\/p>\n
fluctuations-timer-xenomai.c: <\/a><\/strong>\n#include <stdio.h>\n#include <stdlib.h>\n#include <unistd.h>\n#include <sys\/mman.h>\n\n#include <rtdk.h>\n#include <native\/task.h>\n#include <native\/timer.h>\n\nstatic RTIME periode<\/strong>;\nstatic int nb_mesures = 0; \/\/ Nombre de mesures entre deux affichages\n\nvoid fonction_periodique<\/strong> (void * unused)\n{\n    RTIME precedent = 0; \n    RTIME heure = 0;\n    RTIME duree;\n\n    int mesure = 0;\n    long long int min = -1;\n    long long int max = 0;\n    long long int max_max = 0;\n    double sum = 0.0;\n\n    periode = periode * 1000; \/\/ en ns\n    rt_task_set_periodic<\/strong>(NULL, TM_NOW, periode);\n    while(1) {\n        rt_task_wait_period<\/strong>(NULL);\n        heure = rt_timer_read<\/strong>();\n        if (mesure != 0) { \n            duree = heure - precedent;\n            duree = duree \/ 1000; \/\/ en microsecondes\n            if ((min == -1) || (duree < min))\n                min = duree;\n            if (duree > max) {\n                max = duree;\n                if (max_max < max)\n                    max_max = max;\n            }\n            sum += duree;\n        }\n        precedent = heure;\n        mesure ++;\n        if (mesure >= nb_mesures) {\n            rt_fprintf<\/strong>(stdout, \"[%ld] Min.= %lld, Moy.= %.1lf, Max.= %lld,  Max.Max.= %lldn\",\n                (long int)(heure\/1000000000), min, sum \/ nb_mesures, max, max_max);\n            min = -1;\n            max = 0;\n            sum = 0.0;\n            mesure = 0;\n            rt_print_flush_buffers();\n        }\n    }\n}\n\nint main (int argc, char * argv[])\n{\n    int cpu = 0;\n    RT_TASK task;\n    int err;\n\n    mlockall(MCL_CURRENT|MCL_FUTURE);\n    rt_print_auto_init<\/strong>(1);\n\n    if ((argc < 2)\n     || (sscanf(argv[1], \"%lld\", & periode) != 1)\n     || ((argc == 3) && (sscanf(argv[2], \"%d\", & cpu) != 1))) {\n        fprintf(stderr, \"usage: %s periode_us [cpu]n\", argv[0]);\n        exit(EXIT_FAILURE);\n    }\n\n    if ((periode <= 0) || (periode > 2000000)) {\n        fprintf(stderr, \"%s: La periode doit etre dans [1, 2000000]n\", argv[0]);\n        exit(EXIT_FAILURE);\n    }\n\n    if ((cpu < 0) || (cpu >= sysconf(_SC_NPROCESSORS_ONLN))) {\n        fprintf(stderr, \"%s: Le CPU doit etre dans [0, %ld]n\", argv[0], sysconf(_SC_NPROCESSORS_ONLN) - 1);\n        exit(EXIT_FAILURE);\n    }\n\n    setvbuf(stdout, NULL, _IONBF, 0);\n\n    nb_mesures = 5000000 \/ periode;\n    if (nb_mesures == 0) {\n        fprintf(stderr, \"periode trop longuen\");\n        exit(EXIT_FAILURE);\n    }\n\n    if ((err = rt_task_spawn<\/strong>(& task, \"Fluctuation-RT-TIMER\", 0, 99, T_JOINABLE | T_CPU(cpu),\n                             fonction_periodique, NULL)) != 0) {\n        fprintf(stderr, \"rt_task_spawn: %sn\", strerror(-err));\n        exit(EXIT_FAILURE);\n    }\n\n    rt_task_join(& task);\n    return EXIT_SUCCESS;\n}<\/pre>\n
On passe au programme deux arguments : la p\u00e9riode du timer (en microsecondes) et le num\u00e9ro du CPU sur lequel il doit s’ex\u00e9cuter. Pour compiler ce code, il nous faut un Makefile<\/em> qui g\u00e8re les options de compilation de Xenomai.<\/p>\n
Makefile :<\/a><\/strong>\n.PHONY: all\nall: fluctuations-timer-xenomai\n\nXENOCONFIG?=\/usr\/xenomai\/bin\/xeno-config\n\nfluctuations-timer-xenomai:fluctuations-timer-xenomai.c\n\t$(shell $(XENOCONFIG) --cc) $(shell $(XENOCONFIG) --skin=native --cflags) $(shell $(XENOCONFIG) --skin=native --ldflags) -L $(shell  $(XENOCONFIG) --skin=native --libdir) -o fluctuations-timer-xenomai fluctuations-timer-xenomai.c -lnative -lxenomai\n\n.PHONY: clean\nclean::\n\trm -f  *.o  .*.o  .*.o.* *.ko  .*.ko  *.mod.* .*.mod.* .*.cmd *~\n\trm -f Module.symvers Module.markers modules.order \n\trm -rf .tmp_versions\n\trm -f fluctuations-timer-xenomai<\/pre>\n
Les param\u00e8tres de compilation seront fournis par le script xeno-config<\/code> qui se trouve dans le r\u00e9pertoire d’installation de Xenomai (sur la partition Root<\/em> de la carte SD).<\/p>\n
$ make XENOCONFIG=\/media\/Root\/usr\/xenomai\/bin\/xeno-config<\/strong>\narm-linux-gcc -I\/media\/Root\/usr\/xenomai\/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -lnative -L\/media\/Root\/usr\/xenomai\/lib -lxenomai -lpthread -lrt -L \/media\/Root\/usr\/xenomai\/lib -o fluctuations-timer-xenomai fluctuations-timer-xenomai.c -lnative -lxenomai\n$ cp fluctuations-timer-xenomai \/media\/Root\/usr\/local\/bin\/<\/strong>\n$<\/pre>\n
Enfin, pour lancer le programme en boucle, j’ai r\u00e9utilis\u00e9 le script mis au point pr\u00e9c\u00e9demment<\/a>, en rempla\u00e7ant le nom du fichier de r\u00e9sultat<\/p>\n
resultat-fluctuations-timer-linux<\/strong>-${COMPTEUR}.txt<\/pre>\n
en<\/p>\n
resultat-fluctuations-timer-xenomai<\/strong>-${COMPTEUR}.txt<\/pre>\n
et l’invocation<\/p>\n
chrt -f 99 \/usr\/local\/bin\/fluctuations-timer 100<\/pre>\n
par l’appel du programme ci-dessus ainsi<\/p>\n
\/usr\/local\/bin\/fluctuations-timer-xenomai 100 0<\/pre>\n
Nous copions donc le script modifi\u00e9<\/a> dans le syst\u00e8me de fichiers sur la carte SD.<\/p>\n
$ wget http:\/\/www.blaess.fr\/christophe\/files\/article-2012-07-09\/lance-test-fluctuations-timer-xenomai.sh<\/a><\/strong>\n[...]\n$ cp lance-test-fluctuations-timer-xenomai.sh \/media\/Root\/usr\/local\/bin\/<\/strong>\n$ umount \/media\/*oot<\/strong>\n$<\/pre>\n
Lancement du test<\/h1>\n
J’ai tout d’abord fait tourner le test sur le c\u0153ur 1, en modifiant dans le script le second argument sur la ligne invoquant le programme fluctuations-timer-xenomai<\/code>. Le syst\u00e8me \u00e9tait soumis \u00e0 une tr\u00e8s forte charge en appels-syst\u00e8me, en processus, et en interruptions externes. Nous avons vu dans l’article pr\u00e9c\u00e9dent que les traitements des interruptions \u00e9taient, par d\u00e9faut, r\u00e9alis\u00e9s sur le c\u0153ur 0. Aussi notre programme s’ex\u00e9cutant sur le c\u0153ur 1 est l\u00e9g\u00e8rement pr\u00e9serv\u00e9 de leurs effets.<\/p>\n
Le premier test s’est d\u00e9roul\u00e9 pendant une quinzaine d’heures (puis j’ai d\u00fb interrompre l’exp\u00e9rience car il me fallait d\u00e9brancher l’alimentation). J’ai alors r\u00e9alis\u00e9 un graphique avec le m\u00eame script que les exp\u00e9riences sous Linux et Linux-rt<\/p>\n
\"Fluctuations<\/a><\/p>\n
Quelle surprise ! Alors qu’avec Linux vanilla<\/em> et Linux-rt les fluctuations s’\u00e9tendaient jusqu’\u00e0 6 millisecondes, les r\u00e9sultats sous Xenomai montrent des timers dont la pire variation ne d\u00e9passe pas 128 microsecondes au lieu de 100 microsecondes, soient 28 microsecondes de jitter<\/em>. J’ai d\u00fb modifier le script de cr\u00e9ation du graphique en zoomant 20 fois<\/strong> l’axe des ordonn\u00e9es.<\/p>\n
\"Fluctuations<\/a><\/p>\n
On peut remarquer sur ce graphique des p\u00e9riodes nettes o\u00f9 les valeurs fluctuent dans des intervalles diff\u00e9rents. Je suppose qu’il s’agit des moments o\u00f9 j’ajoutais des ping<\/code> flood<\/em> suppl\u00e9mentaires depuis d’autres machines.<\/p>\n
Encourag\u00e9 par ces premiers r\u00e9sultats, j’ai relanc\u00e9 le test pendant deux jours, en le pla\u00e7ant cette fois sur le c\u0153ur z\u00e9ro, l\u00e0 o\u00f9 les interruptions sont trait\u00e9es. Les variations sont l\u00e9g\u00e8rement plus importantes puisque l’on atteint un maximum de 151 microsecondes au lieu de 100 microsecondes. Voici les graphiques correspondants.<\/p>\n
\"Fluctuations<\/a><\/p>\n
\"Fluctuations<\/a><\/p>\n
Conclusion<\/h1>\n
Ce test met en relief les performances de Xenomai, compar\u00e9es \u00e0 celles de Linux et Linux-rt. Les t\u00e2ches temps r\u00e9el de Xenomai s’ex\u00e9cutent avec une fiabilit\u00e9 beaucoup plus grande en ce qui concerne l’instant de d\u00e9clenchement. Nous voyons que la fluctuation maximale obtenue sur une Pandaboard avec un timer Xenomai est de 51 microsecondes (j’ai prolong\u00e9 encore l’exp\u00e9rience depuis, et obtenu la m\u00eame limite maximale). Ceci est coh\u00e9rent avec les r\u00e9sultats fournis par l’outil latency<\/code> livr\u00e9 avec Xenomai, qui nous indique ici une latence maximale de 51.579 microsecondes sur un test \u00e0 haute charge de 6 heures.<\/p>\n
[Panda]# export LD_LIBRARY_PATH=\/usr\/xenomai\/lib<\/strong>\n[Panda]# \/usr\/xenomai\/bin\/latency -p 100 -T 21700<\/strong>\n== Sampling period: 100 us\n== Test mode: periodic user-mode task\n== All results in microseconds\nwarming up...\n[...]\nRTD|      3.507|      7.674|     27.321|       0|     0|      2.908|     51.579\nRTD|      3.517|      7.724|     30.472|       0|     0|      2.908|     51.579\n---|-----------|-----------|-----------|--------|------|-------------------------\nRTS|      2.908|      7.797|     51.579|       0|     0|    06:00:00\/06:00:00\n[Panda]#<\/pre>\n
Pour en savoir plus:<\/h1>\n