Re: Temps réel avec le noyau Linux

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

  Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 03/08/2003 à 21:58. (lien). É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 ??

• [^]Re: noyau flottant ??

  Posté par Loic Jaquemet (page perso, ) le 03/08/2003 à 22:27. (lien). É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/08/2003 à 08:53. (lien). É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 (page perso, ) le 04/08/2003 à 08:57. (lien). É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 () le 04/08/2003 à 11:30. (lien). É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.

Re: Temps réel avec le noyau Linux

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

  Posté par Jonathan ILIAS (Jabber id, page perso, ) le 04/08/2003 à 03:23. (lien). É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/08/2003 à 06:05. (lien). É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.

  --
  Non, rien

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

  Posté par xavier philippon () le 04/08/2003 à 06:50. (lien). É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 (page perso, ) le 04/08/2003 à 07:23. (lien). É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

• [^]Re: solution module noyau

  Posté par koopa () le 04/08/2003 à 09:01. (lien). É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 Brice Arnould ( un_brice ) (page perso, ) le 04/08/2003 à 09:39. (lien). É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).

  --
  Respect à RMS.

  • [^]Re: solution module noyau

    Posté par kicou () le 04/08/2003 à 13:11. (lien). É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 () le 05/08/2003 à 08:51. (lien). É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.

schedutils

• [^]Re: schedutils

  Posté par free2.org (page perso, ) le 07/08/2003 à 15:27. (lien). É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 (page perso, ) le 19/08/2003 à 07:43. (lien). É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.