Temps réel ?????

[invitea4b4a777]

La bonne blague, je te signale que je n'ai fait que reprendre tes propres propos (POST #6):

Si tu reprennait mes propos DANS leur contexte, on pourrais discuté. Mais la, tu les sors du contexte et donc ils sont interpretable comme tu veux.

Je reprend mes propos (que tu as aussi repris):

De plus, et la tu as vraiment interet a te renseigner, un CPU est TOUJOURS a 100%.

Mais ce que tu as zapper et qui me semble important, c'est ca :

Ce que toi tu dit, c'est 100% du CPU pour une seul tache (100% du CPU dedié a cette tache) et ca je suis d'accord, on est rarement a 100% (si on est a 100%, on "bug").

et remarque que j'ai dit que j'etait d'accord avec ce point de vue.

Mais un CPU est toujours a 100%.

Je croit que c'est clair. Un CPU est toujours en cours d'utilisation, par divers applic et jamais en meme temps (ca implique un CPU parallele). Et un CPU est rarement utilisé constamment par une seul applic, parce que tu as deja l'OS qui va prendre des cycles. Et ton applic aussi, donc dans le meilleurs des cas, c'est 50% pour chacun. Mais 50% pour l'applic et 50% pour l'OS, ca fais 100% pour le CPU.

Tu peux constaté ca avec windows. Ouvre le taskman, va voir la courbe d'utilisation. Je pense qu'elle oscillera entre 5% et 80%. Mais si tu prend la liste des process et que tu additionne tout les pourcentage d'utilisation, tu tombera toujours sur 100%. Parce que quant il t'affiche la courbe, il omet le process "Systeme Idle Process", qui n'est pas pris en compte pour le calcul. Et pourquoi il n'est pas pris en compte ??? Parce que c'est justement ce process qui permet a l'OS d'etre multitache. Donc ne viens pas me dire qu'un CPU n'est pas a 100%. Il n'est pas a 100% pour une applic, ca d'accord, mais il est toujours a 100% pour tout les applic. Et c'est la que ca devient casse gueule, parce que quant tu fais un soft qui doit tourné en TR, tu doit aussi prendre en compte ce qui va tourné a coté de cette applic (l'OS, les drivers, les autres applic, etc...) pour savoir comment tu doit gere tes cycles.

Ecoute, soit tu donnes ta définition de l'OS temps réel (ou d'un système temps réel)

Je l'ai deja defini, c'est les systeme multitache. Mais bon, ca va faire la 3eme fois que je le dit. Alors je le redit, un OS TR n'existe pas, ce qui existe, c'est un OS mulitache. Sur ce, moi j'ai donné ma definition. J'attend la tienne.

Tu n'as visiblement pas la connaissance de la programmation temps réel, donc laisse tomber et écoute Jeremy.

Tu n'as visiblement pas la connaissance de la programmation tout court (qui est, quoi que tu dise, toujours sequencielle, meme dans la PoO ou l'evenementielle, et meme la prog TR), deja rien que ca. Après, on pourra discuté de temps reel (du point de vue de la programmation).

Et pour en finir une bonne fois pour tout, parce que je commence a en avoir marre d'etre pris pour un debutant, je suis informaticien, developpeur, je travail dans le domaine de la geomatique et je suis egalement le responsable du service informatique de ma boite (je parle du réseau, des machines, etc...). Alors venir me dire que je n'y connais rien, c'est un peu fort.
-----

[zoup1]

Je trouve que la discussion s'échauffe bien vite.
Vous n'êtes visiblement pas d'accord sur la définition d'un système temps réél.

Pour ma part, j'ai toujours appelé "temps réel" des choses qui correspondent à ce qu'annonce jeremy et monnoliv.
Une petit recherche via google me confirme d'ailleurs dans cette opinion.
Parmi les premiers liens de google:
http://www.enseirb.fr/~kadionik/embe...realtime2.html
http://www.lifl.fr/~boulet/formation...ysteme002.html

[inviteb865367f]

Je l'ai deja dit, mais je le redit, les OS Temps Réel n'existe pas.

Ce qui existe, c'est les OS :

monotache-monoutilisateur (DOS)
multitache-monoutilisateur (Mac, Win 9x, Win NT, Win 2k, Win XP), capacité TR du au multitache
multitache-multiutilisateur (win2k serveur, win2k3 serveur), capacité TR du au multitache

Le reste, c'est du marketing et de la fioriture.

Effectivement ça confirme l'ampleur du gouffre qui sépare nos points de vue.
Dans ce cas je te dis tout de suite que tu ne me convaincras pas .. et on ne te convaincra peut être pas non plus. Inutile de plomber la BDD du site, la définition du TR se trouve tres largement sur le web.

[invitea4b4a777]

Je trouve que la discussion s'échauffe bien vite.
Vous n'êtes visiblement pas d'accord sur la définition d'un système temps réél.

Pour ma part, j'ai toujours appelé "temps réel" des choses qui correspondent à ce qu'annonce jeremy et monnoliv.
Une petit recherche via google me confirme d'ailleurs dans cette opinion.
Parmi les premiers liens de google:
http://www.enseirb.fr/~kadionik/embe...realtime2.html
http://www.lifl.fr/~boulet/formation...ysteme002.html

Sans vouloir etre mechant, selon les documents, c'est plutot ma version qui est correct. Je cite le site :

La gestion du temps est l'un des problèmes majeurs des systèmes d'exploitation. La raison est simple : les système d'exploitation modernes sont tous multitâche, or ils utilisent du matériel basé sur des processeurs qui ne le sont pas, ce qui oblige le système à partager le temps du processeur entre les différentes tâches. Cette notion de partage implique une gestion du passage d'une tâche à l'autre qui est effectuée par un ensemble d'algorithmes appelé ordonnanceur (scheduler en anglais).

