le kernel fedora est déjà bien patcher pour le rendre temps réel. De plus, si je me souvient bien, le RT est proprio!
temps-réel et blob nvidia
- Modifié
En soi, le temps réel n'est pas libre ou proprio, RTLinux est une implémentation devenu proprio, pour du temps réels mou, il y a divers patchs, pour du temps réel dur: il y a RTAI et Xenomai qui utilise tout deux Adeos pour contourner les brevets de FSMLabs sur RTLinux.
Un membre éminent de cette assemblée a co-écrit un cours fort intéressant sur Linux en temps réel ou on présente RTLinux et RTAI.
Un membre éminent de cette assemblée a co-écrit un cours fort intéressant sur Linux en temps réel ou on présente RTLinux et RTAI.
blob nvidia?
Quel est l'utilité d'un kernel temps reel. Il me semble d'atrpms en a fait un en vu d'une utilisation MAO...
Quel est l'utilité d'un kernel temps reel. Il me semble d'atrpms en a fait un en vu d'une utilisation MAO...
le kernel Fedora n' est pas plus qu' un autre, patché pour le temps-réel
il intègre les Patches de messieurs Love et Morton (il suffit de cocher une option au choix et de recompiler). Chacun de ces 2 patchs agissent de manière différente et apportent tout les deux des capacités temps-réel mou.
Le patch de sir Molnar, quant à lui, transforme tout le kernel en lui apportant des capacités temps-réel dur.
d' autres solutions existent bien sûr, comme Xenomai issue de rtai (travail de l' armée italienne et de canadiens), rtai lui même issu de rtlinux (qui est devenu propriétaire et du coup a été laché purement)
Ces solutions sont différentes : il s' agit de micro noyau, en fait de "super-scheduler" pour lesquels le noyau linux n' est qu' une tache parmi d' autres.
d' autres solutions encore, plus ou moins opensource, selon, et toutes propriétaires sont disponibles pour les industries militaire, aviation et espace. La plus connue est windriver, qui après voir déployé son kernel, wxworks, propose aujourdhui majoritairement ses solutions pour le kernel linux. D' autres encore, comme Lynuxworks, qui a suivi le même chemin et propose maintenant des améliorations spécifiques pour le kernel linux.
Le patch de Molnar se situe entre 2. en proposant de rendre tout le kernel hard realtime, on obtiens avec son patch des performances qui n' étaient jusqu' alors accessibles qu' avec des puces et de la programmation spécifique (certainement pas avec un kernel générique sur un ordinateur de type x86-32 !). (voir par exemple le mini programme posté ici : http://forums.fedora-fr.org/viewtopic.php?id=14287 ... qui me donne 1 nanoseconde de temps de réponse ... (sur un duron 900mhz) C' est proprement fabuleux. )
Et de nombreuses améliorations dû au travail sur ce sujet ont été intégrée cette année au kernel vanilla. Du patch dyntrick pour l' horloge jusqu' à la priority-inheritance. (bientôt le patch complet disponible par défaut dans la vanilla ? y aura qu' a cocher l' option...)
RedHat maintiens une distribution spécifique temps-réel depuis longtemps
note : Le patch de Molnar est GPL.
Le problème ici est que le blob nvidia n' est pas du tout écrit pour ça, mais alors pas du tout. (le vrai temps-réel n' a rien à voir avec des graphismes ""temps-réels"" ...) Et du coup y a tout plein de problèmes mutex / sémaphores que je suis loin de comprendre. C' est pourquoi je me demandais si ici certains d' entre vous avait appliqué le patch de klaxxon (pseudo d' un dev (de nvidia?)) sur le blob nvidia lui même, avant de lancer la compilation de son api, et en ayant déjà un kernel-rt prêt. Si oui, j' aurais besoin d' aide pour modifier le dernier patch (prévue pour le 8774) pour le blob, afin d' essayer de l' adapter aux derniers drivers en date.
En vous remerciant.
tankey, simple utilisateur, """frustré""" de vous écrire depuis un
2.6.18-rt7+h-nf2 #1 SMP PREEMPT Thu Nov 23 23:31:01 CET 2006
et non pas d' un
2.6.19-rc6-rt7 où le blob nvidia ne comprends pas ce qui lui arrive et fait freezé le kernel.
(le h-nf c' est 2 patches netfilter qui ont été intégré depuis, mais on s' en fout un peu ici)
il intègre les Patches de messieurs Love et Morton (il suffit de cocher une option au choix et de recompiler). Chacun de ces 2 patchs agissent de manière différente et apportent tout les deux des capacités temps-réel mou.
Le patch de sir Molnar, quant à lui, transforme tout le kernel en lui apportant des capacités temps-réel dur.
d' autres solutions existent bien sûr, comme Xenomai issue de rtai (travail de l' armée italienne et de canadiens), rtai lui même issu de rtlinux (qui est devenu propriétaire et du coup a été laché purement)
Ces solutions sont différentes : il s' agit de micro noyau, en fait de "super-scheduler" pour lesquels le noyau linux n' est qu' une tache parmi d' autres.
d' autres solutions encore, plus ou moins opensource, selon, et toutes propriétaires sont disponibles pour les industries militaire, aviation et espace. La plus connue est windriver, qui après voir déployé son kernel, wxworks, propose aujourdhui majoritairement ses solutions pour le kernel linux. D' autres encore, comme Lynuxworks, qui a suivi le même chemin et propose maintenant des améliorations spécifiques pour le kernel linux.
Le patch de Molnar se situe entre 2. en proposant de rendre tout le kernel hard realtime, on obtiens avec son patch des performances qui n' étaient jusqu' alors accessibles qu' avec des puces et de la programmation spécifique (certainement pas avec un kernel générique sur un ordinateur de type x86-32 !). (voir par exemple le mini programme posté ici : http://forums.fedora-fr.org/viewtopic.php?id=14287 ... qui me donne 1 nanoseconde de temps de réponse ... (sur un duron 900mhz) C' est proprement fabuleux. )
Et de nombreuses améliorations dû au travail sur ce sujet ont été intégrée cette année au kernel vanilla. Du patch dyntrick pour l' horloge jusqu' à la priority-inheritance. (bientôt le patch complet disponible par défaut dans la vanilla ? y aura qu' a cocher l' option...)
RedHat maintiens une distribution spécifique temps-réel depuis longtemps
note : Le patch de Molnar est GPL.
Le problème ici est que le blob nvidia n' est pas du tout écrit pour ça, mais alors pas du tout. (le vrai temps-réel n' a rien à voir avec des graphismes ""temps-réels"" ...) Et du coup y a tout plein de problèmes mutex / sémaphores que je suis loin de comprendre. C' est pourquoi je me demandais si ici certains d' entre vous avait appliqué le patch de klaxxon (pseudo d' un dev (de nvidia?)) sur le blob nvidia lui même, avant de lancer la compilation de son api, et en ayant déjà un kernel-rt prêt. Si oui, j' aurais besoin d' aide pour modifier le dernier patch (prévue pour le 8774) pour le blob, afin d' essayer de l' adapter aux derniers drivers en date.
En vous remerciant.
tankey, simple utilisateur, """frustré""" de vous écrire depuis un
2.6.18-rt7+h-nf2 #1 SMP PREEMPT Thu Nov 23 23:31:01 CET 2006
et non pas d' un
2.6.19-rc6-rt7 où le blob nvidia ne comprends pas ce qui lui arrive et fait freezé le kernel.
(le h-nf c' est 2 patches netfilter qui ont été intégré depuis, mais on s' en fout un peu ici)
un tit lien 😉 je serais très intéressé pour complèter ma doc mao et ma tite culture au passage ! MerciSat wrote:En soi, le temps réel n'est pas libre ou proprio, RTLinux est une implémentation devenu proprio, pour du temps réels mou, il y a divers patchs, pour du temps réel dur: il y a RTAI et Xenomai qui utilise tout deux Adeos pour contourner les brevets de FSMLabs sur RTLinux.
Un membre éminent de cette assemblée a co-écrit un cours fort intéressant sur Linux en temps réel ou on présente RTLinux et RTAI.
- Modifié
:roll: vi vi désolé :roll: c' est à la fois pour le défi et à la fois par confortkwizart wrote:blob nvidia?
vi vi ... :-D sur un kernel hard rt, alsa pète encore moins de xrun que sur un kernel (avec le module realtime par exemple) rt mou. Bref Jack est un petits anges... (et aussi pour le défi, l' aumsement d' avoir un kernel tel que celui là)Quel est l'utilité d'un kernel temps reel. Il me semble d'atrpms en a fait un en vu d'une utilisation MAO...
voici des logs typiques quant le blob nvidia fait râler
Nov 27 17:12:02 3athing kernel: EIP: 0060:[pci_get_class+70/122] Tainted: P VLI
Nov 27 17:12:02 3athing kernel: EIP: 0060:[<c01e0bbc>] Tainted: P VLI
Nov 27 17:12:02 3athing kernel: EFLAGS: 00013217 (2.6.19-rc6-rt5-4 #1)
Nov 27 17:12:02 3athing kernel: EIP is at pci_get_class+0x46/0x7a
Nov 27 17:12:02 3athing kernel: eax: 00000001 ebx: e086e000 ecx: 00003246 edx: de2662b0
Nov 27 17:12:02 3athing kernel: esi: e172ca00 edi: d9ae36f8 ebp: da98be5c esp: da98be54
Nov 27 17:12:02 3athing kernel: ds: 007b es: 007b ss: 0068 preempt: 00000001
Nov 27 17:12:02 3athing kernel: Process modprobe (pid: 7163, ti=da98a000 task=de2662b0 task.ti=da98a000)
Nov 27 17:12:02 3athing kernel: Stack: d9ae36b4 d9ae3400 da98bfb4 e086e01b 00030000 00000000 de2678b0 e172ca00
Nov 27 17:12:02 3athing kernel: 00000000 c0334620 c0334620 00000000 da98be90 c013c9d6 c0334620 da98bea4
Nov 27 17:12:02 3athing kernel: c012ed8e d9ae36b4 d9ae3400 d9ae36f8 da98bfb4 c014003e e172ca48 c02f1bdb
Nov 27 17:12:02 3athing kernel: Call Trace:
Nov 27 17:12:02 3athing kernel: [pg0+540786715/1068811264] nvidia_init_module+0x1b/0x7ee [nvidia]
Nov 27 17:12:02 3athing kernel: [<e086e01b>] nvidia_init_module+0x1b/0x7ee [nvidia]
Nov 27 17:12:02 3athing kernel: DWARF2 unwinder stuck at nvidia_init_module+0x1b/0x7ee [nvidia]
Nov 27 17:12:02 3athing kernel: Leftover inexact backtrace:
Nov 27 17:12:02 3athing kernel: [sysenter_past_esp+86/121] sysenter_past_esp+0x56/0x79
Nov 27 17:12:02 3athing kernel: [<c010302d>] sysenter_past_esp+0x56/0x79
Nov 27 17:12:02 3athing kernel: =======================
Nov 27 17:12:02 3athing kernel: Code: 01 00 00 ba 9c 29 30 c0 b8 73 6b 2e c0 e8 67 22 f4 ff b8 c0 ef 33 c0 e8 2f bd f5 ff 85 f6 74 04 8b 06 eb 0e a1 08 ea 33 c0 eb 07 <39> 58 2c 74 0f 8b 00 85 c0 74 07 3d 08 ea 33 c0 75 ee 31 c0 e8
Nov 27 17:12:03 3athing kernel: EIP: [pci_get_class+70/122] pci_get_class+0x46/0x7a SS:ESP 0068:da98be54
Nov 27 17:12:03 3athing kernel: EIP: [<c01e0bbc>] pci_get_class+0x46/0x7a SS:ESP 0068:da98be54
[root@3athing linux]#il est beau mon dwarf2, il est frais mon dwarf2 :lol:
http://www.enseirb.fr/~kadionik/embedded/linux_realtime/
Les autres cours disponibles sont tout aussi intéressants 😉
Les autres cours disponibles sont tout aussi intéressants 😉
- Modifié
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>
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?
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...
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...
- Modifié
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)
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)
- Modifié
Oui merci de la correctioneddy33 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... 😉
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)
- Modifié
@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" :
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>
++
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.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.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
@+
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...
++
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 ...
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 ...