Forum Linux.embarqué linux temps réel

Posté par  .
Étiquettes : aucune
0
19
avr.
2006
bonjour,

j'ai compilé un noyau 2.6.14 patcher xenomai-2.1-rc2, j'ai noyau qui tourne, cependant lorsque j'essais de faire tourner des taches vxWorks sous mon noyaux (les taches vxworks deviennent des threads sous linux)tous s'exécutant au sein d'un seul et même process.

. Or, j'ai choisi que ce process s'exécute en mode 'User', pour plus de
commodité, et aussi parce que la programmation 'kernel' me fait un peu
peur ...

. LXRT est le mécanisme qui permet à un process 'User' d'être quand même
'temps réel' : Si j'ai bien compris, le fonctionnement de la tâche se fait
principalement en mode kernel 'temps réel', et à chaque fois qu'un appel
système doit être fait, on repasse en mode 'Linux' standard pendant tout
le temps que dure ce service ...

. Il semble malheureusement que dès qu'un appel système est lancé dans un
des thread (typiquement la fonction select avec un timeout de plusieurs
centaines de mS est systématiquement utilisée dans les tâches 'réseau'),
alors le fonctionnement temps réel des autres thread est complètement coincé !

Pour illustrer cela, j'ai fait une application très simple, On crée 5 tâches qui
impriment un messages tous les 100 ticks.
Après la création, si la tâche principale bloque sur un scanf pour
attendre une validation opérateur, alors tout s'arrête.
En revanche, si la tâche boucle en testant le clavier (fonction kbhit) et
en faisant des taskDelay(), le fonctionnement continue.

est ce que ce comportement est normal?
et comment faire pour le contourner?

merci!!!

gdroopy

  • # Temps réél et Linux: Le grand amour

    Posté par  (site web personnel) . Évalué à 2.

    Bon alors j'aide mon pere à faire un truc qui ressemble à du temps réél sous un Linux de base et à une modif(et encore non nécessaire c'est pour que le temps réél "partagé" fonctionne) pres il fonctionne plutot bien en mettant l'ordonanceur en temps réél (FIFO ou Round Robin si t'as qu'une tache avec la priorité la plus basse ca pose pas de probleme), des que la tache la est bloquée (ou elle ecrit vers un cpu de priorité plus haute, ou comme dans ton cas fait une attente passive), les taches de priorité supérieur sont lancées. Apres si t'as plusieurs taches de meme priorité (enfin pour moi c'est plus du temps réél à ce moment la), ca peut poser probleme, vu que le timeslice alloué par défaut à une application est 100ms (ca pose surtout probleme au lancement de la tache, apres je crois que ca s'ameliore), enfin bon c'est "configurable" dans les sources du noyau (si c'est ton cas je pourais retrouver ce qu'il faut changer et dans quel fichier mais je me souviens que ca a été plutot long à trouver)

    Enfin bon apres c'est mon experience mais j'ai toujours vu partout que Linux ne gérait pas le temps réél qu'il etait pas prevu pour, alors bon je comprends pas trop....

    • [^] # Re: Temps réél et Linux: Le grand amour

      Posté par  . Évalué à 1.

      Le noyau standard n'est pas conçu pour le temps réel mais il y a des patchs pour améliorer les temps de latence, et d'autres modifications plus importantes pour en faire du "vrai" temps réel (RTLinux, RTAI). Le timeslice est plutôt de 10ms par défaut je crois (100 HZ).

    • [^] # Re: Temps réél et Linux: Le grand amour

      Posté par  . Évalué à 1.

      bonjour,

      linux n'est pas nativement un os temps réel, bien que le noyaux 2.6 intègre la gestion des priorités (pour du temps réel "mou") mais un noyau patcher avec xenomai devient temps réel (xenomai issu du projet RTAI). voila pour l'histoire du temps réel, j'aimerai bien que tu me donne les modifications noyau pour faire tourner mes applis

      merci

      Gilles

  • # dtyj

    Posté par  (site web personnel) . Évalué à 2.

    Ce que tu décris est le comportement de threads "user". Je crois que linux implémente le comportement attendu depuis l'écriture de la nouvelle lib de thread de Red Hat dont j'ai oublier le nom (NKT ?).

    sinon, comme dis au dessus, tu as peut-être choisis un mauvais comportement de scheduling pour ton thread principal qui garde toujours la main.

    "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.