En fait le temps réel c'est une histoire d'échéance qui peut aller de la µs à quelques heures. La rapidité c'est bien mais ça ne suffit pas et ce n'est parfois qu'un petit supplément.
La règle c'est qu'une tâche doit être remplie avant l'échéance fixée par le cahier des charges, ça nécessite pour pouvoir garantir le respect de ces contraintes temps réel que ton système soit déterministe.
Après on fait la distinction entre le temps réel dur et mou, le premier ne tolére aucun dépassement même dans le cas le plus pire, le second tolérera pour certaines tâches non prioritaires, un certain dépassement des contraintes temporelles. P. ex. un pacemaker, ou un pilote automatique sera souvent géré par un temps réel dur, pas une sonde météo.
Pour un ordi personnel, le temps réel est assez contraignant car si tu lances une tâche de calculs intensive dont la deadline est prioritaire, ta station sera inutilisable, les tâches d'affichage étant souvent de moindre priorités. Après c'est une histoire de compromis entre confort utilisateur et performances. Je pense pas que le fait de sauter quelques frames de temps en temps puisse te déranger quand tu lis une vidéo lors d'une compilation, par contre ça fera chier un ingénieur du son/video etc ...
accarien wrote:pourquoi n'utilise t'on pas toujours ce genre de kernels, quels en sont le limites ?
sans paraphraser ce que déjà dit, on peut résumer la situation comme ceci :
un kernel Rt n' est PAS plus rapide qu' un kernel normal, faut tuer le troll de suite "ouahg je joue a WoW en temps-réel c' est plusss mieux ça va plusss vite" (le graphisme et l' affichage "temps-réel" n' ont vraiment tien à voir avec un kernel RT)
un kernel RT est synonyme de baisse de performances vue d' une manière globale. (au profit du choix fait précisément pour certaines tâches, par l' admin, par exemple le groupe audio dans PAM est accordé à l' accès RT)

Enfin ce choix n' est pas fait par défaut pour des raisons de sécurité. Pas question de faire tourner un serveur même en temps réel mou. (certains serveurs le sont, même en dur, mais pour des raisons et utilisations précises). En règle général il me semble que sur des os comme osX par exemple, c' est CoreAudio qui a un accès privilègié (temps réel mou néanmoins) et rien ni personne d' autres.

Mais là, nous parlons d' une frontière entre les contraintes de l' embarqué et le desktop. C' est à dire des bénéfices de l' évolution des travaux de quelques génies et comment les adapter avec une certaine sureté à nos desktop. Et force est de constater qu' entre la qualité du kernel Linux, le travil de l' équipe Molnar et les applications GNU "laud", ben on est en face d' un système qui roxorise les anus de mamans ours :-P (oups ) :-P

Bref, Linux, c' est l' avenir 🙂
pour du controle d'asservissments ou autre
oui, d' ailleurs la même connaissance suisse s' amuse avec ça :
http://angeliz.free.fr/electro/elec11.htm
ça à l' air de rien, vu comme ça... mais a regardé de plus près les contraintes exigés par le cahier des charges....
Pour le cas ccrma! ils parlent des patches d'Ingo Molnar.
voir ici
EDIT! Tiens c'est justement de lui que l'on parle!