De plus, il est clairement dit qu'un CPU ne peut pas etre en temps reel :

or ils utilisent du matériel basé sur des processeurs qui ne le sont pas, ce qui oblige le système à partager le temps du processeur entre les différentes tâches

Si a partir de la , qqun maintient que le temps reel existe, c'est que qu'il n'a pas compris ce qu'implique ce "temps reel". J'ai jamais dit que le "temps reel" n'etait pas possible au niveau logiciel, j'ai simplement dit que le "temps reel" logiciel est un bluff, rien de plus.

D'ailleurs :

"Un système est dit temps réel lorsque l'information après acquisition et traitement reste encore pertinente".

C'est donc bien du bluff, puisque on joue sur le temps que ressent l'utilisateur.

Qu'est-ce qu'une information pertinente ?? C'est une info qui, meme après traitement, reste coherente par rapport au temps reel physique (qui est bien différent du temps reel CPU). Ca veux dire que tu peux mesurer le poid que fait un recipient en cours de remplissage, si et seulement si la mesure prend moins de temps que le remplissage lui meme (ou que le "pas" de remplissage, au gramme ou au kilo). Ce qui implique obligatoirement un CPU ayant une vitesse minimum. Je cite :

Ce qui signifie que dans le cas d'une information arrivant de façon régulière (sous forme d'une interruption périodique du système), les temps d'acquisition et de traitement doivent rester inférieurs à la période de rafraîchissement de cette information.

Maintenant, si on parle de temps de calcul (temps pris pour effectué un cycle), il faut que le temps maximum alloué pour effectué la mesure (le traitement informatique) soit superieur au temps minimum pris par le CPU pour effectué une instruction (si on imagine que la mesure ne necessite qu'une instruction, ce qui est loin d'etre le cas). Je cite :

Si cette durée est de l'ordre de la seconde (pour le contrôle d'une réaction chimique par exemple), il ne sert à rien d’avoir un système à base de Pentium IV ! Un simple processeur 8 bits du type micro-contrôleur Motorola 68HC11, Microchip PIC, Scenix, AVR... ou même un processeur 4 bits fera amplement l'affaire, ce qui permettra de minimiser les coûts sur des forts volumes de production.

Ca veux dire que si la mesure prend 10 instruction en code et qu'elle doit etre faite toute les 10 milliseconde, et bien il faut un CPU qui fonctionne a la frequence minimum de :

