Re: [HS] Temps reel [Re: horloge a la bourre]
J'ai trouvé cette définition sur Google (cf ci dessous avec la source), j'ai l'impression que chacun arrange la définition suivant ses besoins. En gros, il faut que le temps de réponse soit prédictible avec certitude quitte dans certains cas à ce que la réponse ne soit pas assurée. Il est demandé que la réactivité du système et son taux d'informations traitées soient constants. C'est le bazar dans les définition des systèmes temps réels on dirait mais la notion est intéressante. FB PS: Pour l'horloge, il n'y aurait pas un raté dans l'étalonnage du CPU au début tout simplement? Définition vue: Un système temps réel est un système -> qui interagit avec un environnement externe qui lui- même évolue avec le temps -> qui réalise certaines fonctionnalités en relation avec cet environnement -> qui exploite des ressources limitées Systèmes en temps réel Philippe Mabilleau Ing. Fonctionnalité d'un système temps réel Deux contraintes à vérifier pour qu 'un système temps réel soit fonctionnel Exactitude logique ( logical correctness ): sorties adéquates en fonction des entrées, assurant le comportement désiré pour le système suite à des événements et aux données communiquées Exactitude temporelle ( timeliness ): rencontre des contraintes temporelles. Les sorties sont présentées au bon moment GEI 455 Systèmes en temps réel Philippe Mabilleau Ing. Niveaux de contraintes temporelles: Souple (soft) : système dont la performance est dégradée mais sans engendrer des conséquences dramatiques si les contraintes temporelles ne sont pas rencontrées Sévère (hard) : système dont l'incapacité de rencontrer les contraintes temporelles cause la faute du système Ferme (firm) : contrainte sévère mais où une faible probabilité de manquer les limites temporelles peut être tolérée
Re: [HS] Temps reel [Re: horloge a la bourre]
> La bonne valeur est 70m/s, soit 70cm/ms. Euh, je me trompe peut-être, mais 70cm/ms != 70m/s 70m/s == 7000cm/s == 7cm/ms Bref, ce thread (dont je n'ai même pas suivi le sujet...) m'a l'air bourré de petites fautes de calcul, et on court au troll !! pgpTlLqzE3foh.pgp Description: PGP signature
Re: [HS] Temps reel [Re: horloge a la bourre]
On Fri, Nov 15, 2002 at 02:28:40PM +0100, Charles Goyard wrote: > Ainsi parlait Olivier Rioland : > > obstacle sur un TGV roulant à 250 km/h, 10 ms représente 40 m ! > > Euh... Non. Ton exemple donne du 4km/s, soit du 14400km/h. Imagine des > pilotes de Grand Prix qui font un tour de circuit en 2 secondes :) Attention: le TGV, il va vite; et il est silencieux (en fait, le son du TGV n'arrivera que longtemps après votre mort) :-) /Y
Re: [HS] Temps reel [Re: horloge a la bourre]
On Fri, Nov 15, 2002 at 02:08:28PM +0100, Olivier Rioland wrote: > Selon moi, c'est plutôt au niveau du temps de réponse : Pas mal, mais beaucoup trop vague. > Prenons le cas où un processus A est en train d'être > exécuter par la machine (une tâche de fond). Un événement > extérieur intervient devant lancer un processus B. Alors > il faut que le processus A cède la place au processus B en > un temps maximum connu (généralement une centaine de > micro-secondes, parfois moins) avec une tolérance minimum > (ex : le temps d'attente est supérieur à 1 ms dans > seulement 2% des cas). Non; si ton ABS fait un cycle toutes les 40us, le temps d'attente ne doit jamais être supérieur à 40us. Si dans 2% des cas (500 fois par secondes!) tu es à 1ms, il ne va pas falloir longtemps pour que tu t'arrêtes dans un mur. En fait, ton exemple est exactement l'opposé du temps réel: dans tout système Linux, quand j'appuie sur ma souris, je m'attend à ce que le click soit pris en compte dans les 50ms. Dans 5% des cas, ça peut prendre 500ms. Une fois par mois, ça prend plusieurs seconde (pasque je suis en train de swapper ou qqch dans le genre). Et dans le cas géneral, je n'ai pas de limite supérieure de temps. Donc, le "temps maximum" doit être effectivement connu, mais nettement plus précisément que ça... et dans le cas de l'ABS (ou du missile), le temps maximum doit être *garanti*. (Incidemment, il n'y a pas de temps de réponse "généralement" accepté à 100 micro-secondes: ça dépend entièrement de ce que tu fais). > Sous linux, ce temps est de l'ordre de 10 ms Comment tu mesures? La dernière fois que j'ai mesuré ça, j'avais un process qui attendait un signal sur une entrée d'interruption; quand le process se reveillait, il changeait l'état d'une sortie. Entre l'activation de l'entrée et le changement de la sortie, j'ai mesuré 100uS. Sur un strong-arm à 220MHz, donc pas une bête de course. > (correspondant à la fréquence moyenne d'arrivée d'infos de > la part d'un utilisateur humain quand il tape au clavier > très vite). Quel rapport entre la vitesse de frappe et le temps de réponse du système??!? Si je tape plus vite, il répond plus vite? Je pense que tu confonds des choses qui n'ont rien à voir, ou alors tu n'es pas clair. > Des OS temps réel existent pour plateforme intel, comme > par exemple QNX, mais ils sont chers. L'idée de proposer > un système temps réel basé sur le noyau Linux est donc > plutôt intéressante (je ne connais cependant pas de cas > concrets où ça a été utilisé). En général, pour faire du temps réel, il vaut mieux ne pas utiliser une plateforme Intel (basé sur *86), car l'architecture rend l'evaluation du temps de réponse presque impossible (les instructions ne prennent pas toutes le même temps d'execution; certaines peuvent durer des éternités quand on commence à faire des rep; si je me souviens bien, toutes les interruptions n'arrivent pas à la même vitesse non plus). Cela dit, eCos par exemple est gratuit, se trouve qq part sur www.redhat.com (pas taper -- RedHat fait aussi de très bonnes choses dans le domaine de l'embarqué, c'est juste leur distribution qui n'est pas très bonne ;-) ). /Y
Re: [HS] Temps reel [Re: horloge a la bourre]
>> OK, alors qu'est ce qui _est_ temps-réel ? >Un système temps réel exécute une tâche en un temps connu et toujours le même. >Ce qui n'est pas le cas avec un Unix "standard"... Et quand je dis "tâche", >c'est au sens "processus", dans le noyau. Pas un calcul ou un programme qui >est un ensemble de tâches multiples ! (bien qu'au final, ça puisse revenir au >même...) En fait le besoin est de reagir a un evenement exterieur asynchrone. Il faut donc pouvoir arreter toute tache en cours pour traiter un evenement plus prioritaire, et cette reaction doit etre immediate, dans le referentiel de temps absolu, et non dans le referentiel de temps d'un processus au sein d'une machine multi-processus. La reaction ne peut etre dependante du bon vouloir du scheduler, donc. Un peu comme si le processus etait effectivement seul sur la machine. D'ou la notion de "temps-reel" par rappport a "temps relatif". La reaction elle-meme peut etre longue, ou courte, c'est relatif. Mais elle doit traiter l'evenement avant qu'il devienne obsolete, quelle que soit la notion d'obsolescence dans le domaine traite. Quant a Linux preemptif depuis recemment il faut preciser : Linux comme tous les unix est preemptif depuis les origines. Par contre le noyau n'est preemptable que depuis recemment, et seulement si on veut. Ca veut dire que certaines operations du noyau qui jusqu'a present etaient jugees atomiques et donc ininterruptibles, on ete declarees interruptibles sous certaines conditions de conservation de l'atomicite. Ce qui a necessite notamment la creation de verrous speciaux. A noter que le noyau OpenVMS est preemptable depuis belle lurette. Fab. * Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. *
Re: [HS] Temps reel [Re: horloge a la bourre]
Ainsi parlait Olivier Rioland : > obstacle sur un TGV roulant à 250 km/h, 10 ms représente 40 m ! Euh... Non. Ton exemple donne du 4km/s, soit du 14400km/h. Imagine des pilotes de Grand Prix qui font un tour de circuit en 2 secondes :) La bonne valeur est 70m/s, soit 70cm/ms. -- Charles, en combi anti-G
Re: [HS] Temps reel [Re: horloge a la bourre]
En réponse à Didier Chalm <[EMAIL PROTECTED]>: > > On Friday 15 November 2002 13:27, Georges Mariano wrote: > > > OK, alors qu'est ce qui _est_ temps-réel ? > > Ma définition personnelle à moi que j'ai : > > Un système temps réel exécute une tâche en un temps connu et toujours le > même. Selon moi, c'est plutôt au niveau du temps de réponse : Prenons le cas où un processus A est en train d'être exécuter par la machine (une tâche de fond). Un événement extérieur intervient devant lancer un processus B. Alors il faut que le processus A cède la place au processus B en un temps maximum connu (généralement une centaine de micro-secondes, parfois moins) avec une tolérance minimum (ex : le temps d'attente est supérieur à 1 ms dans seulement 2% des cas). Sous linux, ce temps est de l'ordre de 10 ms (correspondant à la fréquence moyenne d'arrivée d'infos de la part d'un utilisateur humain quand il tape au clavier très vite). Un temps plus faible n'est pas humainement perceptible mais peut avoir des conséquences physiques désastreuses (ex : pour la détection d'un obstacle sur un TGV roulant à 250 km/h, 10 ms représente 40 m ! S'il faut arrêter le train, on est souvent à 40 m près ...). Un temps de réponse trop bas pourrait être rassurant, mais ça diminue de façon notable les performances du micro-processeur. Des OS temps réel existent pour plateforme intel, comme par exemple QNX, mais ils sont chers. L'idée de proposer un système temps réel basé sur le noyau Linux est donc plutôt intéressante (je ne connais cependant pas de cas concrets où ça a été utilisé). Olivier
Re: [HS] Temps reel [Re: horloge a la bourre]
On Fri, Nov 15, 2002 at 01:27:50PM +0100, Georges Mariano wrote: > OK, alors qu'est ce qui _est_ temps-réel ? Vaste question :-) Un système temps-réel "dur" (Hard real time) est un système qui doit garantir un temps de réponse. S'il faut donner une commande à ton ABS toutes les 50ms, il faut garantir que la commande soit là. En général, ces systèmes sont nécessaires pour tout ce qui bouge. Le temps-réel "mou" (Soft real time) suit la même idée, mais rater une réponse n'est pas fatal (Suivant les systèmes, "rater" ne veut pas dire la même chose: pour certains, on peut se permettre de "sauter" une sortie, pour d'autres on peut se permettre d'arriver en retard). Exemple du premier type: Tu décodes du MPEG que tu affiches sur un écran. Idéalement, tu veux donner 25 trames par secondes à l'écran. Si tu rates une trame, il est acceptable de la sauter (et de répeter la dernière trame). Dans ce cas, arriver en retard ne sert à rien: l'écran ne t'attend pas, donc passé la limite de temps, on peut aussi bien laisser tomber le décodage qu'on était en train de faire. Exemple du second type: Un système de détection incendie doit faire sonner les sirènes dans les 5s après qu'un détecteur a detecté un feu. C'est la norme qui le dit. Mais si tu le fais après 6s, le système marche quane même, et est quand même utile (tu as une seconde de moins pour paniquer). (Bon, et tu rates la certification de ton matériel, mais c'est une autre histoire). Il y a bien entendu des combinaisons entre tout ça: des systèmes où certaines choses sont temps réel "dur" mais d'autres non. D'où l'interêt de RTLinux ou RTAI: on fait le temps-réel dur correctement (en dehors de Linux), et on utilise Linux pour le reste (stocker des choses sur disque, parler au réseau etc). De façon génerale, les OS "normaux" (Linux, Windows etc) ne sont pas temps-réel "dur"; on peut les utiliser pour du temps-réel mou si on fait attention à avoir une charge processeur connue et deterministe (Et même comme ça, c'est pas idéal: quand tu fais un read() sur un fichier, tu ne sais pas combien de temps ça va prendre, et il n'y a pas de façon simple de dire "fait un read, mais laisse tomber si ça prend plus de 500ms". On peut le faire en fork-ant avant de faire le read, avec le deuxième process qui attend 500ms puis interrompt le processus qui fait le read... c'est un peu bordélique et pas efficace.) . Pour faire du temps-réel dur, il faut utiliser d'autres noyaux tels que VxWorks (sans doute le plus connu), eCos, RTLinux, Nucleus... En général, ces OS ont un paramètre supplémentaire à leurs appels systèmes: read( fd, buffer, size, timeout )... Voilà voilà. J'espère avoir été raisonnablement clair :-) /Y
Re: [HS] Temps reel [Re: horloge a la bourre]
On Friday 15 November 2002 13:27, Georges Mariano wrote: > OK, alors qu'est ce qui _est_ temps-réel ? Ma définition personnelle à moi que j'ai : Un système temps réel exécute une tâche en un temps connu et toujours le même. Ce qui n'est pas le cas avec un Unix "standard"... Et quand je dis "tâche", c'est au sens "processus", dans le noyau. Pas un calcul ou un programme qui est un ensemble de tâches multiples ! (bien qu'au final, ça puisse revenir au même...) Le débat est lancé ! ;-) -- [EMAIL PROTECTED] EPSHOM Service Informatique BREST - FRANCE
Re: [HS] Temps reel [Re: horloge a la bourre]
On Fri, 15 Nov 2002 12:11:02 + Yves Rutschle <[EMAIL PROTECTED]> wrote: > Ça améliore le temps de réaction du noyau, ça ne le rend pas > temps-réel. > sera aussi. Ce qui donnera de meilleurs temps de réponse, > mais ne le rendra pas temps-réel. OK, alors qu'est ce qui _est_ temps-réel ? (pour ma culture générale ;-) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
