Cette volonté de ne pas laisser un concurrent en position de monopole sur ce secteur, même pour une durée infime, s'explique aisément. En effet de plus en plus les entreprises reposent sur l'automatisation poussée de leurs processus afin de gagner en réactivité. On se rappelle, lors du sommet Linux 2007, le témoignage du représentant du Crédit Suisse qui indiquait qu'un noyau patché pour le temps réel aidait à maintenir les profits lors d'une transaction financière.
La prédictibilité des temps de réponse est donc un enjeu crucial et les distributeurs commerciaux de Linux sont en compétition pour couvrir ce marché au point, comme nous allons le voir, de déclencher une véritable guerre des communiqués.
![[en]](../images/en.png)
LWN : La compétition autour du temps réel (556 hits)-
Description de la solution Novell (298 hits)
-
Description de la solution Red Hat (351 hits)
-
Les patchs RT du noyau (471 hits)
> Lire la dépêche (53 commentaires, moyenne: 4,9).
Vous avez demandé le commentaire #889904.
Run by 
Cette page a été générée par Templeet en 0.0765s (dont 0.0079 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
trem-RT :)
Les utilisateurs Mandriva, comme moi, qui souhaiteraient essayer un noyau temps-réel dur (solution patch de l' équipe de Mr Molnar) peuvent le faire simplement en installant le(s) rpm(s) correspondant :
kernel-rt (et les sources si besoin...).
Ce kernel a rejoint le dépôt Contrib pour la 2008.
urpmi kernel-rt-latest kernel-rt-source-latest
(il y a aussi une version kernel-rt-SMP)
Et les utilisateurs enchainé au blob de nvidia seront "heureux" d' apprendre que le driver nvidia fourni par le PLF est patché pour supporté un noyau temps-réel dur. (le driver nvidia n' étant pas copain, pour le moment, avec un noyau temps-réel)
ps : n' oubliez pas de customiser le fichier limits.conf afin d' y renseigner correctement les nouveaux ""droits"" pour votre utilisateur.
Merci pour cette dépêche, passionante.
[^]Re: trem-RT :)
Merci pour cette dépêche, passionante.
Pareil. A vrai dire, j'ai commencé à la lire, et je me suis dit tiens ça ressemble a du patrick_g, bingo.
Merci pour toutes tes dépêches/journaux, patrick_g, c'est toujours très bien écrit !
[^]Re: trem-RT :)
Quelle est l'utilité du temps reel dur sur une distrib orientée desktop ? un temps reel mou ou semi-dur n'est il pas suffisant pour la plus exigeante des madames michu ?
[^]Re: trem-RT :)
Pour la MAO ?
(note: c'est une vrai question)
Cf Jack -> http://jackaudio.org/
[^]Re: trem-RT :)
En l'état, sur une machine normalement chargée, je trouve que jack (ou alsa tout court) marche très bien sans recourir à des patchs 'temps reel dur'. De même windows et macos s'en sortent très bien pour faire de l'audio a faible latence et pourtant ils ne sont pas "temps reel dur"
[^]Re: trem-RT :)
>>> De même windows et macos s'en sortent très bien pour faire de l'audio a faible latence
Y'avait pas une histoire sur les performances réseau de Vista qui s'effondraient quand le user écoutait de la musique ?
[^]Re: trem-RT :)
Si. "Playing Music Slows Vista Network Performance ?" [http://it.slashdot.org/article.pl?sid=07/08/21/1441240]
On a long enough timeline, the survival rate for everyone drops to zero.
[^]Re: trem-RT :)
Jack sans l' option RT ? ça va être un 14 juillet de xruns, là ;)
[^]Re: trem-RT :)
Comme Yvan, c'est clair qu'il est in-envisageable de faire de la MAO sérieusement sans un kernel RT... maintenant, ma question (et là ou j'avoue ma méconnaissance), c'est sur la pluvalue éventuelle d'un RT dur pour la MAO, par rapport à du RT "mou".
[^]Re: trem-RT :)
winCE est temps-réel (prremption-on-acid même ? je ne suis pas sûr, je ne crois, à vérifier). Mais ce qui est sûr c' est que WinCE annoncé comme révolutionnaire à fait flop dès qu' ils (ms) ont ouvert le code aux clients. Les gars de l' industrie ont dû se dire un truc du genre "oula y a tant que ça à refaire dedans, bon ben on va garder vxworks et autres, hein..."
En tout cas, WinCE, à part sur les téléphones portables et autres gadgets, personne n' en n' a plus jamais entendu parler dans l' industrie il me semble...
Mac OSX a CoreAudio qui est temps-réel.
[^]Re: trem-RT :)
WinCE 6.0 est TOUT sauf temps-réel "dur", en tout cas, je refuse de l'utiliser dans une application "safety critical".
Au niveau déterminisme, Linux+PREEMPT_RT est nettement plus fiable. En plus,
Au niveau industriel, WinCE a fait une petite percée dans l'automobile avec "WinCE for automotive", Microsoft s'est associé à quelques constructeurs et équimentiers. Kuka Gbmh (fabricants de robots Allemand) propose deux solutions de virtualisation pour utiliser soit WinCE soit VxWorks en concurrence de Windows.
Le seul avantage de WinCE sont les outils de développements et encore, un routard de l'embarqué sait générer sa chaine de cross-compilation comme un grand. :o)
[^]Re: trem-RT :)
Temps réel dur ne signifie pas faible latence mais capacité à ne louper aucune échéance.
Tu peux avoir un TR dur ayant des latences de 100ms et un TR mou avec des latences de 10µs.
[^]Re: trem-RT :)
je me suis dit la même chose que le commentaire plus haut, avant de lire le nom du rédacteur je me suis dit, "tiens, on dirait du patrick_g !" Félicitation pour cette dépêche.
Si j'ai bien compris, ce combat des diverses distributions se passe en temps réel :)
Un noyau temps réel de base, cela pourra permettre aux musiciens de ne pas avoir de latence lorsqu'ils travaillent sous linux.
Actuellement, il faut appliquer soi-même des patchs, recompiler le noyau ou utiliser des noyaux patchés non officiel etc.
J'avais essayé les patchs et la recompilation sous opensuse à l'époque, bilan cela rendait la machine instable, kernel panic lors de l'utilisation de mon périph usb midi. J'avais essayé debian studio 64, cela fonctionnait, mais impossible de recompiler correctement certains logiciels car les sources étaient différentes du noyau fournit. La liste de diffusion n'a pas bcp aidé face à cela, donc j'ai rapidement changé de distribution. Actuellement je travaille sans noyau patché, et sur certaines choses il y a de la latence, donc je suis moins bien loti que les utilisateurs windows par exemple qui n'ont pas besoin de se prendre autant la tête juste pour enregistrer ou brancher leur clavier...
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: trem-RT :)
Comme il est dit plus haut, la Mandriva 2008 propose un kernel-rt ainsi que ses sources. La particularité de ce noyau est qu'il permet une recompilation facile en fonction de son matériel. Personnellement j'utilise ce noyau en production (x86_64) pour la MAO et les temps de latences sont en chutes libres. 5 ms, avec un peu de réserve.
Selon l'application, on peut descendre jusqu'à 2 ms (en pilotant la machine MAO sans X par ssh depuis une machine maître)
[^]Re: trem-RT :)
Normalement, tu peux descendre beaucoup plus bas avec PREEMPT_RT en deça des 100µs jusqu'à 16µs (avec le kernel de l'osadl).
Avec mon kernel de base avec le profil "voluntary preemption", j'ai des latences max de 5ms en utilisant le bench cyclictest.
[^]Re: trem-RT :)
Pour ma part avec le kernel rt Mandriva 2008, cycletest me fait rester en dessous de 37 micro secondes. Idem avec le kernel osadl.
[^]Re: trem-RT :)
vi /etc/security/limits.conf
@audio - rtprio 80
@audio - nice -15
@audio - memlock 300000
grossomerdo ça veut dire :
@ = groupe, donc le groupe audio à -> les valeurs après
la wildcard - désigne à la fois hard et soft. on peux à la place mettre soft uniquement par exemple.
rtprio peut aller jusqu' à 99 il me semble (à vérifier)
nice est la valeur de priorité dans la table des process. Son vocabulaire la fait aller jusqu' à -19 qui est la plus haute priorité.
memlock permet de locker une partie de la mémoire vive, ici 300MO.
(d' autres options permettent par exemple de limiter le nombre de fichiers ouverts pour l' utilisateur en deça de ceux prévu par le système, par exemple, ou encore le priority de base. Mais n' ont pas trop lieu d' être ici)
Jack veux au moins : kernelRT + rtprio à 60 (en dessous ça rale) + de la mémoire vive bloquée/dédiée. Sans ces configs, jack même sur un kernel RT n' est pas super efficace.
bon voilà, j' unlock, oupss, désolé
[^]Re: trem-RT :)
Juste pour pinailler:
les patches RT du kernel ne permettent pas de faire du temps réel "dur", ils rendent simplement le kernel plus préemptible.
Le temps réel dur c'est pouvoir être *certain* qu'une tâche sera exécutée avant un délai donné.
Au final, pour de l'audio avec les patchs d'Ingo Molnar, on n'a quasiment aucun xrun, mais cela ne permet pas d'affirmer que le kernel est temps réel dur.