max temps par cycle : 10ms
nb instruction : 10
temps par instruction : 1ms
frequence CPU min : 1000cycle/1seconde = 1Khz (1'000 cycle par seconde). En l'occurence, un microcontroleur de type PIC ira très bien.

Et si on veux respecter le temps physique (celui qui est defini par la reaction mesurée) et bien on DOIT prendre un CPU de 1Khz, quelques soit la programmation derriere (celle de monnoliv ou la mienne). Parce que c'est la limite physique du CPU qui defini le temps reel. Bien sur, on peut overclocker les CPU, mais on ne fais que deplacer la limite physique, on ne la supprime pas. Par contre, si on multiplie les CPU, on peut y arrivé.

Donc j'ai raison, le temps reel logiciel n'est que du bluff, un argument marketing et de la fioriture, puisqu'il depend du materiel et pas du logiciel, meme si la methode de programmation (le langage, le developpeur), l'OS, les applic influencent les performance (plus ou moins proche de la limite physique).

Et je rappel juste un point important, la vitesse maximal est limitée par l'element ayant la vitesse la plus faible. Ca veux dire qu'on peut avoir un CPU de 10Ghz, si on as une RAM a 1hz, on ira pas bien vite. Mais ca ne veux pas dire que la RAM doit ABSOLUMENT etre a la frequence du CPU pour avoir les meilleurs performance. Si la RAM est utilisée tout les 10 cycles CPU, on peut se permettre d'avoir un rapport de 1 a 10 entre les vitesse de la RAM et du CPU. Mais faut etre sur qu'aucun cas ne prennent moins de 10 cycles, sinon, on as un ralentissement dû a la RAM qui est mal calibrée (ou le CPU).

[zoup1]

[QUOTE = le premier lien de tout à l'heure]
Un système temps réel n'est pas forcément plus rapide qu'un système à temps partagé. Il devra par contre satisfaire à des contraintes temporelles strictes, prévues à l'avance et imposées par le processus extérieur à contrôler. Une confusion classique est de mélanger temps réel et rapidité de calcul du système donc puissance du processeur (microprocesseur, micro-contrôleur, DSP). On entend souvent :


« Être temps réel, c'est avoir beaucoup de puissance : des MIPS voire des MFLOPS”


Ce n'est pas toujours vrai. En fait, être temps réel dans l'exemple donné précédemment, c'est être capable d'acquitter l'interruption périodique (moyennant un temps de latence d'acquittement d'interruption imposé par le matériel), traiter l'information et le signaler au niveau utilisateur (réveil d'une tâche ou libération d'un sémaphore) dans un temps inférieur au temps entre deux interruptions périodiques consécutives. On est donc lié à la contrainte de délai entre deux interruptions générées par le processus extérieur à contrôler.
[/QUOTE]
Que comprends tu as ce paragraphe que je mets en exergue ?

[monnoliv]

Un système temps réel est un système qui garantit l'execution d'une tâche en un temps donné (borne maximale de temps). Voilà pour moi, un début de définition, je viens de la pondre, donc elle peut être améliorée mais la philosophie est là. Le programme de réponse à un stimuli (externe ou interne) doit s'éxécuter en un temps donné borné et garanti par le système.
Un exemple: une caméra enregistre à 20 img/s, pour ne perdre aucune image, le traitement (stockage, calcul, ...) associé doit être inférieur à 1/20 de seconde. Et bien, tu peux retourner le problème comme tu veux, toi, tu ne garantiras JAMAIS qu'avec Windows, Linux, MAC OS ou autre tu arriveras à respecter ce temps. Même si tu as le dernier cri en processeur, ça fonctionnera peut-être dans 99.999% des cas, mais il restera une incertitude. Voir par exemple toutes les m... avec windows quand on programme un périphérique rapide, tel que l'USB2.0 en highspeed (qui ne fonctionne pas chez 80% des gens d'ailleurs, et sans qu'ils le sachent).
Un OS temps réel (voir def. ci-dessus) est fait pour te garantir le temps maximal que prendra la tâche.
M'enfin bon, je pense avoir compris ton point de vue et il apparait que tu n'a jamais eu à traiter un système temps réel. Quant au motif commercial, je vois pas ce que ça vient faire ici.

[inviteb865367f]

Son point de vue n'est pas tout à fait faux puisque un proc à 1hz ne résoudra probablement aucun problème de TR, m'enfin c'est pas la philosophie, et prétendre que W2k3 serveur est TR ....

Bref, tout ça en pensant à celui qui a posé la question au départ et en esperant qu'il ne soit pas trop embrouillé

[zoup1]

Un exemple: une caméra enregistre à 20 img/s, pour ne perdre aucune image, le traitement (stockage, calcul, ...) associé doit être inférieur à 1/20 de seconde. Et bien, tu peux retourner le problème comme tu veux, toi, tu ne garantiras JAMAIS qu'avec Windows, Linux, MAC OS ou autre tu arriveras à respecter ce temps.

Il se trouve que Mac OS est construit sur un noyau Mach avec un support Real Time

[inviteb865367f]

Oui à la base Mach est orienté TR, ca ne dit pas que Mac OS est TR.

[zoup1]

A vrai dire, je ne sais pas exactement ce que cela veut dire, j'ai vu qu'on pouvait utiliser différents types de threads avec différents types de prioritées dont une qui s'appelle realtime. Maintenant, je ne sais pas ce que cela veut dire précisément.

[inviteb865367f]

Je ne sais pas trop non plus, je pense qu'il doit pouvoir garantir à ces threads le TR en zappant les threads non TR. Par exemple si tu fait N cycle dans le thread TR et P cycle pour tous les autres thread non TR alors ton thread TR est TR.
Mais ce n'est pas que un problème d'ordonnanceur, il faut voir comment il se débrouille avec le reste. En théorie ca doit pouvoir marcher.

[invite25e646de]

rep josua_fr:

OK donc c'est bien ce que je pensais, il faut tenir compte de la vitesse du proc ainsi que du nombre de cycle par instruction( donc voir le codage en assambleur du programme!)....c'est bien cela?

Amicalement.

[invitea4b4a777]

Un système temps réel n'est pas forcément plus rapide qu'un système à temps partagé. Il devra par contre satisfaire à des contraintes temporelles strictes, prévues à l'avance et imposées par le processus extérieur à contrôler. Une confusion classique est de mélanger temps réel et rapidité de calcul du système donc puissance du processeur (microprocesseur, micro-contrôleur, DSP). On entend souvent :

« Être temps réel, c'est avoir beaucoup de puissance : des MIPS voire des MFLOPS”

Ce n'est pas toujours vrai. En fait, être temps réel dans l'exemple donné précédemment, c'est être capable d'acquitter l'interruption périodique (moyennant un temps de latence d'acquittement d'interruption imposé par le matériel), traiter l'information et le signaler au niveau utilisateur (réveil d'une tâche ou libération d'un sémaphore) dans un temps inférieur au temps entre deux interruptions périodiques consécutives. On est donc lié à la contrainte de délai entre deux interruptions générées par le processus extérieur à contrôler.

Que comprends tu as ce paragraphe que je mets en exergue ?

Je comprend qu'il faut simplement calibré le CPU en fonction de la tache. Et c'est le CPU qui fera que la tache est executé conformement au contrainte de temps. C'est ce que j'arrete pas de dire depuis le debut du fil. Si le CPU est mal calibré, on pourra pondre toutes les formes de codes, utilisé tout les trucs possible, on arrivera jamais a etre en temps reel (par rapport au temps de la mesure).

Prenons 2 exemple, une horloge et un systeme de mesure de reaction chimique. Le temps moyen necessaire a une horloge, c'est la seconde. Donc un CPU qui tourne a 3-4 hertz ira très bien (parce qu'il fait 3-4 operation a la seconde). Par contre, ce meme CPU sera inutilisable pour la mesure de la reaction chimique, parce que la reaction est inferieur a la seconde. Il faut donc un CPU qui soit capable de faire, aller, disons 10 instruction dans le laps de temps qui existe entre 2 reaction. Ca veux dire que si le delai entre les reaction est de l'ordre de la milliseconde, il faut un CPU qui soit au minimum de 1,01khz (et encore, la on arrive juste a placé 10 instruction entre les reaction, donc il faudrais arrivé a 1,5khz, histoire d'avoir 500 instruction de marge).

Mais vous remarquerez que les vitesse que je nomme sont des vitesse très faible en comparaison des CPU actuel. Donc il n'est nullement question de puissance astronomique (de MFLOPS), mais de puissance CPU par rapport a la tache qu'on veux lui faire faire. En fait, la vitesse du CPU est defini par la tache.

