2 - Les distributions et les noyaux

Salut,

En gros (je connais pas mal linux, mais je suis pas spécialiste du realtime), le patch du noyau sert à apporter un scheduler (ordonanceur de tâches) très agressif qui suspend les tâches les moins prioritaires (c'est à dire toutes dans le cas du real time) pour les tâches les plus prioritaires (l'audio en ce qui nous concerne).

Par contre la priorité d'une tâche est dépendante du processus (avec la commande nice on peut changer la priorité) et de l'utilisateur (il faut que l'utilisateur ait le droit de lancer des tâches de priorité real time).

De là je dirais que alsa lancé par un utilisateur autorisé à faire du realtime devrait le faire (jack se sert d'alsa, ce n'est donc pas jack qui apporte le "temps réel", tout au plus ne le dégrade-t-il pas trop).

D'ailleurs le terme de "temps réel" est abusif, on devrait parler de système temporisé (système qui garanti qu'une tâche ne dépassera pas un certain temps prédéfini). La contrainte de temps étant faible on parle de temps réel, mais c'est un abus de langage.

A faire confirmer par un spécialiste (un developpeur kernel sur ce forum ? )

Merci pour ta réponse m.cargnelli 😉

Hier soir j'ai lu cette doc :
http://www.alsa-project.org/main/index.php/Low_latency_howto

et j'ai alors été interpelé par le paragraphe PAM qui semble attribuer directement une certaine priorité à un group d'utilisateurs.
Et ton post me rappelle donc cette lecture.
Sauf que personnellement je n'ai pas de répertoire security dans /etc/
Il y a meme cette histoire de chrt, mais ca non plus je ne l'ai pas.

Tout ce dont tu parles peut-il se résumer à PAM (et chrt) ?
Dans ce cas, comment obtient-on ces possibilités ?

Cette histoire de /etc/security/limits.conf me semble passionnante.
Si pour avoir un bon "système temporisé" 😉 il suffisait d'avoir un kernel RT, de définir les paramètres de ce .conf, et de lancer tous les processus audio sous le group "audio", alors ca serait vraiment très puissant ! 😛

Dans l'absolu c'est ça.
Personnellement je me suis référé à la page gentoo pour le realtime (j'ai une gentoo), mais ça doit être valable, au moins pour la partie configuration, pour les autres distributions.

http://gentoo-wiki.com/HOWTO_Jack#Realtime_mode

Note qu'il y a 2 solutions d'après l'article : avec le module realtime-lsm, et avec pam (>=0.99). La version realtime-lsm n'est plus supportée donc il faut utiliser pam, qui utilise le fameux fichier /etc/security/limits.conf

hmm... ok.

Sinon y'a ici :
http://www.linuxmao.org/tikiwiki/tiki-index.php?page=Acc%C3%A8s+temps+r%C3%A9el+pour+les+applications
😛

Donc si je comprends bien, le patch RT c'est la base, le support meme du realtime par le kernel, mais ca ne gère rien,
et ensuite, il faut un support pour contrôler ce realtime, la répartition de ses priorités pour chaque processus,
et donc on utilise pour cela soit le realtime lsm, soit PAM.
c'est ca ? 😊

et donc le plus puissant actuellement serait d'utiliser PAM ?

'lut,

Globalement d'accord avec ce qui a été dit plus haut. Quelques précisions quand même :

• Le patch d'Ingo apporte plus qu'un nouvel ordonnanceur plus agressif. Il modifie le noyau de façon assez importante le rendant plus "préemptible" (ie "déchargeable" pour faire passer prioritairement d'autres opérations). Il change par exemple la gestion des IRQ qui peuvent alors être ordonnancées/priorisées comme des threads classiques (intéressant pour prioriser l'IRQ attribuée à la carte son par exemple).
• Effectivement, ces "capacités" du noyau ne sont pas accessibles normalement en "single user", pour des raisons de sécurité et de stabilité (difficile de reprendre la main sur un système qui a une application priorisée qui a malheureusement plantée).
• Le module realtime-lsm est considéré comme obsolète par les dev du noyau. Faut dire que cette solution leur posait problème notamment en terme de sécurité (un module capable de plein de trucs sensibles sur le noyau lancé en permanence...). La méthode "officielle" est donc d'utiliser PAM (qui sert à la base pour plein d'autres trucs, et notamment quand il faut établir des règles de répartition des ressources).
• PAM permet aussi d'attribuer de la mémoire vive "non swapable", garantie de bon fonctionnement (certaines applis comme ardour avertissent l'utilisateur si cette valeur est faible par rapport à la mémoire vive totale disponible)

T.

Bonjour !
En lien avec ce qui vient d'être dit sur l'évolution de l'intégration du "real-time" au noyau, est-on près d'après vous, à voir les noyaus de nos distributions en real-time par défaut ? Pourquoi n'est-ce pas encore le cas à votre avis ?

Bonne soirée

Et bien tout simplement parce que Linux est très majoritairement utilisé à des fins réseaux.
Or il serait parfaitement stupide d'utiliser le real-time pour un serveur...

Attention :
Ca fait un bout de temps que le noyau 2.6 évolue, et il est parfaitement possible de faire fonctionner en temps réel une application même avec un noyau vanilla (vanilla = noyau standard disponible sur http://www.kernel.org et non patché). D'ailleurs, il suffit de configurer PAM correctement pour pouvoir lancer qjackctl avec l'option RT.

Le patch d'Ingo, par les modifications substantielles du noyau qu'il apporte, permet "juste" d'en améliorer les performances, schématiquement en permettant aux processus des applications lancées en temps réel de passer "devant" d'autres opérations bas niveau du noyau. On se rapproche ainsi du fonctionnement d'un système temps réel "dur". Mais ce fonctionnement peut avoir des conséquences néfastes en terme de stabilité (j'en parle au-dessus), de sécurité (ben oui, une appli en mode user prioritaire sur des processus noyau, vaut mieux pas qu'elle ait une faille exploitable...), voire même en terme de performances : une des qualités de linux, c'est en effet son fonctionnement multitâches, où l'ordonnanceur répartit les ressources pour permettre à l'utilisateur de faire plusieurs choses en même temps. C'est quand même bien pratique, et un peu contradictoire avec ce que l'on cherche à faire en MAO (prioriser tout pour le son au détriment du reste).

Enfin il y a des domaines nettement plus exigeants que la MAO pour le temps réel (industrie, mais aussi bourse -et oui, en une fraction de seconde des milliers de dollars s'envolent) qui nécessitent des solutions encore plus performantes et adaptées. D'ailleurs, la lutte est acharnée sur ce marché ( http://www.linuxfr.org/2007/12/13/23447.html ), notamment entre Novell (qui propose SUSE Linux Enterprise Real Time) et Red Hat (avec Red Hat Enterprise MRG) qui emploi un certain ... Ingo Molnar !

T.

Merci MrBark et Trinine pour vos réponses.
Je comprends un peu mieux la logique de tout ça.
Ciao