Chargement...
 
Skip to main content

1 - La documentation et les nouvelles de LinuxMAO


[chantier] wiki noyau RT

France
Coucou za tous

vu les nouveautés récentes du coté de l'équipe RT du noyau linux, je pense que c'est l'occasion de refaire le wiki le concernant sur linuxmao : Le noyau Temps-Réel

Ce que je crois comprendre :

Le "noyau RT" consiste en plusieurs améliorations diverses et variées de la structure interne du noyau, il ne s'agit pas d'une fonction unique "RT"
Les plus grosses améliorations sont aujourd'hui toutes intégrées au noyau "vanilla" (le noyau de base) mais non activées, il faut pour cela simplement utiliser l'option Preemption Model = Complete Preemption (Real-Time) (CONFIG_PREEMPT_RT) (il y a d'autres réglages sympa à faire pendant la config du noyau tant qu'on y est, mais ceux-la sont indépendants des améliorations RT : fréquence du proc au max, désactivation de la gestion automatique de l'alim...)
(en fait, il y'a peut etre d'autres options liées, à vérifier : High-Resolution Timer (utilisé par rosegarden il me semble, Deterministic Scheduler (on en a besoin pour la MAO de ca ?) )
les améliorations RT importantes et déjà intégrées au noyau vanilla sont, en plus des deux précédentes (sources) :
  • Preemption Support
  • IRQ Threads (depuis linux 2.6.30)
  • Forced IRQ Threads (depuis linux 2.6.39)
à ma connaissance, ce sont les améliorations qui font gagner des milisecondes, et sont donc utiles à la MAO, les autres améliorations toujours en développement (le patch RT actuel) sont mimines à coté (font gagner des microsecondes, ca peut etre utile à l'industrie, mais pas vraiment pour nous)
la nouveauté, c'est donc les threaded IRQ, cette fonction oblige à utiliser en plus un utilitaire système comme rtirq (voir Temps-réel pour les processus IRQ)
c'est un changement important car les personnes qui utilisaient un noyau ''vanilla' en mode RT n'avaient pas jusqu'à présent à faire celà, et les questions sur le forum du genre "ca marche plus" vont bientôt tomber.

j'aimerai savoir si j'ai bien tout juste, et aussi avoir des détails sur les 2 options de conf du noyau High-Resolution Timer et Deterministic Scheduler (je ne suis pas sur que cette dernière soit une conf à part d'ailleur, elle est peut etre incluse dans Complete Preemption), vous en savez plus ?

si tout le monde est bien d'accord, alors on peut passer à la ré-écriture partielle des pages sur le noyau RT, encore une fois les points importants à aborder sont :
  • le patch RT ne sert à rien pour la MAO, pour du RT dur sans souci utilisez un noyau vanilla ou similaire avec les options RT stables appropriées
  • gestion obligatoire des priorités des IRQ (avec rtirq par exemple)
  • rabachage : patchez votre noyau seulement si vous souhaitez aider à débugguer, pas pour faire de la musique !!

j'en profite pour proposer un plan (hierarchie) pour ce dossier :
dans optimisations système :


j'attend vos commentaires ! 😉

oliv'
J'ai testé mon autre machine, équipée d'une carte Nvidia avec tous les drivers disponibles dans la Linux Mint, mais aucun n'a fonctionné...un misérable écran en 800x600.
Donc cette machine restera en kernel lowlatency ce qui n'est pas si mal avec ma carte son externe (UMC 1820 Behringer), 5,3 millisecondes.
Bon en même temps, j'ai une tour (carte Nvidia additionnelle) sur laquelle je peux rajouter de la mémoire vive (32 Gb pour moi) sur laquelle je peux même changer le processeur si besoin. Mais bon !
Pour ceux qui ont de vieilles tours, gardez les précieusement. Les machines actuelles, notamment les PC portable, ne sont pas aussi modulables.
Mais quoiqu'il en soit, un noyau Linux lowlatency ou realtime exploitera la machine mieux que n'importe quel autre système d'exploitation.
Je suis en train de restaurer un vieux synthé Quasimidi Sirius des années 80. Le processeur de cette machine date, est obsolète, et quand on voit ce qu'il fait, je m'interroge ?!?
Aujourd'hui les processeurs sont donnés pour hyper-puissants, mais la majorité du temps cela se résume à : Il attends plus vite les données. 😉
Et je rajouterai il fait tourner windows 😊
Sur ma machine de mix (une vielle tour d'au moins 15 ans), en debian testing, pas de noyau particulier, le debian de bas qui est déja en "dynamic preamp"
6.17.13+deb14-amd64 #1 SMP PREEMPT_DYNAMIC
Je n'ai qu'une sortie via une interface DAC/casque reliée en optique, mesurer une latence n'aurait pas de sens.Pour mon usage, le plus important est la qualité de cette interface, ainsi que celle du casque

Sur la machine de prise de son, c'est une librazik avec le noyau recommandé, sur un vieux portable de plus de 10 ans. L'interface est une XR18. A nouveau, mesurer une latence n'aurait pas de sens, c'est la XR18 qui fait les retours (0 latence perceptible), et qui gere les effets sur chaque piste.
Certains de nos morceaux sont rapides (200 bpm), on ne supporterait pas une latence de 5 ms dans les retours (l'équivalent d'un sextolet), ça tuerait le groove.
Page: 2/2
1  2