A partir de la, on peut legitimitement se posé la question : Pourquoi nos CPU actuel sont des monstre de puissance si on peut faire du TR sur un CPU de 1khz. Ben y a 2 choses. 1erement, il faut une vitesse minimum pour faire un certain nombre de tache dans un temps imparti (le problème du temps), mais le programmeur a aussi une grande influence. Moi je rigole toujours quant je vois des soft qui demande des machines de fous, alors que le meme type de soft tournait très bien sur des machines moins puissante. C'est aussi le problème des specification minimum. Quant j'entend MS me dire qu'il faut un PC de 400Mhz minimum pour faire tourné 2000 server, et que moi je le fais tourné sur un PPro 166, je me dit que la puissance c'est aussi un argument marketing.

prétendre que W2k3 serveur est TR ....

Alors la, faut que tu m'explique se que tu entend par "pretendre que w2k3 est temsp reel" ??? Moi je constate que w2k3 est multitache, donc capable de temps reel. Parce que comme on la vue, il y a plusieurs maniere de faire du temps reel, puisque en fait le temps reel depend de la maniere dont on va gerer l'enchainement des taches. Bon, bien sur, w2k3 n'est pas une reference, mais c'est tout de meme un OS qui permet de faire du temps reel (et remarque que je n'est pas du que w2k3 est un OS TR, mais un OS multitache qui permet le TR).

Un système temps réel est un système qui garantit l'execution d'une tâche en un temps donné (borne maximale de temps). Voilà pour moi, un début de définition, je viens de la pondre, donc elle peut être améliorée mais la philosophie est là. Le programme de réponse à un stimuli (externe ou interne) doit s'éxécuter en un temps donné borné et garanti par le système.

Je suis d'accord avec cette definition. Elle ne specifie rien en terme de langage, ni en terme de puissance CPU (a par l'imperatif de temps, qui depend du type de tache), ni en terme d'OS. Un systeme, ca peut etre un composant electronique dedié avec un soft specifique, pas forcement un OS usine a gaz comme windows ou linux (qui plante et qui est sujet aux virus aussi).

Un exemple: une caméra enregistre à 20 img/s, pour ne perdre aucune image, le traitement (stockage, calcul, ...) associé doit être inférieur à 1/20 de seconde. Et bien, tu peux retourner le problème comme tu veux, toi, tu ne garantiras JAMAIS qu'avec Windows, Linux, MAC OS ou autre tu arriveras à respecter ce temps. Même si tu as le dernier cri en processeur, ça fonctionnera peut-être dans 99.999% des cas, mais il restera une incertitude. Voir par exemple toutes les m... avec windows quand on programme un périphérique rapide, tel que l'USB2.0 en highspeed (qui ne fonctionne pas chez 80% des gens d'ailleurs, et sans qu'ils le sachent).

Ton exemple est parfait, il demontre bien que le TR ne depend pas de l'OS, mais du CPU. Puisque dans cet exemple, j'ai le choix entre utilisé un PC avec un OS grand public (win, linux, Mac OS) et donc d'avoir un CPU assez puissant (a cause de l'OS) ou utilisé un programme codé en assembleur (pour ne pas avoir a subir l'OS). D'autant plus que dans ton exemple, il faut un CPU qui tourne au minimum 20hz, ce qui n'est pas bien mechant.

La je te donne un petit truc en se qui concerne windows. Je suis d'accord que windows gere mal les taches, surtout si elle sont dans une priorité de base. Mais moi, je modifie souvent la priorité des applic, parce que j'ai justement pas envie d'attendre 3 plomb que windows veuille bien se bougé. Et le fait de changer la priorité se vois. L'applic va tout de suite mieux. Elle reagit mieux, elle prend moins de temps, etc... Par contre, le temps gagner sur une applic et perdu sur une autre. Je fais souvent ca avec wmplayer, parce que j'ai pas envie d'avoir de coupure dans mes MP3. Si toi tu developpe un petit soft qui recupere l'image de la webcam, ben s'il est trop lent a ton gout, monte sa priorité, et tu verra la difference. Et comme windows permet de changer les priorité, pour moi il permet le temps reel justement.

Et si jamais tu doute, il ne devient pas instable, en tout cas 2k et XP. Win9x c'est un autre problème.

M'enfin bon, je pense avoir compris ton point de vue et il apparait que tu n'a jamais eu à traiter un système temps réel.

Je t'interdit de me dire de quoi je suis capable ou pas. Tu ne sais pas ce que je fais (a titre privé ou professionnel), alors ne viens pas me dire que je n'ai jamais eu a traité un systeme temps reel.

Un exemple de programme que j'ai crée moi meme, sans demandé quoique ce soit a qqun, sans repiquer de code source sur le net. Les simulateur de vie artificiel. La aussi on as des problème de temps, parce que chaque individu est une tache a lui tout seul, et qu'on a une colonie d'invidu (donc plein de tache en parallele), et donc il faut gerer l'enchainement (en interne et vis-a-vis des autres applic aussi, faudrais pas faire planté le PC non plus). J'ai aussi developper un simulateur de circuit electronique numerique, et il y a aussi des problème de temps (temps pris par un composant pour changer de valeur, donc temps total dependant du nombre de circuit, donc de la "tache" simulé par le circuit). Et j'ai fais du harcodage (codage de logique directement avec des IC), donc je sais de quoi je parle quant je parle d'electronique numerique et de programmation.

Je te prie de garder tes reflexion pour toi.

Tu me semble avoir le discoure typique des informaticiens provenant du monde universitaire. Les mecs qui se la pete parce qu'il ont codé de l'IA, des reseaux de neurone, etc... C'est très joli tout ca, mais si tu ne connais pas la base (l'electronique, les languages de prog), ben tu peux faire toute l'IA que tu veux, elle ne marchera pas. Il n'y a rien de surprenant a savoir faire du C ou du Java. Mais parce que vous en fait de l'IA, alors ca vous autorise a vous prendre pour les dieux de l'informatique. Et bien non, parce que ton IA elle a repose sur divers composant logique ou phyisque. Et ben tout ces composant ont developpé par des gens comme moi (en se qui concerne les composant logique).

