Sortie de RTAI 24.1.12

Posté par  . Modéré par Nÿco.
Étiquettes :
0
27
oct.
2003
Noyau
RTAI est un OS temps réel dur libre (GPL) qui fait tourner le noyau linux comme sa tâche de priorité la plus faible.

RTAI est un fork de RTLinux qui permet de s'affranchir des problèmes de licences liés à celui-ci.

L'originalité de ce projet est qu'il permet d'obtenir d'une machine un comportement temps réel dur (n'ayant rien à envier à ses concurrents propriétaires) tout en gardant le comportement temps partagé du noyau linux.

Note du modérateur : la version précédente datait du mars 2003 Les contributeurs se focalisent principalement sur le développement d'où des manques certains dans le maintien du site et de la documentation.
Ces inconvénients sont largement compensés par une liste de diffusion très réactive.

Une distribution RTAI se présenté sous la forme de patchs pour différentes version du noyau linux et des sources de RTAI lui-même.

Pour ceux qui connaissent RTLinux, RTAI permet en plus d'écrire des tâches temps réel dur dans l'espace utilisateur.

Aller plus loin

  • # temps réel dur ?

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Une bonne ame pour expliquer ce qu'est que le "temps réel dur" ?

    Merci.

    (des liens, c'est bon aussi)
    • [^] # Re: temps réel dur ?

      Posté par  . Évalué à -3.

      temps réel

      loc. m.
      [SYSTM] Abrégé en TR. Se dit d'un système devant répondre aux sollicitations de son environnement physique dans des délais précis, ou d'un système devant simuler le fonctionnement d'un autre système, à la même vitesse que ce dernier. Un modèle météorologique en temps réel serait complètement crétin pour prédire le temps !
      Le temps réel repose sur trois notions fondamentales : le parallélisme (multitâche pour exécuter un programme indépendamment de tout autre), le respect des échéances et le couplage des tâches (© LMI).
      Le temps réel est dit « mou » s'il a un temps de réponse de l'ordre de 0.5 secondes. Il est dit « dur » si ses délais sont plus courts. Voir aussi HRT, ROOM.
      Articles liés à celui-ci :
      à la volée BeOS CHILL clavarder doubleur eCos HRT IRTOS IVI jardiner MAP MGR netlag O OS/9 PDP-x PLV POSIX RSVP RTEMS RTP RTS SML Spox streaming TR visiophonie voxel
      Articles voisins :
      temporiser - temps d'accès
      - temps de réponse
      - temps inactif
      - temps partagé - TEOTWAWKI - TEP - térabit - téraflop - Téraflop Club


      http://tout-savoir.net/lexique.php?rub=definition&code=7416(...)
      • [^] #

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

        la différenciation doux/dur n'a rien à voir avec les temps utilisés.
        Un système temps-réel doux "fait de son mieux" pour répondre aux exigences des applications.
        Un système RT "dur" quand à lui *garanti* qu'il répondra dans les temps qu'on lui demande (pourvu qu'il soit d'accord avec les contraintes demandés).
        • [^] #

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

          Il est bien entendu qu'un système qui fait du swapping n'a aucun moyen de garantir quoi que ce soit. (ou alors seulement pour certaines tâches qui sont vérouillées en mémoire). En effet même si le système s'efforce de répondre dans les temps, il ne peut pas prévoir si une page est abscente de la RAM et qu'il faut perdre 10 ms pour aller la chercher sur le disque dur.
          • [^] # Re: Sortie de RTAI 24.1.12

            Posté par  . Évalué à 4.

            Même si le swap est placé sur un device à temps d'accès constant ne servant qu'à ça (type carte Flash) et que les algos de paging ont certaines caractéristiques connues ?
            Imaginons un petit appareil (genre machin ultra-portable pour jeunes branchouilles) comportant 16 Mo de DRAM rapide et 512 Mo de mémoire Flash utilisée comme ramdisk/pagefile... C'est réaliste ? C'est utile ?
            • [^] # Re: Sortie de RTAI 24.1.12

              Posté par  (site web personnel, Mastodon) . Évalué à 1.

              Dans ton cas, il n'y aura pas de swap : tout est dans la même mémoire.
            • [^] # Re: Sortie de RTAI 24.1.12

              Posté par  . Évalué à 1.

              La mémoire flash a une limite de ré-écritures, non ?
              • [^] # Re: Sortie de RTAI 24.1.12

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                Entre 100.000 et un million de cycles. Au-delà, certains bits commencent à se figer. Ce n'est pas très génant si:
                1 - c'est une carte mémoire amovible (SD Card, Memory Stick)
                2 - c'est un produit à faible potentiel de vie (un téléphone mobile est PRÉVU pour être changé au boût de deux ans, une limitation des cycles de vie de batterie le garantissant)
                3 - c'est une mémoire qui est rarement modifiée (BIOS d'une carte-mère d'un pc)
            • [^] # Re: Sortie de RTAI 24.1.12

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

              Pour du temps réel dur, ce genre de trucs est *très* difficile à gérer.

              Ne serait-ce que pour le cache du processeur, en général, on parle en WCET (Worst Case Execution Time), et le pire cas, c'est un défaut de page. Du coup, le calcul du pire cas pour un processeur avec cache est pire ou égal à celui d'un processeur sans cache.

              Sinon, il faut être capable de dire à l'avance si il va y avoir un défaut de page ou pas. Il y a des gens qui travaillent dessus (pour le cache instructions. Pour les données, c'est carrément infaisable), mais c'est un problème difficile.
              • [^] # Re: Sortie de RTAI 24.1.12

                Posté par  . Évalué à 1.

                Dans l'API linux, il y a moyen de demander au noyau de ne pas swapper les pages d'un processus...
                Donc c'est faisable (et facile) avec RTAI.
                De plus, dans un developpement RTAI, les traitements qui ont des besoins tres fort en terme de temps de latence (temps de reaction a une interruption) sont ecris comme des modules du noyau... donc la memoire qu'ils utilisent n'est pas swapee.

                C'est probablement la facon la plus simple (et la plus sure) de s'afranchir des problemes de swap... en contrepartie, les besoin en ressources doivent etre bien connus...
                • [^] # Re: Sortie de RTAI 24.1.12

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

                  Pour moi, un "page miss" n'est pas le fait d'aller chercher une page manquante mais qu'une référence de translation mémoire physique mémoire virtuel manque (VM). La plus part des cpu n'ont pas plus de 128 référence dans leur cache (en x86, une page == 4Ko la plus part du temps). Il y a donc une it pour modifier cela.

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

    • [^] # Re: temps réel dur ?

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

      Apres une rapide recherche google, voila ce que j'ai trouvé :

      Sommaire d'un chapitre d'un cours temps reel :
      http://www.rennes.supelec.fr/ren/perso/pchlique/tpsreel/acctr.htm(...)

      temps reel souple :
      http://www.rennes.supelec.fr/ren/perso/pchlique/tpsreel/trmou.htm(...)
      temps reel dur :
      http://www.rennes.supelec.fr/ren/perso/pchlique/tpsreel/trdur.htm(...)
    • [^] # Re: temps réel dur ?

      Posté par  . Évalué à 3.

      Y a-t-il une autre bonne âme bien renseignée pour expliquer dans quels domaines applicatifs le temps réel est utile ?

      Tout ce que je sais du sujet vient de la "propagande BeOS".

      Pour un poste de travail domestique classique, quels sont les avantages ?
      - vidéo plus fluide ?
      - traitement du son ? création musicale ?
      - jeux plus "multimédia" ?
      - applications bureautiques plus rapides ?
      - retour de l'être aimé, accroissement pénien, repousse des cheveux, chance aux jeux et aux examens ?

      BeOS le faisait il y a 20 ans !

      • [^] # Re: temps réel dur ?

        Posté par  . Évalué à 1.

        J'ai entendu parler des système embarqués...
        • [^] # Re: temps réel dur ?

          Posté par  . Évalué à 4.

          Effectivement, le temps réel est omnipresent dans l'industrie et plus particulièrement dans les systèmes embarqués. Ce qui signifie peu de mémoire, une consommation mesurée, et donc des perfos en deca de ce que vous avez sur vos bureaux ... ce qui oblige à bien optimiser son code. Je dirais même que seul le monde de la micro-informatique et des serveurs est épargné par le temps réel ...
          Quand on entend parler de "bourse en temps réel sur Internet", ca me fait rire ... y'a rien de temps réel là dedans.

          Dans le domaine des systèmes industriels régnent en maitres les OS propriétaires, les OS "maison", voire même pas d'OS du tout (chaque tâche est activée par une interruption). Mais Linux est en train de boulverser tout ce petit monde : pourquoi developper un OS "maison" quand on a les sources d'un OS tout fait, qui marche, il "suffit" de le rendre temps réel.

          Je pense qu'après les serveurs, c'est par l'embarqué que Linux se diffuse le plus largement.

          En ce qui concerne les sources d'infos, je conseille tout particulièrement :
          http://www.linuxdevices.com(...)
          (du PDA au gros Cluster, tous les Linux embarqués, avec des études de marchés très intéressantes, et un joli comparatif linux 2.4 / 2.6)

          http://www.enseirb.fr/~kadionik/(...)
          (Site d'un universitaire français, qui regorge de liens et de cours sur Linux, les systèmes embarqués, et ... Linux embarqué ! )

          Juste un précision sur RTAI : c'est effectivement un fork de RTlinux, mais qui est exempt du problème de brevet logiciel qui accable ce dernier ;-)

          JiM
          • [^] # Re: temps réel dur ?

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

            Patrice Kadionik est une référence dans ce domaine. Son site mériterait effectivement une plus grande publicité pour son contenu.
            Il ne faut pas oublier un autre bordelais, pionnier de Linux, Pierre Ficheux qui a écrit "Linux embarqué" publié chez Eyrolles.

            Grâce à eux, il existe une documentation de qualité en français sur le sujet.
      • [^] # Re: temps réel dur ?

        Posté par  . Évalué à 5.

        Pour le desktop c'est pas beaucoup utilisé, on trouve le temps réel dur dans les domaines suivant:

        - voiture (control des frein par exemple)
        - avion , fusée, sonde spatial,...etc
        - plus généralement des applications mettant en jeu la vie d'humains
        - systeme de control industriel (l'application qui control la loupe pour graver des processeurs,...etc
        - centraux telephonique, ... etc
      • [^] # Re: temps réel dur ?

        Posté par  . Évalué à 7.

        Les systemes temps reel sont presque exclusivement utilises dans l'industrie.
        On n'a rien a attendre en termes de performance pure par rapport a un systeme temps partage (au contraire...).
        L'interet d'un OS temps reel est qu'il te garantie les temps de reponse.
        Les contraintes d'un OS temps partage - linux, par exemple - sont pricipalement tournee vers l'agrement de l'utilisateur.
        Les contraintes d'un OS temps reel son quand a elle tournee vers le processus (au sens large) a controler.
        • [^] # Re: temps réel dur ?

          Posté par  . Évalué à -3.

          Les contraintes d'un OS temps reel son quand a elle tournee vers le processus (au sens large) a controler.

          C'est donc brevetable au sens rocardien du terme!
          ==>[]
          • [^] # Re: temps réel dur ?

            Posté par  . Évalué à 3.

            Non. Car le terme "processus" se rapporte non pas au processus industriel au sens large, mais au sens "tâche à accomplir" au sens général. Ce peut donc être le contrôle d'un processus matériel (peut être brevetable, et encore, dans ce cas d'utilisation précis, seulement), ou bien d'un autre processus logiciel.
        • [^] # Re: temps réel dur ?

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

          C'est la bonne définition en effet. La garantie d'effectuer une tâche dans le temps imparti n'est pas forcément synonyme de rapidité. Dans certains processus industriels, la seconde suffit et c'est encore du temps réel.
      • [^] # Re: temps réel dur ?

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

        Aux applications embarqué "dure", tout ce qui est multimédia peut être considérer comme du temps réel "mou".

        En effet, que xmms ferme son clapet en 800us au lieu de 300 ms, on s'en fout un peu. Par contre, qu'il est le hoquet parce que je secoue une fenètre (de mon window manager, hein...), ça c'est hors de question.

        Un logiciel temps réel se soucie plus d'une date limite dans le temps, que réellement la quantité de travail à faire. C'est la différence entre la bande passante et la latence, la quantité de travail et au bout de combien temps il sera fait.

        L'informatique d'aujourd'hui est plutot en "best effort". On fait au mieux. Ton serveur web est dessiné pour fournir en moyenne 30 requètes/sec. Il n'est pas fait pour garantir une réponse à toutes requètes en 10 ms. Cela pourrait être utile pour les jeux par exemple.

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

      • [^] # Re: temps réel dur ?

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

        Pour le bureau, tu n'en a pas grand chose à faire que ton système soit temps réel : Ce que tu veux, c'est que ça aille "le plus vite possible", pas pouvoir garantir des contraintes de temps précises. Il y a un minimun exigible pour que ça ai l'air fluide (essaye du temps partagé avec des tranches de 3 secondes pour voir ;-), mais ça n'est pas vraiment du "temps réel".

        Par contre, quand il s'agit de matériel, si tu as un capteur qui t'envoie une donnée toutes les 100 ms, si tu ne veux pas en rater une, il faut faire attention à ce que tu fais.
        • [^] # Re: temps réel dur ?

          Posté par  . Évalué à 2.

          Si je comprend bien, l'argument "temps réel" tellement mis en avant par Be-paixasoname-Inc. était du pipo ?

          BeOS le faisait il y a 20 ans !

          • [^] # Re: temps réel dur ?

            Posté par  . Évalué à 1.

            As tu essayé BeOS?
            Il y a des versions gratuites qui doivent encore se trouver (attention il faut avoir moins d'1Go de RAM à cause d'une limitation du noyau).

            Je ne sais pas sur quel argument marketing, tu es tombé, mais BeOS était très agréable d'utilisation:
            - le système était très fluide, on était quasiment jamais bloqué.
            - C'était l'installation (avec du matériel compatible malheureusement quand même assez limité) la plus facile et rapide que j'ai jamais vu.
            - le temps de boot était vraiment très rapide (10-20s me souvient plus exactement du chiffre) et le système utilisable juste après le démarrage.
            Alors quand on me parle du boot rapide de WindowsXP, je rigole.
            Ce qui me fait moins rire, c'est que Linux est encore plus lent à booter..
            Pourtant si BeOS l'a fait, c'est que c'est possible!!

            Le gros point faible était le peu d'application qui existait, ça l'a tué..
            • [^] # Re: temps réel dur ?

              Posté par  . Évalué à 1.

              la reactivité de l'interface n'a rien a voir avec le temps réel. C'est pas parcque tout est très fluide qu'on peu dire que c'est un système temps réel. La definition d'un OS RT est assez strict.
            • [^] # Re: temps réel dur ?

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

              QNX Neutrino, autant que je sache, est lui aussi un système dit "temps réel" qui boot extrèmement rapidement (moins de 15 secondes sur mon 450MHz à côté de moi). Il existe une verion de développement pour ceux qui veulent tester. (y'a même des packages Mozilla et Abiword)...

              Ces systèmes (Be, QNX) ont déjà un énorme avantage sur linux : une meilleure gestion vidéo et ce qui s'en suit (pas de quadruple transcodage de palette de couleurs, pas de gestion de polices à la c*n, pas de multiples systèmes de gestion du son,...). Mais ils n'ont pas été conçus pour être aussi versatile.
              Ce qui intéresse les fabricants, c'est que Linux embarqué ou Linux sur PC, les sdk sont franchement proches. Donc c'est autant de gagné en stadardisation et en temps de dev.

              Et puis, mine de rien, Linux est plus fiable que d'autres. Sendo l'a amèrement essayé : Linux lui ne tentera pas de te mettre un poignard dans le dos, c'est un partenaire FIABLE.
        • [^] # Re: temps réel dur ?

          Posté par  . Évalué à 2.

          Typiquement quand on lit des entrées physiques tout ou rien, c'est plutôt toutes les 10 ms (pooling).
          • [^] # Re: temps réel dur ?

            Posté par  . Évalué à 1.

            Typiquement quand on lit des entrées physiques tout ou rien, c'est plutôt toutes les 10 ms (pooling).

            C'est n'est pas du pooling (regroupement, mise en commun) mais du polling (interrogation régulière, attente active).
            Bon tu n'es pas le premier à confondre les deux (au moins pour l'orthographe).
      • [^] # Re: temps réel dur ?

        Posté par  . Évalué à 3.

        Exemple très concret pour nos amis parisiens: sur la ligne de métro 4, le délai d'attente avant le prochain métro est donné en temps réel. de sorte que lorsque ce compteur arrive à 00, le train est là. magique et sous linux.

        D'autres applications ? sans doute en labo pour calculer en combien de temps une réaction se produit après injection d'un produit, par exemple. Mais ce n'est qu'une supposition.

        Bien à vous

        plagiats
        • [^] # Re: temps réel dur ?

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

          Un autre exemple : dans l'aviation.
          De nombreux avions sont équipés s'un sytème "fly by wire" qui corrige en temps réel (il vaut mieux! :) les actions du pilote. Imaginons que le système reçoivent de nouvelles informations tous les 10e de secondes (valeur totalement arbitraire). Si l'avion commence à piquer du nez (-5°) il faut que le système corrige la trajectoire en bougeant les ailerons de +5°. Si le système ne répond pas dans le temps imparti alors il va recevoir à nouveau l'information -5° qu'il va corriger à nouveau. L'avion va donc se redresser de 5+5 soit 10°.
          C'est un exemple assez simpliste mais ça montre l'importance du temps réel "dur" dans certaines applications critiques.
      • [^] # Re: temps réel dur ?

        Posté par  . Évalué à 3.

        je peut te donner un exemple d'utilisation de RTLinux (meme principe que RTAI)

        http://linuxfr.org/comments/226351.html(...)

        l'interet du temps reel sur cet appli est de pouvoir garantir une precision de traitement au 1/24 sec, L'application d'un filtre necessite une precision à l'image près.

        donc une partie RTLinux qui s'occupe des fonctions critiques (recuperation du timecode, synchronisation du betacam, envoit des infos sur les filtres) et une partie moins sensible (GUI) qui est affiché/raffraichis quand la partie RTLinux se tourne les pouces.
      • [^] # Re: temps réel dur ?

        Posté par  . Évalué à 2.

        si tu veux recompiler ton noyau et que tu n'es pas pressé parce
        que tu as envie de regarder un divx pendant la compilation
        sur un p2@266MHz, il vaut mieux avoir un noyau "patché rt"
        pour garder la fluidité de l'action

        ps: par contre, il faut pas être pressé pour la ciompilation...
  • # Re: Sortie de RTAI 24.1.12

    Posté par  . Évalué à 7.

    J'espère que ce sera pas un fork RaTAI.

    =====[]=> (je vole, à travers)
  • # Restons français!

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

    A chaque fois que je lis temps-réel dur, je ne peux pas m'empêcher de tiquer.
    En français, ça ne veut pas dire grand chose, c'est juste une traduction malheureuse de hard real time.

    Je trouve que temps réel strict ou souple (pour soft real time) est plus parlant et compréhensible.
    Comme il est dit dans le commentaire http://linuxfr.org/comments/290325.html(...) le temps réel strict garantit un temps de réponse strictement défini et connu, tandis que le temps réel souple s'accorde plus de souplesse, et fait seulement de son mieux.
  • # Re: Sortie de RTAI 24.1.12

    Posté par  . Évalué à 2.

    Sans vouloir polémiquer (pas envie de lancer un troll mais de comprendre ) , si j ai bien compris un OS temps réel a pour principal (seul) par rapport a un OS tps partagé de *garantir* un temps de réponse . On comprend vite les enjeux dans l industrie ou dans les cas où une vie humaine est en jeu .

    C est cette garantie qui me gene , sachant que le noyau linux etant en GPL , rien n est *garantie* .

    Ok je vous arrete tout de suite , pas question de me redire qu une garantie de tps c est pas pareil qu une garantie de résultat . Mais ca pose le problème suivant .

    Avec un noyau TR proprio, un defaut de conception/effet de bord etc lorsqu'il entraine la perte du temps reel cause les memes pertes qu avec un noyau libre . Avec le noyau libre , l entreprise qui subit les pertes ne pourra se retourner vers personne . Alors qu'avec un noyau proprio elle pourra faire "jouer sa garantie" si je puis dire .

    Peux etre est ce que je me trompe et que dans la réalité un OS tps réel libre est interressant pour les entreprises developpants des OS temps reel où en utilisant . Mais comme il s agit souvant de situation où justement c est la garantie qui importe , je me demande simplement si avant de vouloir *garantir* du tps réel il ne serai pas meilleur de *garantir* un noyau tps partagé rapide et stable (pas de trolls là non plus , simplement qu il faut bien avoué que les entreprises préfèrent un *BSD à un Linux , car ils sont soit disant "plus stable" .)

    (Ps : si vous moinsé merci de me dire pkoi , ca m evitera de réessayer de demander des explication sur tel ou tel devellopement )
    • [^] # Re: Sortie de RTAI 24.1.12

      Posté par  . Évalué à 3.

      Le temps de réponse déterministe à une interruption ou à une commutation de tâche est garanti par conception de l'ordonnanceur de l'OS.
      Avec un OS open-source, tu peux t'assurer toi-même de l'agorithme d'ordonnancement utilisé, eventuellement le patcher ...

      Je en pense pas que le terme "garantie" s'applique ici en termes juridiques : je te vois mal coller un procès à un éditeur d'OS parce que ton air-bag ne s'est pas déclenché à temps ...
      C'est plus une caractéristique du produit, tout dépend de ce que tu en fais. Par exemple, un bête printf() ajouté pour débugger une fonction va complètement bousiller ton beau séquencement de tâches périodique à 10ms, OS temps réel ou pas.

      JiM
      • [^] # Re: Sortie de RTAI 24.1.12

        Posté par  . Évalué à 1.

        Je en pense pas que le terme "garantie" s'applique ici en termes juridiques : je te vois mal coller un procès à un éditeur d'OS parce que ton air-bag ne s'est pas déclenché à temps ...

        Je ne suis pas un specialiste du domaine, mais je pense que justement, un éditeur qui te vend un OS qui a des prétentions temps réel peut être attaqué en justice si son système ne repond pas aux exigence. En faisant ton choix, tu as regardé les caractéristiques de l'OS (temps de lantence...) en fonction de ton application.

        Quand t'achète une voiture, si on te dit qu'ell à 5 vitesses et qu'en fait, elle n'en n'a que 4, tu peux légitimement gueuler :)
        • [^] # Re: Sortie de RTAI 24.1.12

          Posté par  . Évalué à 2.

          Je suis d'accord.
          Celà dit, si les performances annoncées ne sont pas au rendez-vous tu vas vite t'en rendre compte, à condition que tes jeux de tests soient bien faits, evidemment. Mais il ne faut pas attendre un problème grave pour ca !
          Il y a quand même un minimum de validation et de tests qualité à faire avant de lâcher une application temps réel critique dans la nature. Les éditeurs le savent, et font attention à ce qu'ils annoncent (on n'est pas dans le domaine de l'OS bureautique avec écrans bleus ... d'aillleurs y'a pas toujours d'écran, juste un bon vieux terminal serie pour debugger)

          Donc, entre bencher un OS proprio, et bencher un OS libre dans les mêmes conditions que l'application à développer, je ne vois pas la différence. Sauf que si les resultats ne te plaisent pas, tu peux aller regarder comment ca marche dans le cas de l'OS libre. Pour le proprio, tu attends la prochaine release ...

          Un autre argument est le nombre d'architectures (processeurs) supportés. Un éditeur facturera très cher le portage de son OS sur un nouveau processeur, tandis qu'une bande d'enthousiastes peut porter linux et les extensions temps-réel sur n'importe quel CPU. Par exemple, le portage de µClinux sur le processeur reconfigurable MicroBlaze est en cours dans une université australienne. http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/(...)

          Je pense que la possibilité de trainer en justice un fournisseur n'a pas la même valeur que le fait de produire un système maitrisé dans sa totalité.

          JiM
          • [^] # Re: Sortie de RTAI 24.1.12

            Posté par  . Évalué à 1.

            Je me demandais si justement une entreprise ne préfèrerai pas passer par du proprio pour se decharger de la responsabilité en cas de prob . (mais en effet , dans tout les cas une appli temps reel se doit d'etre testé en long large et en travers .)

            Il me viens une seconde question , un peu plus personnelle : je travaille dans le milieu boursier (dans une salle des marchés en fait ) et on utilise beaucoup le terme "temps reel" mais pour des applis windows , donc forcement qui ne sont pas en temps réelles .

            Y a t il des modifications permettant de baisser le tps de latence sous les OS de crosoft , a la facon d'un patch kernel ? (je m attend pas a ce qu on me donne un patch , mais peut etre un noyau modifié pour windows . (ps il s agit d'une info en rapport avec le tps reel , pas reellement avec linux , inutile de moinser ;) )

            Je demande ca car a par essayer de faire fonctionné sous wine ces fameuses appli dites "tps reelles" , j ai pas trouvé grd chose pour améliorer la reactivité des produits ( quelques soucis avec GL T??? ;) )

            Si d autres personnes sont aussi confrontés a ce genre de soft (sois disant tps réel , mais sur des os loin de l etre) ...
        • [^] # Re: Sortie de RTAI 24.1.12

          Posté par  . Évalué à 1.

          Dans un systeme industriel, l'appli temps reel fait le plus souvent partie d'un systeme plus vaste (la partie soft d'un pilote automatique n'est q'un sous ensemble)... et c'est l'industriel qui s'engage sur le produit dans son ensemble... c'est a lui de faire les tests kivonbien... et c'est a lui de choisir l'OS temps reel kivabien...
    • [^] # Re: Sortie de RTAI 24.1.12

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

      Le fait que la GPL précise que les logiciels soumis à cette licence ne sont pas livrés avec une garantie ne signifie pas qu'ils ne fonctionnent pas (sinon personne ne pourrait lire ce message), mais simplement que l'utilisateur s'interdit de se retourner contre l'auteur du code en cause en cas de défaillance.

      Ainsi si un système temps réel devait ne pas répondre dans les temps prévus il serait impossible, sans violer la GPL de chercher des poux à Linus Torvalds, ou autre développeur du noyeau.

      Cependant ce que je comprends de la GPL m'incite à préciser que rien n'interdit à une entreprise de fournir une garantie sur un soft qu'elle distribue, si elle l'estime possible, en tant que service associé au logiciel distribué(et même de demander à ce titre une rémunération). Mais cette garantie n'engagera que cette entreprise, au titre d'un contrat séparé, et non l'ensemble de la communauté au titre de la GPL.
    • [^] # Re: Sortie de RTAI 24.1.12

      Posté par  . Évalué à 1.

      En general, les OS temps reels ont une conception beaucoup plus simple qu'un OS temps partage
      - linux gere des priorite variables pour que tous le monde soit servi
      - un ordonnanceur temps reel ne gere que des priorites statique ... beaucoup plus simple.

      Il y a une tres bonne explication a tous ca dans l'article de P.Ficheux :

      www.enseirb.fr/~kadionik/embedded/ linux_realtime/linux_realtime.pdf

Suivre le flux des commentaires

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