hum...

allez, le "membre eminent" passe le lien de l'article coecrit avec Pierre Ficheux : http://kadionik.developpez.com/cours/systeme/linux-temps-reel/

C'est en fait du TR mou, une notion d'informaticien qui assure plutot une qualite de service...
Le seul TR est le TR dur, celui de l'electronicien. Hein Sat 😉
Les patchs integres dans le noyau 2.6 sont ceux de R. Love et Morton. Ils ne permettent que du TR mou...
Le TR dur, ca sera peut etre pour le noyau 3.0. D'ailleurs Linus pense de plus en plus aux "hardeux" :
http://harded.free.fr/site/?p=62

C'est bon signe 😉

++

<edit>
oops : Sat, tu as ete le plus rapide ! Suis un peu moins incognito maintenant...
</edit>
dsl j'ai virer le mou 😛 (pitain de ctrl +z :-P) et j'ai pas fais gaffe!
Ah voila le lien que je cherchais! :
ccrma

Atrpms fait des modules pour ce kernel, mais fc5 pour l'instant! Le kernel me semble recompilé mais je ne sais pas comment il se situe au niveau du temps réel!
http://mirror.atrpms.net/ccrma/apt/fedora/5/i386/RPMS.planetccrma/

tu parles de blog nvidia? - c'est interressant ce que tu dis - mais j'avous ne pas toujours te suivre...

Comme je suis interressé de "maintenir collectivement" les drivers nvidia sur livna, ce sujet m'interresse...
(@Sat: mais je n'ai pas encore lu ton tuto sur mock sur ton site, ce qui me semble un préalable! Mais bon les personnes encore sous fc5 semblent patientes!)

@tankey Si tu as des liens sur ces patches temps réel du pilote nvidia?
@tankey
Je te cite :
"qui me donne 1 nanoseconde de temps de réponse ... (sur un duron 900mhz) C' est proprement fabuleux. )"
Tu t'exprimes mal...

Ce n'est pas la reponse de ton systeme donc le pire cas par exemple a une interruption (on mesure le temps entre l'occurence de l'interruption et le debut de traitement de l'ISR associee) qui est plutot de l'ordre de qq dizaines de µs...C'est ce temps de latence la qui est important.

Tu as en fait mesure la plus petite periode du timer hardware TR utilise, qui est de l'ordre de la µs et qui est ici normal et non extraordinaire...
Mais, bon je vais pas faire un cours....du soir... 😉

++

PS : c'est pas mhz mais MHz...
Quand on écrit des cours aussi intéressants, on assume derrière 🙂
En parlant de Pierre Ficheux, j'ai hate de lire la suite de sa série dans GLMF.

@kwizart: Mock est très simple d'emploi, par contre c'est chiant de voir que la compil' a foiré au bout d'une certaine attente.
@kwizart

Bonne question, tres bonne question... en fait il faut recompiler le noyau ou du moins recuperer la configuration (le .config) du noyau FC...je regarde...et vous donne la reponse...


++
@Sat

Oui tu as raison...Restons modeste. J'ai tant de collegues "modestes "qui n'arrivent plus a passer les portes...😉

Oui, Pierre ecrit une serie interessante dans LM en ce moment...le courageux !
++
ha ben ce cours là était déjà dans mes petits papiers depuis mes premiers jours sous temps-réels 🙂 🙂 enchanté de faire la connaissance de l' auteur :lol:

et "chapeau bas, because c' est l' article le plus explicite, détaillé et très bien vulgariser que j' ai lu. (sur la 50aine de liens RT en stock dans mes bookmarks de user de base)
eddy33 wrote:Tu t'exprimes mal...
Ce n'est pas la reponse de ton systeme donc le pire cas par exemple a une interruption (on mesure le temps entre l'occurence de l'interruption et le debut de traitement de l'ISR associee) qui est plutot de l'ordre de qq dizaines de µs...C'est ce temps de latence la qui est important.
Tu as en fait mesure la plus petite periode du timer hardware TR utilise, qui est de l'ordre de la µs et qui est ici normal et non extraordinaire...
Mais, bon je vais pas faire un cours....du soir... 😉
Oui merci de la correction

pour le eptit programme, fait par une connaissance (je ne sais pas si je peux me permettre dire ami) de Suisse, de test, faites l' essai :

kernel normal (iens j ai même ps essayé !) mais ça devrait râler

kernel modifié RT mais sans dyntrick et tout le tralala (just option ful preempt après patchage, donc):
[root@3athing linux]# /home/username/Documents/prog-couriousous-burn-RT/Nouveau\ dossier/a.out
Clock resolution: 999848 nanoseconds
[root@3athing linux]#

kernel RT plein :
[root@3athing linux]# /home/username/Documents/prog-couriousous-burn-RT/Nouveau\ dossier/a.out
Clock resolution: 1 nanoseconds
[root@3athing linux]#
(avec un s, oui :-P )

celui ci est sympa parcequ' il ne brule pas vraiment le kernel, j' en ai un truc qui me fait freezer tout le système pendant 1/4h avant de cracher son résultat. Je voudrais bien voir l' vis des spécialistes sur le sujet sur lui ussi (mais bon vais pas abuser)
@tankey
enchante...

A la question : est-ce que le noyau de Fedora utilise les patchs pour du TR mou, la reponse est OUI...
Apres verification, dans la rubrique "Processor type and features", sous-rubrique "Preemption model", c'est l'option "Voluntary Kernel Preemption " qui est validee par defaut dans le noyau Fedora Core.

Je cite l'aide sous "make gconfig" :
Voluntary Kernel Preemption (Desktop) PREEMPT_VOLUNTARY

This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new
preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions,
at the cost of slighly lower throughput.
This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it
is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is
under load.

Select this if you are building a kernel for a desktop system.
Il y a aussi l'option "Preempt The Big Kernel Lock" de cochee : 
Preempt The Big Kernel Lock PREEMPT_BKL

This option reduces the latency of the kernel by making the big kernel lock preemptible.
Say Y here if you are building a kernel for a desktop system.
Say N if you are unsure.
Conclusion :
Le noyau FC est par defaut configure pour faire du Temps Reel mou.

De toute facon, ce ne coute rien de le valider et ca ameliore la Qualite de Service (pour le multimedia et le son).
Verifie sur le dernier noyau 2.6.18-1.2849.fc6 sous FC 6...

<edit>
@tankey
Je suis toujours dubitatif et tres resevre par les mesures faites par tous ces programmes logiciels de mesure de temps de latence...Je prefere sortir l'oscillo et l'emulateur pour cela.
</edit>


++
Salut

J'ai survolé votre discussion et j'avoue n'avoir rien compris 😃

Etant curieux, pourriez vous m'expliquer ce qu'est un kernel temps réel, a quoi ca sert ?

Je pense avoir compris le principe, traiter l'info des qu'elle arrive, pour du controle d'asservissments ou autre. Mais pourquoi n'utilise t'on pas toujours ce genre de kernels, quels en sont le limites ?

Merci de votre compassion pour un ptit noob tout perdu 😉

PS: si ma question n'a rien à fairelà , n'hesitez pas à me le signaler 😃

Merki
@+
Salut accarien,
Je te conseille de lire l'article sur Linux et le TR cite plus haut...tous est explique dedans...

++
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ù?