Mais je ne trouve ni le kernel (qui semble avoir un autre nom?) ni des sources... ce qui est un peu limite!...
Tu as le liens pour le kernel-molnar? il faudrai qu'il soit conforme au régles de versionning du kernel fedora pour faire des kmod (quels qu'il soient) avec un minimum de facilités!
le kernel est dispo chez Molnar directement.
perso je préfère appliquer le patch, parceque je préfère sortir ma hache pour la compilation ! (rien à faire du spport firewire, j en ai pas... pas de cartes rj45 en 10000, pas de gadgets, pas de watchcards, pas besoin de toutes ces cartes graphx et surtout : pas d' acpi ! pas d' apm ! z' en veux pas ! etc etc etc... "mon" kernel fait 1454670 soit environ 1.46mo (c' est donc très loin d' un kernel par défaut qui approche 1.7mo, mais encore un peu au dessus du fameux 1.42)
-> Sir Molnar : donc chez lui directement, pour les patches comme pour le kernel précompilé (ça c' est nouveau)
http://people.redhat.com/mingo/realtime-preempt/
Merci pour vos reponses !

J'essayerai de lire le cours quand j'aurai un peu de temps 😉

Bonne journée (pas trop dure, ni trop mole) à tous ! 😃

@+
Travaux pratiques :
patchage du "driver" nvidia pour un kernel RT et Xen
http://www.nvnews.net/vbulletin/attachment.php?attachmentid=20801&d=1159874953
version du driver nvidia à patché : 9625
version du kernel testé : 2.6.18-rt3

ici le patch pour "driver" nvidia, pour un kernel RT 'seul' :
http://www.nvnews.net/vbulletin/attachment.php?attachmentid=20592&d=1159301176

ici les topics respectifs où on en cause :
http://www.nvnews.net/vbulletin/showthread.php?t=77597
http://www.nvnews.net/vbulletin/showthread.php?t=76935&page=2

quelqu' un pour dire comment adapter ceci 8-) à un
kernel 2.6.19-rc6 (attention, le support sata/pat bug dessus)
et driver 9629

?
Euh.. une petite question bête. Si je veux installer un noyaux temps réél sur ma fedora là, pour faire un peu de MAO, sans avoir à le recompiler, à l'instar de ce que faisait planet CCRMA à une époque, Je peux le trouver où?
Bah je pourrais pas regarder avant un petit momment mais je te conseille d'utiliser une version nvidia beta 9742 disponible sur mon site ou sur celui de livna...

Si cela marche bien il pourrait être envisageable de faire les modifications pour faire le kernel-rt-utiliser kmod nvidia!
(Dans mon cas cela peut être tres utilile pour convaincre mon père d'installer un fedora rt sur son pc orienté musique !!!)
Quels petits test fonctionnels sous x86_64 seulement! (pas réussi à le refaire sous i686 - investigations...)
http://kwizart.free.fr/fedora/6/testing/

Pas de souci avec le direct rendering chargement du module etc...maintenant pour l'utilité, il faut voir (j'ai pas de son sur mon périphérique de capture video... un test tuner tv pourrait être utilile... nb de frames perdus entre un kernel temps réel et non temps réel!)

@Noee désolé pas vu ton post!
Plus haut dans le fil je donne les liens du projet ccrma (pronomcer karma!)

Ah oui et vous pensez qu'il est possible de faire du kernel temps réel sur une plateforme via epia (orienté multimedia center avec une carte double tuner pci-express?! Noel approche mais le CN800 ?
@ kwizart :
:-D :-D8-) :pint:

clapclapclap

pour le nombres de frames perdues c' est "normal". essaye en passant le groupe video en accès tempsréel dans PAM, aussi en ajustant éventuellement ta config (et ne charge pas le module nvidiafb, c est une daube)
pour le problème de son dans ton périphériques de capture vidéos, je n' en sait fo**** rien. Certainement un bug du driver inclut dans cette version de kernel ? cela m' étonnerait que le kernel patché rt et le driver nvidia patché rt en soit la cause.

pour la plateforme via : oui, carrément.
néanmoins, au vue de l' utilisation que tu en décris, personnellement je ne le ferait pas. (les gains sur l' audio risquent de ne pas compenser les pertes de performances globales)

personnellement et humblement, dans le cas où on est pas électronicien, je ne conseillerai une telle configuration que pour un GROS ordi servant pour l' audio (alsa, serveur Jack, ardour, rosegarden, le midi)

pour PAM quelques précisions
(merci de bien vouloir m' excuser si ceci est redondant avec le wiki, je n' ai pas encore pu tout parcourir. en plus c' est un cp/cl d' une partie d' un tuto que j' ai écrit sur un autre site y a qq temps déjà)

le fichier limits.conf :

@audio - rtprio 99
@audio - nice -15
@audio - memlock 250000