Tu peux etre PDG de la plus grosse boite, si tu ne respect pas tes employé, tu risque de faire faillite très vite.

[invitea4b4a777]

Quant au motif commercial, je vois pas ce que ça vient faire ici.

Ce que j'entendais par motif commercial, c'est par exemple toi qui va essaye de vendre un OS que tu appel TR a qqun, alors que le terme TR ne veux rien dire dans ce cas la, puisque si la personne a un CPU trop faible, le terme TR dans le nom de l'OS est trompeur. C'est ca pour moi l'argument marketing. Et en l'occurence, c'est un argument trompeur, puisque ton OS ne pourra pas etre TR.

C'est comme les jeux video de strategie en temps reel. Ca veux dire quoi ?? Simplement que c'est pas l'utilisateur qui declenche les cycles, c'est tout. Mais les doom like sont aussi en temps reel, pourtant on ne joue pas avec cet argument pour vendre un doom like, mais pour un jeu de strategie oui. C'est donc bien un argument marketing, le terme "Temps Reel", puisque il depend plus du matos que du programme. Mais ce qui est etonnant, c'est que les fabricant de matos n'ont pas le culot de dire qu'il font du matos temps reel, par contre, les fabricant de soft eux n'hesite pas a tromper les gens.

Je suis totalement contre ce genre de methode. 1erement, c'est de la publicité mensongere et c'est interdit. 2emement, ca donne une image fausse de ce qu'est l'informatique. Combien de fois, en tant que depanneur, j'entend les gens me dire que leur PC est lent. Mais un PC lent ca n'existe pas. La seul chose de lent qui existe, c'est l'OS. Et quant tu leur explique que des fois il faut attendre un peu pour que l'OS se stabilise (que se soit windows ou linux), ben ils comprenne pas. Mais très souvent, les problème viens de l'impatience de l'utilisateur qui va cliquer 36x sur le meme icone, donc lancé 36 fois la meme tache(et des informaticien le font aussi, ca ca me tue). Si toi tu trouve sympa de continué a leur donné de faux espoir, ben ce n'est pas très correct. Mais bon, chacun ces methodes.

[invitea4b4a777]

