{"id":2781,"date":"2012-07-23T02:01:13","date_gmt":"2012-07-23T01:01:13","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=2781"},"modified":"2012-11-30T13:33:55","modified_gmt":"2012-11-30T12:33:55","slug":"les-latences-de-xenomai","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2012\/07\/23\/les-latences-de-xenomai\/","title":{"rendered":"Les latences de Xenomai"},"content":{"rendered":"

\"Latences<\/a>
\nJ’ai abord\u00e9 dans plusieurs articles (Xenomai sur Pandaboard<\/a>, GPIO, Pandaboard et temps r\u00e9el\u00a0 \u2013 Gestion des interruptions<\/a>, La Pandaboard au poteau de torture \u2013 Timers Xenomai<\/a>…) la question des latences maximales de Xenomai. Mais il est aussi int\u00e9ressant de conna\u00eetre et de configurer correctement la latence minimale.<\/p>\n

\n\n<\/p>\n

Mesure des latences<\/h1>\n

La notion de latence fait r\u00e9f\u00e9rence ici \u00e0 la dur\u00e9e qui s’\u00e9coule entre le d\u00e9clenchement d’une interruption et le d\u00e9but du traitement que nous avons associ\u00e9 \u00e0 cette interruption. Cette dur\u00e9e d\u00e9pend en grande partie du syst\u00e8me d’exploitation et du mat\u00e9riel. On s’int\u00e9resse g\u00e9n\u00e9ralement \u00e0 la latence maximale car c’est elle qui concerne les applications temps r\u00e9el par exemple. Ainsi le cahier des charges d’un projet peut imposer qu’entre l’activation d’un capteur externe et la r\u00e9ponse du syst\u00e8me il ne s’\u00e9coule pas plus de 100 microsecondes quels que soient la charge logicielle ou la quantit\u00e9 d’interruptions se d\u00e9clenchant \u00e0 ce moment.<\/p>\n

La latence maximale se mesure avec des exp\u00e9riences de longues dur\u00e9es (plusieurs jours voire plusieurs semaines) sous une tr\u00e8s haute charge (en t\u00e2ches et en interruptions). \u00c0 titre d’exemple, nous avons observ\u00e9 dans les articles mentionn\u00e9s plus haut que sur une carte Pandaboard, le syst\u00e8me Xenomai 2.6.1 nous permet d’obtenir une latence maximale de 50 microsecondes environ.<\/p>\n

Pour cela, un utilitaire livr\u00e9 avec Xenomai mesure le temps s’\u00e9coulant entre le d\u00e9clenchement d’un timer mat\u00e9riel et l’activation de la routine de traitement. Cet outil s’appelle latency<\/code>, voici un exemple d’utilisation sur un syst\u00e8me faiblement charg\u00e9.<\/p>\n

# \/usr\/xenomai\/bin\/latency -p 100 -T 14400<\/strong>\n== Sampling period: 100 us\n== Test mode: periodic user-mode task\n== All results in microseconds\nwarming up...\nRTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)\nRTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst\nRTD|      0.724|      0.996|     13.918|       0|     0|      0.724|     13.918\nRTD|      0.490|      1.182|     12.357|       0|     0|      0.490|     13.918\nRTD|      0.486|      0.966|      8.396|       0|     0|      0.486|     13.918\nRTD|      0.468|      1.001|     14.261|       0|     0|      0.468|     14.261\nRTD|      0.478|      0.970|     12.934|       0|     0|      0.468|     14.261\nRTD|      0.476|      0.988|      6.640|       0|     0|      0.468|     14.261\nRTD|      0.494|      1.001|      8.414|       0|     0|      0.468|     14.261\nRTD|      0.488|      0.964|      9.918|       0|     0|      0.468|     14.261\nRTD|      0.476|      0.956|      7.882|       0|     0|      0.468|     14.261\nRTD|      0.484|      0.956|      8.386|       0|     0|      0.468|     14.261\nRTD|      0.486|      0.960|      7.815|       0|     0|      0.468|     14.261\nRTD|      0.486|      0.972|      8.244|       0|     0|      0.468|     14.261\n[...]<\/pre>\n
Les options utilis\u00e9es ici indiquent que le timer doit suivre une p\u00e9riode de 100\u00a0microsecondes, et que la dur\u00e9e totale de la mesure sera de 14400\u00a0secondes soient 4\u00a0heures.<\/p>\n
L’outil latency<\/code> affiche une ligne de r\u00e9sultats interm\u00e9diaires toutes les secondes, sur lesquelles il pr\u00e9sente les latences minimales (lat min<\/code>), moyennes (lat avg<\/code>) et maximales (lat max<\/code>) rencontr\u00e9es pendant la seconde \u00e9coul\u00e9e. Ensuite il indique les d\u00e9passements de timers (overrun<\/code>) et les changements de mode (msw<\/code>) au sens de Xenomai.
\nEnfin les deux derni\u00e8res colonnes indiquent les plus courtes (lat best<\/code>) et plus longues (lat worst<\/code>) latences rencontr\u00e9es sur tout le d\u00e9roulement du processus.<\/p>\n
Au bout de quatre heures l’exp\u00e9rience se termine sur les r\u00e9sultats suivants.<\/p>\n
RTD|      0.482|      0.976|      8.652|       0|     0|     -0.393|     31.192\nRTD|      0.496|      0.968|      6.450|       0|     0|     -0.393|     31.192\nRTD|      0.527|      0.982|     13.291|       0|     0|     -0.393|     31.192\nRTD|      0.494|      0.964|      7.890|       0|     0|     -0.393|     31.192\nRTD|      0.456|      0.960|      6.482|       0|     0|     -0.393|     31.192\nRTD|      0.492|      0.970|     12.140|       0|     0|     -0.393|     31.192\nRTD|      0.498|      0.966|      7.265|       0|     0|     -0.393|     31.192\nRTD|      0.503|      0.980|      9.224|       0|     0|     -0.393|     31.192\n---|-----------|-----------|-----------|--------|------|-------------------------\nRTS|     -0.393|      0.900|     31.192|       0|     0|    04:00:00\/04:00:00\n#<\/pre>\n
Nous voyons que la pire latence rencontr\u00e9e ici est de 31.192 microsecondes. Mais le syst\u00e8me n’\u00e9tait pas tr\u00e8s sollicit\u00e9 et on pourrait rencontrer des latences jusqu’\u00e0 50 microsecondes environ sous une forte charge.<\/p>\n
Ce qui est plus surprenant c’est la latence minimale : elle est n\u00e9gative ! Cela signifierait donc que la routine de traitement se d\u00e9clenche avant l’interruption timer ? Plut\u00f4t \u00e9trange…<\/p>\n
Anticipation de la latence minimale<\/h1>\n
En r\u00e9alit\u00e9, lorsque Xenomai programme le d\u00e9clenchement d’un timer, il anticipe la dur\u00e9e qui s’\u00e9coulera entre l’interruption mat\u00e9rielle et l’arriv\u00e9e dans la routine de traitement. Ainsi nous obtenons de meilleures performances pour l’ensemble des t\u00e2ches diff\u00e9r\u00e9es ou p\u00e9riodiques.<\/p>\n
Mais comment peut-il anticiper la dur\u00e9e ? Simplement en se basant sur une valeur pr\u00e9programm\u00e9e, que l’on peut consulter dans le pseudo-fichier \/proc\/xenomai\/latency<\/code>. En voici un exemple.<\/p>\n
[Panda]# cat \/proc\/xenomai\/latency <\/strong>\n2499\n[Panda]#<\/pre>\n
Xenomai consid\u00e8re qu’il s’\u00e9coulera environ 2.5 microsecondes au minimum entre l’arriv\u00e9e d’une interruption et son traitement, aussi avance-t-il de cette dur\u00e9e les timers qu’il programme.<\/p>\n
Mais cette valeur est pr\u00e9programm\u00e9e arbitrairement. Il serait int\u00e9ressant de l’ajuster exp\u00e9rimentalement en fonction de notre mat\u00e9riel. Pour cela il faut simplement effacer la latence minimale, et relancer le programme latency<\/code>.<\/p>\n
# echo 0 > \/proc\/xenomai\/latency<\/strong>\n# \/usr\/xenomai\/bin\/latency -p 100 -T 14400<\/strong>\n== Sampling period: 100 us\n== Test mode: periodic user-mode task\n== All results in microseconds\nwarming up...\nRTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)\nRTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst\nRTD|      3.204|      3.355|      9.928|       0|     0|      3.204|      9.928\nRTD|      2.950|      3.234|      9.692|       0|     0|      2.950|      9.928\nRTD|      2.962|      3.317|     11.464|       0|     0|      2.950|     11.464\nRTD|      2.948|      3.134|     15.281|       0|     0|      2.948|     15.281\nRTD|      2.930|      3.140|      9.974|       0|     0|      2.930|     15.281\n[...]\nRTD|      2.966|      3.275|     10.553|       0|     0|      2.136|     18.827\nRTD|      2.962|      3.283|     10.033|       0|     0|      2.136|     18.827\nRTD|      2.962|      3.277|      9.607|       0|     0|      2.136|     18.827\nRTD|      2.952|      3.277|     10.422|       0|     0|      2.136|     18.827\n---|-----------|-----------|-----------|--------|------|-------------------------\nRTS|      2.136|      3.216|     18.827|       0|     0|    04:00:00\/04:00:00<\/pre>\n
Il n’y a plus d’anticipation, les latences sont donc naturellement un peu plus longues. Au bout de quatre heures, avec un syst\u00e8me tr\u00e8s peu charg\u00e9, nous avons obtenue une latence la plus faible de 2.136 microsecondes. Ce qui est plus faible que les 2.5 qui \u00e9taient pr\u00e9programm\u00e9s auparavant et explique donc l’\u00e9cart n\u00e9gatif de 0.39 microsecondes observ\u00e9 durant la premi\u00e8re exp\u00e9rience.<\/p>\n
Connaissant cette valeur minimale, nous pouvons l’inscrire dans \/proc\/xenomai\/latency<\/code> et relancer l’exp\u00e9rience.<\/p>\n
# echo 2136 > \/proc\/xenomai\/latency<\/strong>\n# \/usr\/xenomai\/bin\/latency -p 100 -T 14400<\/strong>\n== Sampling period: 100 us\n== Test mode: periodic user-mode task\n== All results in microseconds\nwarming up...\nRTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)\nRTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst\nRTD|      1.103|      1.265|      8.152|       0|     0|      1.103|      8.152\nRTD|      0.853|      1.204|      8.138|       0|     0|      0.853|      8.152\nRTD|      0.857|      1.216|      7.853|       0|     0|      0.853|      8.152\n[...]\nRTD|      0.827|      1.047|      8.321|       0|     0|      0.039|     21.178\nRTD|      0.839|      1.043|      7.926|       0|     0|      0.039|     21.178\nRTD|      0.831|      1.041|      7.188|       0|     0|      0.039|     21.178\nRTD|      0.829|      1.039|      7.587|       0|     0|      0.039|     21.178\n---|-----------|-----------|-----------|--------|------|-------------------------\nRTS|      0.039|      1.130|     21.178|       0|     0|    04:00:00\/04:00:00<\/pre>\n
Cette fois notre syst\u00e8me est tr\u00e8s bien calibr\u00e9, la latence minimale \u00e9tant descendue \u00e0 39 nanosecondes.<\/p>\n
Notez que la valeur exacte peut \u00eatre ainsi inscrite dans \/proc\/xenomai\/latency<\/code> dans le cours d’un script de d\u00e9marrage par exemple, mais \u00e9galement \u00eatre programm\u00e9e \u00ab\u00a0en dur\u00a0\u00bb \u00e0 la compilation du noyau dans le menu Real Time Sub-system<\/em>, sous-menu Timing<\/em>, option Scheduling latency (ns)<\/em>.<\/p>\n
\"Configuration<\/a><\/p>\n
Conclusion<\/h1>\n
La configuration compl\u00e8te d’un syst\u00e8me temps r\u00e9el est un processus long, qui n\u00e9cessite des exp\u00e9rimentations sur de longues dur\u00e9es avec des charges tr\u00e8s vari\u00e9es tant en processus qu’en interruptions. Xenomai nous permet de r\u00e9gler beaucoup de param\u00e8tres pour ajuster au mieux le syst\u00e8me au mat\u00e9riel cible.<\/p>\n
PS: Je manque un peu de temps pour tenir le blog en ce moment, une partie non n\u00e9gligeable de mon temps libre \u00e9tant consacr\u00e9 \u00e0 l’exploration du Raspberry Pi (dont je reparlerai ici tr\u00e8s prochainement bien s\u00fbr).<\/p>","protected":false},"excerpt":{"rendered":"
J’ai abordé dans plusieurs articles (Xenomai sur Pandaboard, GPIO, Pandaboard et temps réel  – Gestion des interruptions, La Pandaboard au poteau de torture – Timers Xenomai…) la question des latences maximales de Xenomai. Mais il est aussi intéressant de connaître et de configurer correctement la latence minimale.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,8,14],"tags":[],"class_list":["post-2781","post","type-post","status-publish","format-standard","hentry","category-embarque","category-linux-2","category-temps-reel"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/2781","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=2781"}],"version-history":[{"count":1,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/2781\/revisions"}],"predecessor-version":[{"id":3229,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/2781\/revisions\/3229"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=2781"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=2781"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=2781"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}