{"id":2453,"date":"2012-06-18T07:00:52","date_gmt":"2012-06-18T06:00:52","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=2453"},"modified":"2012-11-30T13:42:47","modified_gmt":"2012-11-30T12:42:47","slug":"la-pandaboard-au-poteau-de-torture-2-fluctuations-de-timers-linux","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2012\/06\/18\/la-pandaboard-au-poteau-de-torture-2-fluctuations-de-timers-linux\/","title":{"rendered":"La Pandaboard au poteau de torture – 2 – Fluctuations de timers Linux"},"content":{"rendered":"

\"Pandaboard<\/a>Dans le pr\u00e9c\u00e9dent article<\/a>, nous avons examin\u00e9 les possibilit\u00e9s de fonctionnement en continu d’une carte Pandaboard. Il s’est av\u00e9r\u00e9 que l’ajout d’un dissipateur thermique \u00e9tait indispensable pour maintenir un r\u00e9gime permanent \u00e0 100% du CPU.<\/p>\n

Nous allons dans cet article observer le comportement d’un timer logiciel Linux sur cette carte sous une haute charge – tant logicielle qu’en interruptions – et mesurer les fluctuations maximales.<\/p>\n

\n\n<\/p>\n

M\u00e9thode de mesure<\/h1>\n

Timers Linux<\/h2>\n

Le programme suivant utilise l’API des timers Posix timer_create()<\/code> et timer_settime()<\/code> propos\u00e9e par le noyau Linux. Il programme la r\u00e9ception p\u00e9riodique d’un signal. Dans les exp\u00e9riences ci-dessous, j’ai utilis\u00e9 un timer de 100 micro-secondes. Cette valeur est choisie de mani\u00e8re \u00e0 ce que la p\u00e9riode soit sensiblement plus courte que celle du tick syst\u00e8me (pour les noyaux compil\u00e9s sans l’option tickless<\/em>). Sur les syst\u00e8mes ARM, le tick est g\u00e9n\u00e9ralement r\u00e9gl\u00e9 \u00e0 une fr\u00e9quence de 128Hz, parfois 1000Hz. En utilisant un d\u00e9clenchement \u00e0 10kHz, nous obligeons le kernel \u00e0 utiliser des timers de pr\u00e9cision \u00e9lev\u00e9e (High Resolution Timers<\/em>). En contrepartie, nous choisissons une p\u00e9riode relativement longue par rapport \u00e0 la dur\u00e9e du traitement \u00e0 r\u00e9aliser lors de la r\u00e9ception du signal (quelques microsecondes).<\/p>\n

Lorsque le timer se d\u00e9clenche, notre programme mesure la dur\u00e9e \u00e9coul\u00e9e depuis l’occurrence pr\u00e9c\u00e9dente gr\u00e2ce \u00e0 l’API clock_gettime()<\/code>. Il affiche toutes les cinq secondes les dur\u00e9es minimale, maximale et moyenne observ\u00e9es. En outre, il conserve la pire valeur (intitul\u00e9e \u00ab\u00a0Max Max\u00a0\u00bb dans les r\u00e9sultats) rencontr\u00e9e depuis le d\u00e9but de son ex\u00e9cution.<\/p>\n

fluctuations-timer.c: <\/strong><\/a>\n\n#include <signal.h>\n#include <stdio.h>\n#include <stdlib.h>\n#include <time.h>\n#include <unistd.h>\n\nstatic int nb_mesures = 0;\n\nvoid handler_alarm(int unused)\n{\n    static long long int min;\n    static long long int max;\n    static double sum;\n    static long long int max_max = 0;\n    static struct timespec precedent;\n    static int mesure = -1;\n\n    long long int duree;\n    struct timespec ts;\n\n    \/\/ Reinitialisation des mesures intermediaires\n    if (mesure == -1) {\n        min = -1;\n        max = 0;\n        sum = 0;\n        clock_gettime(CLOCK_REALTIME, & precedent);\n        mesure ++;\n        return;\n    } \n\n    clock_gettime(CLOCK_REALTIME, & ts)<\/strong>;\n    duree  = ts.tv_sec - precedent.tv_sec;\n    duree *= 1000000000; \/\/ en nanosecondes\n    duree += ts.tv_nsec - precedent.tv_nsec;\n    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 = duree;\n    }\n    sum += duree;\n    precedent = ts;\n    mesure ++;\n    if (mesure == nb_mesures) {\n        fprintf(stdout, \"[%ld] Min.= %lld, Moy.= %.1lf, Max.= %lld,  Max.Max.= %lldn\",\n            time(NULL), min, sum \/ nb_mesures, max, max_max);\n        fflush(stdout);\n        mesure = -1;\n    }\n\n}\n\nint main (int argc, char * argv[])\n{\n    long int periode;\n    timer_t tmr;\n    struct sigevent notification;\n    struct itimerspec itimer;\n\n    if ((argc != 2) || (sscanf(argv[1], \"%ld\", & periode) != 1)) {\n        fprintf(stderr, \"usage: %s periode_usn\", argv[0]);\n        exit(EXIT_FAILURE);\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    nb_mesures = 5000000 \/ periode;\n    if (nb_mesures == 0) {\n        fprintf(stderr, \"periode trop longuen\");\n        exit(EXIT_FAILURE);\n    }\n    signal(SIGALRM, handler_alarm);\n    notification.sigev_notify = SIGEV_SIGNAL;\n    notification.sigev_signo  = SIGALRM;\n    if (timer_create(CLOCK_REALTIME, & notification, & tmr)<\/strong> != 0) {\n        perror(\"timer_create\");\n        exit(EXIT_FAILURE);\n    }\n\n    itimer.it_value.tv_sec  = itimer.it_interval.tv_sec  = periode \/ 1000000;  \/\/ en secondes\n    itimer.it_value.tv_nsec = itimer.it_interval.tv_nsec = (periode % 1000000) * 1000; \/\/ en nanosecondes\n    if (timer_settime(tmr, 0, & itimer, NULL)<\/strong> != 0) {\n        perror(\"timer_settime\");\n        exit(EXIT_FAILURE);\n    }\n\n    while(1)\n        pause();\n\n    return EXIT_SUCCESS;\n}<\/pre>\n
Voici le type de r\u00e9sultats que nous fournit ce programme. Naturellement nous l’ex\u00e9cutons sous un ordonnancement temps-r\u00e9el afin de s’affranchir des fluctuations li\u00e9es \u00e0 l’ordonnancement en temps partag\u00e9.<\/p>\n
# chrt -f 80 .\/fluctuations-timer 100 <\/strong>\n[1339860164] Min.= 00, Moy.= 99.7, Max.= 305,  Max.Max.= 305\n[1339860169] Min.= 30, Moy.= 99.7, Max.= 274,  Max.Max.= 305\n[1339860174] Min.= 30, Moy.= 99.7, Max.= 366,  Max.Max.= 366\n[1339860179] Min.=  0, Moy.= 99.7, Max.= 274,  Max.Max.= 366\n[1339860184] Min.= 30, Moy.= 99.7, Max.= 305,  Max.Max.= 366\n[1339860189] Min.=  0, Moy.= 99.7, Max.= 305,  Max.Max.= 366\n  (Contr\u00f4le-C<\/em>)<\/strong>\n#<\/pre>\n
Mesures de longues dur\u00e9es<\/h2>\n
Lorsque l’on d\u00e9sire conna\u00eetre les pires fluctuations auxquelles on peut s’attendre sur un syst\u00e8me donn\u00e9, il est n\u00e9cessaire de r\u00e9aliser ce genre d’exp\u00e9rience de mani\u00e8re prolong\u00e9e, avec une charge tr\u00e8s \u00e9lev\u00e9e, tant en ce qui concerne les processus et l’ordonnancement qu’en termes d’interruptions et d’appels syst\u00e8me.<\/p>\n
Pour cela, nous allons \u00e9crire un script qui fait tourner ce programme en boucle en remplissant des fichiers de mesure. Chaque ex\u00e9cution (chaque fichier) durera une journ\u00e9e. Nous mesurerons les secondes \u00e0 partir de z\u00e9ro en ramenant chaque fois l’heure syst\u00e8me au 1er janvier 1970.<\/p>\n
Le principe est donc en substance repr\u00e9sent\u00e9 par le squelette de script suivant.<\/p>\n
#! \/bin\/sh\n\n# Trouver le premier nom de fichier inutilise. \nCOMPTEUR=0\nwhile true\ndo\n    COMPTEUR=$((COMPTEUR + 1))\n    FICHIER_RESULTATS=\/root\/resultat-fluctuations-timer-linux-${COMPTEUR}.txt\n    if ! [ -f \"${FICHIER_RESULTATS}\" ]; then break; fi\ndone\n\nwhile true\ndo\n    # Retour dans le passe ! \n    date -s 1970.01.01-00:00\n\n    # Lancer la mesure\n\n    date +\"##[%s] Debut de l'experience\" > \"${FICHIER_RESULTATS}\"\n    txt=$(uname -a)\n    date +\"##[%s] $txt\" >> \"${FICHIER_RESULTATS}\"\n\n    chrt -f 99 \/usr\/local\/bin\/fluctuations-timer 100 >> \"${FICHIER_RESULTATS}\" &<\/strong>\n\n    while true\n    do\n        # Charger le systeme\n        [...]\n\n        sleep 300\n        SECONDES=$(date +%s)\n        if [ $SECONDES -ge 86400 ]; then break; fi\n    done\n\n    killall fluctuations-timer\n    echo \"##[$SECONDES] Fin de l'experience\" >> \"${FICHIER_RESULTATS}\"\n\n    COMPTEUR=$((COMPTEUR + 1))\n    FICHIER_RESULTATS=\/root\/resultat-fluctuations-timer-linux-${COMPTEUR}.txt\ndone<\/pre>\n
Charge syst\u00e8me importante<\/h2>\n
Pour avoir des chances de rencontrer assez rapidement les pires fluctuations, il est tr\u00e8s important de charger excessivement le syst\u00e8me. Pour ce faire, je me suis inspir\u00e9 du script dohell<\/code><\/strong> qui est livr\u00e9 avec Xenomai. Celui-ci multiplie les commandes pour surcharger tous les aspects du syst\u00e8me.<\/p>\n
J’ai d\u00e9cid\u00e9 d’alterner les p\u00e9riodes de tr\u00e8s fortes charge pendant cinq minutes avec des p\u00e9riodes de repos de trente secondes. Ceci permet d’augmenter les phases de transition, pendant lesquelles surviennent souvent les pires conditions plut\u00f4t que durant les phases de fonctionnement en r\u00e9gime permanent.<\/p>\n
Pendant les p\u00e9riodes de charge, nous lan\u00e7ons des t\u00e2ches qui r\u00e9alisent de tr\u00e8s nombreux appels-syst\u00e8me.<\/p>\n