Et juste pour tordre le coup aux OS TR, DOS est capable de faire du temps reel. Si, et seulement si tout est gerer en interne par l'applic. DOS lui ne va rien gerer, mais il permet de faire tourné des applic ayant des imperatif temporelle. D'ailleurs, vaux mieux utilisé DOS que windows dans certain cas, parce que DOS est bcp plus leger que windows (en terme d'utilisation CPU). Et si DOS est classé dans les OS temps reel, faudra vraiment qu'on m'explique pourquoi.

[monnoliv]

il faut un CPU qui tourne au minimum 20hz, ce qui n'est pas bien mechant.

Moui, un peu plus quand même .

Je t'interdit de me dire de quoi je suis capable ou pas. Tu ne sais pas ce que je fais (a titre privé ou professionnel), alors ne viens pas me dire que je n'ai jamais eu a traité un systeme temps reel.

T'énerve pas, je dis ce que je veux, à toi de réagir en conséquence.

Tu me semble avoir le discoure typique des informaticiens provenant du monde universitaire. Les mecs qui se la pete parce qu'il ont codé de l'IA, des reseaux de neurone, etc...

A ton tour tu préjuges de ma formation et de mes activités.

Bon, je te ferais remarquer que je suis le seul à m'être risqué sur une définition du temps réel. Libre à toi d'en proposer une autre ou de l'améliorer. D'autre part, je ne mets pas en doute tes compétences informatiques en général.

DOS lui ne va rien gerer, mais il permet de faire tourné des applic ayant des imperatif temporelle.
Et si DOS est classé dans les OS temps reel, faudra vraiment qu'on m'explique pourquoi.

Ces deux phrases sont contradictoires pour moi.

[invitea4b4a777]

Moui, un peu plus quand même .

Je suis d'accord. Mais c'est dans cette ordre de grandeur (par rapport au Mhz ou au Ghz).

T'énerve pas, je dis ce que je veux, à toi de réagir en conséquence.

C'est vrai que je me suis un peu emporté. Mais ce qui m'enerve, c'est que l'informatique ne s'apprend pas, mais se pratique. On apprend bcp plus en cherchant soit meme des solutions qu'en appliquant des theorie tout prete dont on ne comprend pas les bases. J'entend par la qu'il n'existe aucune methode infaible en informatique. Et une solution que tu aura developper, qui marchera parfaitement, pourrait (je dit bien pourrait) etre remplacé par une autre solution. On le vois bien avec le temps reel, on il existe en tout cas 2 methode différente de gerer l'ordonnancement des taches (les interruption et les "flags").

A ton tour tu préjuges de ma formation et de mes activités.

Oui et je l'ai fais volontairement. Justement pour qu'on arrete de comparer nos formation et qu'on s'attache plus a la solution. j'entend par la que je connais des gens qui n'ont pas la formation d'informaticien et qui maitrise plus l'informatique que des informaticiens formé. Je precise juste que pour moi maitrisé l'informatique ne signifie pas reussire a surfé sur le net, mais deja a regler soit meme les problèmes qui surviennent quant on utilise un ordi.

Bon, je te ferais remarquer que je suis le seul à m'être risqué sur une définition du temps réel. Libre à toi d'en proposer une autre ou de l'améliorer.

Ben disons que pour moi, y a pas de definition du temps reel, a part ta definition qui me va bien :

Un système temps réel est un système qui garantit l'execution d'une tâche en un temps donné (borne maximale de temps). Voilà pour moi, un début de définition, je viens de la pondre, donc elle peut être améliorée mais la philosophie est là. Le programme de réponse à un stimuli (externe ou interne) doit s'éxécuter en un temps donné borné et garanti par le système.

Si je la trouve correct, c'est parce qu'elle ne defini rien du point de vu du codage (ni methode, ni langage). J'entend par la que tu ne defini que l'imperatif temporelle. Ce qui est logique si on parle de problème temporelle (l'ordronnancement des taches).

D'autre part, je ne mets pas en doute tes compétences informatiques en général.

Ben personnellement, c'est que j'ai ressenti. Mais maintenant qu'on a posé les choses, j'eviterais d'etre trop susceptible.

Ces deux phrases sont contradictoires pour moi.

Je me cite (pour qu'on soit d'accord sur l'interpretation que je fais) :

DOS lui ne va rien gerer, mais il permet de faire tourné des applic ayant des imperatif temporelle.

Pour moi, ca signifie simplement que DOS peut faire tourné tout type d'applicatif (quelques soit la tache effectué par cet applicatif). Si l'applicatif a des contrainte temporelle, c'est a l'applicatif de les gerer. DOS lui ne va rien faire, mais comme il permet a l'applicatif d'etre executé, il peut executé des applicatif qui eux sont en temps reel (ayant des imperatif temporelle). Je prend l'exemple (qui est mauvais, je le reconnais) de win95. Win95 repose sur un noyau DOS mais il permet de faire du multitache. En fait, en DOS (et en win95), le mutlitache est au niveau applicatif (c'est une application qui gere les tache, pas le systeme lui meme), alors que dans linux ou win2k, il est au niveau systeme.

C'est comme le TCPIP, qui en DOS est une application, mais en linux ou en win2k, fait partie integrante du systeme. C'est simplement une question de couche. Mais le TCIP de DOS ou de win2k fait exactement la meme chose dans les 2 OS, mais est gerer différent.

Et si DOS est classé dans les OS temps reel, faudra vraiment qu'on m'explique pourquoi.

Ben ca c'est plus un pic par rapport au OS TR. Parce que comme DOS peut faire tournée des applicatif TR, alors il est quelquepart lui aussi TR, donc il pourrait correspondre a ce que tu appel un OS TR. Mais DOS n'est pas temps reel (parce qu'il est monotache). Pourtant, on peut faire du temps reel avec. Alors ou se situe la limite ??? C'est ca qui me semble le plus important. Parce qu'on peut faire de l'applicatif temps reel, ou un OS TR (meme si pour moi, un OS TR n'existe pas, parce qu'il est forcement multitache).

Je sais pas comment exprimé ca clairement, mais pour moi, si on place le temps reel dans l'OS, c'est une question de simplicité (qui est parfaitement normal, un peu comme on la fais pour TCPIP entre DOS et Win2k-Linux). Parce qu'on peut aussi placer la gestion du temps reel dans un applicatif (TCPIP sous DOS). C'est donc plus une maniere de voir le traitement de l'information (ai-je un imperatif temporelle a respecté) que l'emplacement ou est traité cette information (OS ou applicatif). C'est aussi a cause des systeme dedié que je ne peux pas accepter qu'un OS soit temps reel, parce que dans les systemes dedié (j'entend dans les robots par exemple) on as pas d'OS a proprement parler, mais on est aussi en temps reel (on a aussi des imperatif temporelle a respecté).

En fait, c'est pas l'OS qui est temps reel, c'est la tache. Et une tache n'as pas forcement besoin d'un OS pour etre executé justement.

J'espere avoir été un peu plus clair (comprehensible).

[invite25e646de]

Bon! Excusez moi les gars ....mais la ca y est je suis completement paumer !!!!

Pouriez vous vous mettre d'accord et me donner une definition simple du temps reele?
Sur quel machine ( proc ou PIC), sur quelle OS, en fin toute les info pour faire duTR!
Et aussi avec quel langage (SVP ne zaper pas cette info, c'est important pour moi) ou si c'est uniquement avec de l'assambleur ?
Bref: Soyez sympas quoi !!!
D'avance merci.

[invitea4b4a777]

Pouriez vous vous mettre d'accord et me donner une definition simple du temps reele?

Personnellement, je te conseil de prendre cette definition (de monnoliv) :

Un système temps réel est un système qui garantit l'execution d'une tâche en un temps donné (borne maximale de temps). Voilà pour moi, un début de définition, je viens de la pondre, donc elle peut être améliorée mais la philosophie est là. Le programme de réponse à un stimuli (externe ou interne) doit s'éxécuter en un temps donné borné et garanti par le système.

Ca c'est la definition du concept "Temps reel" en informatique.

Sur quel machine ( proc ou PIC), sur quelle OS, en fin toute les info pour faire duTR!

Ben pour faire du temps reel, tu doit deja savoir le laps de temps que tu as a disposition pour faire tes operations. Ensuite, il faut que tu sache combien d'instruction tu as besoin pour effectué tes operation (une operation peut prendre plusieurs instruction CPU). Finalement, il faut que choississe un CPU qui a une vitesse suffisante pour executé les instruction dans le laps de temps imparti.

Et personnellement, si tu t'y connais bien en prog, je te conseil de meme pas passer par un OS, mais de programmer un soft qui marche tout seul. Qui puisse etre executé directement par le CPU. Comme ca, tu es sur d'avoir 100% du CPU pour toi, et tu n'as pas a te prendre la tete avec des taches executé en parallele. Mais si tu fais appel a des composant type réseau ou graphique, tu devra forcement passé par un OS et la, ben je prefere laissé la parole aux autre quant a te conseiller un OS. Parce qu'effectivement, windows n'est pas le meilleurs dans le domaine. Je serais tenté de dire linux, mais je suis sur qu'on trouve des OS qui gere mieux l'aspect "multitache" (genre OS provenant de l'armée, voir pourquoi pas l'OS amiga qui est l'un des plus robuste).

Et aussi avec quel langage (SVP ne zaper pas cette info, c'est important pour moi) ou si c'est uniquement avec de l'assambleur ?

L'assembleur peut etre une bonne solution, parce que tu ne rajoute pas de "fioriture" logique autour de tes insctructions. Et l'assembleur te permet de savoir precisément le nombre d'instruction que tu aura. C'est logique, puisque l'assembleur représente justement les instruction CPU. Donc si ton programme en C fais 10ligne, en assembleur il pourrais en faire 100. C'est donc les 100 lignes (d'assembleur) qu'il faut prendre en compte pour le calcul de la vitesse.

Mais programmer en assembleur n'as rien d'une sinecure. A ce prix, il vaux mieux prendre du C et programmer sans faire appel a des elements systeme (ne pas utilisé de librairie) externe au programme que tu crée, y compris les librairie fournit avec le RAD (outil de developpement), parce que tu aura besoin de ses librairie pour faire tourné ton soft, donc de les implementé dans le(s) composant qui feront tourné ton programme. S'il s'agit d'un PC, on peut se le permettre, y a assez de RAM pour tout le monde, mais si tu es sur un systeme embarqué (type PIC), tu as interet a limité la memoire utilisé par le soft parce que tu n'as pas des 100ene de mega a disposition (si t'as deja 32Mo, tu peux t'estimé heureux).

Mais en fait, il n'y a pas un langage mieux que les autres. Bien sur, il faut un langage compiler (par opposition au langage interpreté), mais tu peut le faire avec du pascal, du C, du fortran, du cobol, etc.... Je te conseil tout de meme de prendre un langage orienté objet, c'est plus puissant, mais tu peux y arrivé avec un langage type pascal (qui n'est pas, a ma connaissance, orienté objet. Mais j'y mettrait pas ma main au feu ).

[SPH]

Je programme et je vais essayer de te dire ce qu'est le temps réel.
Mieux, je vais te montrer ce qu'est du temps réel.
Télécharge ces 2 fichiers et met les sur le bureau (par exemple) :
http://xmas.free.fr/ghost

Tu remarqueras que plus il y a de pixels, plus ca rame. C'est parce que à chaque image, je calcul réellement la nouvelle coordonnée de CHAQUE point; ce qui est long. Ca c'est du temps réel.

Maintenant, j'aurais pu utiliser une technique opposée au "temps réel". Cela s'appelle du "précalculé". En effet, au lancement du programme, je pourrais ouvrir une grosse banque et calculer toutes les coordonnées de tous les points pour chaque images !!! On va dire que les calculs représente par exemple 40% du temps passé en temps réel. Et bien l'idéal pour "masquer" ce temps d'attente est d'afficher une image statique ou de faire un effet assez simple qui ne prend pas trop de temps processeur et pendant ce temps, ta banque se rempli de toutes les coordonnées. Quand c'est pret, tu n'affiches que des points et tu t'épargne le temps de calcul puisque tout est en banque.

Attention, le "temps réel" et le "précalculé" s'appliquent a de tres nombreux parametres et effets speciaux (pas seulement a des points...)
Egalement, n'importe quel language sait faire ca. Ca ne dépend pas du language mais du programmeur !

[monnoliv]

Ca n'a rien a voir avec le temps réel ce que tu écris (au sens de la définition que j'ai esquissée).

Maintenant, j'aurais pu utiliser une technique opposée au "temps réel". Cela s'appelle du "précalculé".

Ce que tu fais c'est utiliser une LUT (Look Up Table, rien à voir avec le TR)

Et bien l'idéal pour "masquer" ce temps d'attente est d'afficher une image statique ou de faire un effet assez simple qui ne prend pas trop de temps processeur et pendant ce temps, ta banque se rempli de toutes les coordonnées.

Et ça, ca s'appelle le Double Buffering (toujours rien à voir avec le TR)

Attention, le "temps réel" et le "précalculé" s'appliquent a de tres nombreux parametres et effets speciaux (pas seulement a des points...)
Egalement, n'importe quel language sait faire ca. Ca ne dépend pas du language mais du programmeur !

Ce sont des astuces pour aller plus vite et pour améliorer l'affichage.

A+

[SPH]

Ca n'a rien a voir avec le temps réel ce que tu écris (au sens de la définition que j'ai esquissée).

Je n'ai rien lu a part l'intitulé. Et j'ai donné la definition de ce qu'est pour moi le temps réel. Maintenant, c'est a l'auteur de ce sujet de puiser ce qu'il veux dans le post qui lui correspond le plus...

[invitea4b4a777]

Ca n'a rien a voir avec le temps réel ce que tu écris (au sens de la définition que j'ai esquissée).

Bien que je soit d'accord avec toi monnoliv, je dirais que c'est quant meme un problème de TR, puisque quant on fais du graphisme, on a l'imperatif d'avoir un visuel fluide (c'est un minimum), ce qui signifie affiché au minimum a 25 images/seconde (ca veux dire afficher 1 image en moins de 1/25 seconde, si on fais du graphisme statique).

La ou je te rejoint, c'est que cet imperatif temporel n'est pas defini par la tache (ce qui doit etre le cas si on parle de TR, selon ta definition, que j'admet parfaitement), mais par l'utilisateur. En fait, si on a un imperatif temporel, c'est parce que l'utilisateur veux avoir un visuel fluide, mais la tache elle meme (ce qu'on représente en affichant l'image) n'a pas forcement d'imperatif temporel. Si l'image affichée représente un paysage, on peut l'afficher en quelques seconde, puisque ca ne changera pas le paysage, mais l'utilisateur va devoir patienté (tant pis pour lui, il avait qu'a avoir un PC plus puissant). De meme si l'image représente une structure qui evolue au fil du temps, genre une analyse graphique d'un phenomene physique, on peut se permettre un leger ralentissement par rapport a l'affichage. Si la structure evolue toutes les 10secondes, on peut se permettre de prendre 9 seconde pour afficher l'image.

C'est comme les soft de 3D qui passe 8heure a compiler une anime de 30seconde. Si on veux avoir une anime fluide, on est obligé de passé par du precalculé, parce qu'on ne peut pas avoir la fluidité si on doit en plus calculer tout en meme temps. Le soft 3D ne peut donc pas etre considerer comme un soft temps reel, puisque il n'a pas d'imperatif temporel a respecté, il peut prendre le temps qu'il veux pour generé l'image (et l'afficher). C'est pour ca par exemple qu'une anime précalculée s'approche plus de la realité virtuel qu'une anime temps reel, parce qu'on diminue les effets sur une anime TR, pour pouvoir respecté l'imperatif temporel des 25 images /seconde. Il faut prendre moins de 1/25eme de seconde pour generé et affiché 1 seuls image pour que l'anim soit fluide (ce qui est mieux pour une anim), et la on est qu'a 25 FPS. Parce que quant on joue et qu'on est a 65 FPS, il reste encore moins de temps pour genere et affiché une image. A un moment, on arrive a la limite ou le jeu doit diminué les details pour continué a avoir le meme rythmes d'affichage (d'ou des différence de qualité pour un meme soft sur différente carte graphique).

Un autre exemple, les codec divx récent recalle l'image et le son en TR. En fait, ce qu'il font, c'est diminué la quantité de lignes affichée pour l'image afin que le PC puisse accelerer la video est recaller la voix et l'image. D'ailleurs ca se voit a l'oeil nu, il supprime une ligne sur 2 quant il commence a avoir de la peine (l'image devient plus sombre et moins precise). Ca c'est un soft TR, parce qu'il doit respecté le rythme de 25images/seconde.

Pour savoir si le soft de SPH est temps reel (cad s'il a un imperatif temporel a respecté), il faudrais savoir pourquoi le soft analyse TOUT les pixel et si cette analyse depend d'un imperatif temporel (pris de decision repetée en se basant sur l'image, par exemple). J'ai un ami qui a fais un soft qui est capable de detecté quel icone je pointe avec la souris, en se basant sur l'analyse du texte affiché sous l'icone. Le soft fait une transformation graphique (changement de couleur) pour faire ressortir le texte, puis compare le chablon fournit par l'analyse du texte avec une liste de texte connu (et en plus, il analyse les texte partiel). Il etait donc capable de savoir quel raccourci visait la souris sans passer par un quelconque composant windows (ce qui peut etre cool pour une IA). Bien que ce soft face de l'analyse graphique, il n'avais pas d'imperatif temporel a respecté et ne peut donc pas etre considerer comme un soft TR (meme si son cycle le fais penser).

Donc SPH, est ce que ton analyse graphique doit etre effectué en un temps minimum ??? Par exemple, est-ce que ton soft va prendre une decision a la fin de l'analyse ou est-ce qu'il fais juste l'analyse et retourne les resultats ?????

[SPH]

Donc SPH, est ce que ton analyse graphique doit etre effectué en un temps minimum ??? Par exemple, est-ce que ton soft va prendre une decision a la fin de l'analyse ou est-ce qu'il fais juste l'analyse et retourne les resultats ?????

Je n'utilise pas un soft, je programme directement pour intervenir comme je l'entend sur l'image. Donc, je programme selon ce que j'attend...
Juste une chose : si les softs commerciaux font ce que tu attend d'eux mais le font pendant des heures, je ne pourrais pas les battre ! Si c'est long, c'est que le traitement de l'image est complexe et on ne peux rien y faire...

[invitea4b4a777]

Je n'utilise pas un soft, je programme directement

A moins que tu face de l'assembleur, tu utilise un soft, meme si ce soft c'est toi qui la fait. Parce que programmer directement, ca veux dire crée les instruction CPU, et ca, a part faire tes propres circuit, c'est impossible. Y a pas de différence entre un soft commercial et un soft programmer par soit meme. Au finale, c'est de tout facon des bits qui sont executé par le CPU.

Donc, je programme selon ce que j'attend...

Justement, est-ce que tu as un imperatif temporel a respecter ????

Juste une chose : si les softs commerciaux font ce que tu attend d'eux mais le font pendant des heures, je ne pourrais pas les battre !

Ben si justement. Si tu trouve une methode qui permet d'avoir la meme qualité d'image en 10x moins de temps, je peux te dire que les studio hollywoodien vont te l'acheter, ton soft. Si tu peux crée une scene avec plein d'effet (lumiere, rayon, effet pyrothechnique, structure 3D hyperdetail (+1000 polygone par objet), etc...) et que tu peux affiché l'image en moins de 1/25eme, tu a crée un soft qui fait de l'anim TR et la, ben y a les majors du film (ca economise sur les temps de calcul) et du jeux video (ca permet un realisme plus poussé) qui vont venir te voir rapidement.

Si c'est long, c'est que le traitement de l'image est complexe et on ne peux rien y faire...

On peut toujours trouvé qqch a faire. Multiplié les CPU, comme 3DMax le permet (en utilisant un cluster de PC pour le calcul de l'image), multiplié les cartes graphique, voir justement utilisé le GPU d'une carte graphique plutot que le CPU lui-meme. Y a toujours un moyen, c'est ca la puissance de l'informatique.

Après faut evalué le cout d'investissement (matos + developpement) par rapport au benefice espéré (temps gagné).