->le symbole arobase précède le nom audio, il sera donc interprété comme le "groupe audio"
->Le symbole entre @audio et rtprio est "-" il désigne que nous voulons à la fois hard et soft.
->La première valeur est la plus important, elle désigne la priorité que l'on souhaite attribuer à ce groupe : 99 est un bon choix ici.
->La seconde valeur attribue le "nice", la commande usuelle pour attribuer une priorité dans l' ordonnancement des taches entre elles. Son vocabulaire va de -20 qui est la plus forte priorité, jusqu'à 19, la plus faible.
->La dernière valeur indique la mémoire vive à "réserver" pour cela : ici 250Mo.

Note : ces paramètres sont à ajuster en fonction de votre machine et de l'utilisation courante que vous en faites. Sur des plus grosses configurations, il est plus courant de placer le nice à -10 et la mémoire à 512000 (pour la mémoire une bonne valeur est une valeur 50% de la quantité disponible).
et bien sûr, vérifier que l' utilisateur soit bien dans le groupe audio
je dirais même (bien) plus
chapeau bas
😉

pour l' intérêt : avoir à la fois un système taillé pour le traitement du signal audionumérique, donc profiter à fond de Jack, Ardour, RoseGarden, Jamin (...) mais sans perdre le plaisir des "amor" de type Beryl ou une tite partie de Cube2 ( 😉 ) de Tremulous, de wesnoth ou de Glest : quant on a une carte nvidia
(et pas la chance d' avoir une des dernières cartes INTEL avec les drivers gpl)
en tout cas je vous remercie de l' accueil et sincèrement ça fait du bien de prendre une claque sur un forum.
Pas de souci avec le direct rendering chargement du module etc...maintenant pour l'utilité, il faut voir (j'ai pas de son sur mon périphérique de capture video... un test tuner tv pourrait être utilile... nb de frames perdus entre un kernel temps réel et non temps réel!)
En fait je parlais d'un test que je pourrais faire... je sais pas si je perds des frames pour l'instant...
Dans l'idée, cela serait un serveur...

Vraiment cela m'interresse tout à fait? donc a suivre...
Tu as réussit à l'intaller si tu es en x86_64 ?
je ne dispose que d un x86-32 donc pas possible d' essayer ton boulot comme cela
et j ai rien fait aujourdhui de mon côté, de plus.

je sens que je vais partir sur quelque chose de plus simple aussi, quitte à revenir à une version antérieur du blob et du kernel.
ce qui est drôle c' est que le nouveau blob n' est censé ne plus posé de problèmes sur un kernel-rt, alors que j' ai des soucis. Avec les anciens, peux de soucis ici !

si tu veux t' amuser à bruler le kernel RT, tu peux essayer
le script python de Molnar (toujours même adresse)
le programme appelé timing
et le programme posté ici sur le topic avec les problèmes de son de blz.
ce dernier, sur un vrai et full RT devrait affiché au pire 9 nanosecondes au mieux 1 nanoseconde (résultat ici sur mon pc)

évidemment ces programmes ne valent pas un oscillateur branché au c** du pc. Néanmoins ils permettent de se faire une idée correcte, non pas en standalone, mais par comparatif de diverses machines et solutions.
hum...

PRECICE TES CONDITIONS DE MESURE : tes mesures en ns correspondent a la mesure d'une periode d'un timer hard.
Ce qui ne correspond pas au temps de latence globale d'un systeme TR dur ou mou qui est de l'ordre de 10-20 us (par exemple entre l'occurence d'une interruption et le debut de son traitement dans l'ISR)...

Cela induit en erreur le lecteur qui va croire qu'avec du TR, il aura des temps de latence ns !

Seule la logique cablee (dans un FPGA) pourrait atteindre cette valeur (et encore...) en aucun cas pour l'instant une logique programmee...

++

PS : je ne degainerai pas mon oscillo 😉
PS : je ne degainerai pas mon oscillo wink
zuttt!!!!
:-P :-P :-D :lol:

merci encore eddy33, c' est un plaisir de te lire