Temps réel avec le noyau Linux

• # Re: Temps réel avec le noyau Linux

  Posté par the_freeman le 03 août 2003 à 20:02. Évalué à 8.

  

  <pub>
  Toujours au sujet du temps réel, il y a un article, d'un assez bon niveau, à ce sujet dans le Linux Mag' de ce mois-ci (enfin celui de Juillet/Aout), cf la news au sujet de sa sortie: http://linuxfr.org/2003/07/03/13137.html(...)
  </pub>

  • [^] # Re: Temps réel avec le noyau Linux

    Posté par let antibarbie = xp <- xp - 1 le 03 août 2003 à 23:58. Évalué à 2.

    

    Cet article est ptet un bon point de départ sur le RT-linux, parceque bon.. question documentation du linux temps réel c'est niet peau d'zébu.. et quand on trouve quelques documents ils datent... de très longtemps... ne sont pas maintenus.. et s'appliquent pour la plupart au noyo 2.2 *sic* (bon ok, depuis l'an dernier où j'avais fait ce triste constat, ça s'est ptet amélioré ?)
    
    ---
    Non aux votes en fonction de la moyenne des notes a nos précédents commentaires!

• # noyau flottant ??

  Posté par benja le 03 août 2003 à 21:56. Évalué à 6.

  

  Quel est l'intérêt d'utiliser les nombres flottants dans le noyau ?
  Theo de Raadt y est fermement opposé cf. http://www.monkey.org/openbsd/archive/tech/0305/msg00123.html(...)

  • [^] # Re: noyau flottant ??

    Posté par Loic Jaquemet le 04 août 2003 à 00:27. Évalué à 6.

    

    Ca c'est de l'argumentation clair, net et précise .. il est fort le Théo ...
    
    j'aime bien la réponse : http://www.monkey.org/openbsd/archive/tech/0305/msg00126.html(...)

  • [^] # Re: noyau flottant ??

    Posté par koopa le 04 août 2003 à 10:53. Évalué à 1.

    

    Pour un noyau non temps réel ca ne sert à rien : on fait tout tourner en mode user
    
    quand on fait des taches temps réels, elles tournent en mode noyau
    or très souvent ces processus font des calculs scientifiques (exemple un apparail de control et de mesure) alors on est bien content de pouvoir utiliser les nombres flottants.

  • [^] # Re: noyau flottant ??

    Posté par gege (site web personnel) le 04 août 2003 à 10:57. Évalué à 1.

    

    L'interet vient du fait que pour le moment toutes les implémentations temps-réel de linux (RTAI, mais aussi RTLinux http://www.fsmlabs.com/,(...) Montavista linux http://www.mvista.com/,(...) BlueCat http://www.lynuxworks.com/(...) ...) obligent à développer des modules kernel. C'est surement regrettable (en effet, il n'y a que les handlers d'IT qui ont un réel besoin d'être au niveau noyau), mais c'est comme ça.
    
    Donc si on veut faire du commande/controle sur des systèmes réels, il faut bien utiliser les flottants dans le noyau (avec les inconvénients évoqués par de Raadt).
    
    Les solutions actuelles offrent des moyens de communiquer facilement entre le monde temps-réel et le monde linux normal pour y déporter une partie des traitements (fifos, shared memory...), mais dans tous les cas on perd l'aspect temps réel (donc utilisé simplement pour du log, des actions asynchrones...).

    • [^] # Re: noyau flottant ??

      Posté par Nicolas Boulay (site web personnel) le 04 août 2003 à 13:30. Évalué à 1.

      

      Justement, dans l'article de lmag il explique que RTAI cherche à mieux déveloper le support d'application temps réel en user land.

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

• # Re: Temps réel avec le noyau Linux

  Posté par kb le 04 août 2003 à 03:31. Évalué à 1.

  

  Simple question: quelle est le temps de réponse maximum accepté pour qu'un OS soit considéré "temps réél" ?

  • [^] # Re: Temps réel avec le noyau Linux

    Posté par Jonathan ILIAS-PILLET (site web personnel) le 04 août 2003 à 05:23. Évalué à 8.

    

    Le temps de réponse attendu dépend des besoins. Et les besoins sont bien évidemment très hétérogènes... Pour rappel le temps réel ne signifie pas "le plus rapide" mais "au bon moment".
    
    Et à ce sujet, le temps de réponse est un critère presque moins important que le déterminisme. On cherche en général les durées moyennes et max pour les primitives utilisées, le temps de réponse des interruptions, le changement de contexte, etc...

  • [^] # Re: Temps réel avec le noyau Linux

    Posté par fleny68 le 04 août 2003 à 08:05. Évalué à 2.

    

    Pour être temps réel, le temps de réponse doit surtout être garanti; C'est là toute la difficulté.
    Si tu prends un système quelconque qui réponds en 1us dans 99 % du temps, ce n'est pas du temps réel.

  • [^] # Re: Temps réel avec le noyau Linux

    Posté par xavier philippon le 04 août 2003 à 08:50. Évalué à 6.

    

    Pour compléter les autres réponses :
    En plus d'être déternimiste, le temps de réponse doit être en rapport avec le processus que l'on contrôle.
    Pour réguler la température d'un batiment, un temps de réponse d'une minute permet de faire du temps réel. Une Clim auto sur une voiture, a un temps de réponse d'une dixaine de seconde.
    Dans certain cas, le fait dêtre trop rapide, peu poser des problèmes.
    Un assevissement trop rapide, ne peut pas controler un processus trop lent, on arrive facilement à un phénomène de pompage.
    L'armée américaine a perdu un proto d'avion, YF22 ou YF23, comme ça. Le pilote a mis son zinc dans une config, basse vitesse, où la trajectoire réagissait plusieurs secondes après l'action sur les gouvernes. L'avion c'est mis a faire un mouvement de montagne russe et le pilote a du s'ejecter !
    Si quelqu'un retrouve la video, je suis preneur.

    • [^] # Re: Temps réel avec le noyau Linux

      Posté par Dugland Bob le 04 août 2003 à 09:23. Évalué à 1.

      

      Un autre exemple classique est le contrôle de température dans les fonderies, le temps de réponse du process est de l'ordre de la demi-heure, on est donc pas stressé par la vitesse. Par contre on répond dans la demi-heure, pas dans les 2 heures !

• # solution module noyau

  Posté par free2.org le 04 août 2003 à 10:27. Évalué à 1.

  

  une solution peu évoquée pour faire du temps réeel sous linux est de faire son propre module noyau (y'a des documents assez simples pour les débutants). en effet un module accapare tout le CPU, notamment à chaque fois qu'on le charge. c'est alors lui le maitre de la machine, et s'il est correctement programmé il doit pouvoir "garantir" un temps de réponse maximal.

  • [^] # Re: solution module noyau

    Posté par koopa le 04 août 2003 à 11:01. Évalué à 2.

    

    c'est vraiment une solution peu élégante
    
    et comment on fait si on a plusieurs taches temps réel de niveaux de priorités différentes ??

  • [^] # Re: solution module noyau

    Posté par un_brice (site web personnel) le 04 août 2003 à 11:39. Évalué à 2.

    

    Un premier problème est l'impossiblité d'utiliser la glibc, ou toute autre librairie (je sais même pas si il y a des fonctions permettant aux modules d'ouvrir un fichier). Toujours est-il que le fait de tout programmer au niveau du noyeau sappe l'interêt de la technique puisque les applications ne ressemblent plus à des applications GNU/Linux standards. À ce moment là, autant programer sur un vrai noyeau temps réel (y'en a des libres).
    D'ailleurs ça serait peut être pas si efficace paske la latence dépendrais de ce qui se passe ailleurs dans le noyeau. Et, sans pouvoir en être sur, je doute de la qualité de l'ordonanceur qui gère les diffèrents modules et du fait qu'il permette (par exemple) d'interrompre un module à n'importe quel moment pour lui substituer un module de priorité supèrieure (je crois pas qu'il gère la notion de priorité). Donc le système serais bloqué si le module est trop important.
    Après on peut faire on module qui se charge juste de ce qui est fortement contraint et comunique avec l'espace utilissateur pour le reste, mais ça reviendrais à réinventer la roue puisque des kits (dont RTAI) existent pour ça.
    
    Tout ces problèmes sont contournés par la solution retenue par certains projets (comme RTLinux si je confonds pas), à savoir ajouter un vrai ordonanceur temps réel qui se place "au dessus" du noyeau (pour cet ordonanceur, GNU/Linux est ses applications sont un process, de même que chaque application temps réel). Elle semble donc bien avoir un interêt.
    Et RTAI aussi, qui intercepte certaines interruptions pour donner la main à ses applications temps réel quand elles ont lieu (dans l'optique de répondre rapidement à un périphèrique) (si j'ai bien compris).

    • [^] # Re: solution module noyau

      Posté par kicou le 04 août 2003 à 15:11. Évalué à 2.

      

      En parlant de RTOS Libre, le mieu et le plus complet que j'ai trouvé
      en GPL modifié (style LGPL) c'est RTEMS.
      Je sais pas si quelq'un a des retours dessus ?

      • [^] # Re: solution module noyau

        Posté par Nicolas Boulay (site web personnel) le 05 août 2003 à 10:51. Évalué à 1.

        

        Si j'ai bien compris, c'est très utilisé même dans l'industrie mais c'est un peu moribon.
        
        eCos qui appartient à Red Hat est repris par une boite anglaise et semble bien plus dynamique.

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

• # schedutils

  Posté par free2.org le 06 août 2003 à 17:02. Évalué à 1.

  

  je viens de faire
  apt-get install schedutils
  
  cela installe des programmes qui exploitent les APIs posix realtime avec lesquelles linux est compatible depuis longtemps (sans garantie de temps de réponse, mais avec la garantie que les process realtime seront toujours prioritaires avant les autres, ce que même nice --20 ne garantit pas)
  
  il est étonnant que les applications de gravage/musique/video n'utilisent pas (à ma connaissance) ces API

  • [^] # Re: schedutils

    Posté par free2.org le 07 août 2003 à 17:27. Évalué à 1.

    

    rectificatif: cdrecord et ses dérivés utilisent le realtime linux, je viens de le vérifier grace à schedutils

  • [^] # Re: schedutils

    Posté par grmbl le 19 août 2003 à 09:43. Évalué à 1.

    

    Ah bin voilà ce qu'il me fallait !
    J'ai effectivement pas besoin de temps réel dur, mais juste de m'assurrer que l'affichage ou le swap, par exemple ne soient en aucun cas prioritaires par raport à la diffusion audio.
    Je plussoie dès que possible.

Suivre le flux des commentaires

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