1278 connectés

FORUM HardWare.fr

Linux et OS Alternatifs

Débats

Kernel lowlatency : kesako ?

Recherche :

Dernière réponse
Sujet : Kernel lowlatency : kesako ?
enfoiro	pour ceux que ca intéresse, partie 3 du tuto "RT on Java" sur le developerworks http://www-128.ibm.com/developerwo [...] 7javatsync a+

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

enfoiro

pour ceux que ca intéresse, partie 3 du tuto "RT on Java" sur le developerworks
http://www-128.ibm.com/developerwo [...] 7javatsync
a+

enfoiro

Merci de lire le début du topic où l'explication est donnée. :o

goldyfruit

Oui je sais, merci.

goldyfruit a écrit :

Pour une utilisation desktop (dev web et trucs dans le genre) ça a une réelle utilité ou autant rester en lowlatency + preempt ?

dans le kernel, y a une option pour regler un truc don je me souvien plus le nom, on a le choix entre different hz, genre 250hz ou bien 1000 hz ...
le kernel generic est regle sur 250 hz , et le low lattency sur 1000hz...
seulement,avec les nouveau CPU SMP (genre les core2duo), il vau mieu etre sur 250hz (raison technique complique...).

Bref, pour le desktop il vau mieu etre en generic, et utiliser le lowlatency que pour des raison specifique.

goldyfruit a écrit :

Pour une utilisation desktop (dev web et trucs dans le genre) ça a une réelle utilité ou autant rester en lowlatency + preempt ?

realtime-lsm permet à une appli qui tourne en user d'acquérir des capacités realtime (qui ne le sont pas vraiment mais passons). Donc, à moins d'utiliser une appli spécifiquement conçue pour le RT (comme jackd), ça ne change rien.

Sinon, je suis vraiment enthousiasmé par l'intégration du RT d'Ingo Molnár dans linux. Ca ouvre toute une série de perspectives, comme l'utilisation d'un OS GNU/linux complet dans un environnement industriel qui nécessite le RT (et il y en a énormément).
Contrôler de l'électronique avec une résolution à la milliseconde ... sous Debian :love:
C'est autre chose que la virtualisation, WinFS ou le ReadyBoost (TM) [:rhetorie du chaos]

Avec les progrès récents de l'embarqué :les SBC x86, les micro plates-formes arm, les nouveaux FPGA ... [:nico54]

goldyfruit

enfoiro a écrit :

kernel lowlatency ubuntu + module realtime-lsm
ca marche au poil :)

a+

Pour une utilisation desktop (dev web et trucs dans le genre) ça a une réelle utilité ou autant rester en lowlatency + preempt ?

enfoiro

kernel lowlatency ubuntu + module realtime-lsm
ca marche au poil :)

a+

enfoiro, j'ai exactement la meme chose que toi ^^ C2D avec intel HD integre :)
je pense que je vai me prendre une carte un peu plus convenable :)

mais avec ta nouvelle carte, quel type de kernel utilise tu maintenant?
le kernel genric ou bien le lowlatency+module realtime?

enfoiro

Salut,

Moi aussi j'avais des craquements en ayant le kernel lowlatency d'ubuntu avec un chip intel HD intégré. Conclusion => changement de carte son pour quelque chose de potable (terratec phase 22) et maintenant ca marche au poil.

L'installation du module realtime-lsm est obligatoire pour que jack fonctionne en realtime.

Je n'ai pas eu besoin de patcher mon noyau pour ne plus avoir de "xruns" ie des latences trop élevées (config C2D sur une P5B).

Je pense que le souci était dû au driver alsa du chip intel, ou que ce chip intégré est pourri.

T'a quoi comme carte son ?

a+

bon alors je cross post un peu entre ce topic et le topci de la MAO mais bon ici comme ca parle plus de kernel c'est sans doute plus adapte.
Donc voila mes questions sans reponse :
probleme : par defaut, avec le kernel generic smp ubuntu (Linux punkcpu 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux)
j'ai des craquement lors d utilisation d'appli MAO.

on m'a donc conseille de reduite la latence de mon kernel

maintenant j'ai plusieur option qui s'offre a moi.

- utiliser le kernel genric, et installe le module realtime-lsm (a mon avis ca va pas servir a grand chose

- installe le kernel lowlatency propose dans le repository

- installe le kernel lowlatency propose dans le repository + le module realtime-lsm

- installer le pach rtlinux et ensuite recompilation de mon kernel (je m'en passerai bien ...)

- installer le pach rtlinux et ensuite recompilation de mon kernel + installation du module realtime-lsm

voila. et enfin, un truc qui me perd encore plus, c'est que j'ai un core 2 duo, et que justement avec les smp, il n'est pas conseille d'voir 1000hz, mais plutot de rester vers 250hz, comme c'est configurer dans le kernel generic ubuntu.

quelle est donc la meilleur solution, merci.

enfoiro

intéressant lien.
Ingo vient de publier un patch qui est une refonte du scheduler de linux (Complete Fair Queuing)
http://kerneltrap.org/node/8059

THRAK

enfoiro a écrit :

1) En effet, intéressant http://techpubs.sgi.com/library/tp [...] realtime.z

Il s'agit d'un document concernant une ancienne release qui date (et pas qu'un peu).
Pour des informations plus fraîches sur le RT la release actuelle d'IRIX (6.5) voici un pdf assez sympa :
---> http://www.sgi.com/pdfs/3291.pdf

enfoiro

THRAK a écrit :

1) En fait il était principalement question de IRIX, un UNIX développé par SGI.

2) Pour les autres UNIX je ne pourrais pas en dire plus, si ce n'est qu'il en existecertains développés spécifiquement pour le temps réel strict. J'imagine que ces derniers doivent être ce qu'il y a de mieux en la matière, mais ils ne sont pas vraiment adaptés à un usage autre que dans le domaine militaire, de la recherche ou de l'industrie, et plus spécialement sur de l'embarqué (micro-contrôleurs avec des contraintes strictes).

3) Ce qui me permet de réagir à cette phrase :

Citation :

A mon avis, le kernel linux possède trop de fonctionnalités, est trop complexe pour devenir totalement "hard realtime".

4) C'est peut-être la question la plus utile qu'il faut se poser : le temps réel strict a-t-il un réel intérêt pour la majorité des utilisateurs ? Il semble que non si j'en crois quelques infos glanées sur le web, notamment au niveau de la définition de système temps réel par Wikipédia :

Citation :

On distingue le temps réel strict ou dur (de l'anglais hard real-time) et le temps réel souple ou mou (soft real-time) suivant l'importance accordée aux contraintes temporelles. Le temps réel strict ne tolère aucun dépassement de ces contraintes, ce qui est souvent le cas lorsque de tels dépassements peuvent conduire à des situations critiques, voire catastrophiques : pilote automatique d'avion, système de surveillance de centrale nucléaire, etc. À l'inverse le temps réel souple s'accommode de dépassements des contraintes temporelles dans certaines limites au-delà desquelles le système devient inutilisable : visioconférence, jeux en réseau, etc.

Source : http://fr.wikipedia.org/wiki/Système_temps_réel
5) On en déduit donc bien, en terme d'usage, que c'est moins le temps réel dur que souple qui importe dans le cas de Linux. Le temps réel souple posant moins de contraintes en terme de développement, il n'est pas impossible -loin de là- que nous le voyons prochainement intégrer en standard le noyau.

1) En effet, intéressant http://techpubs.sgi.com/library/tp [...] realtime.z

2) oui

3) Je pensais à tout le travail d'adaptation des différentes parties du noyau, en particulier aux drivers qui doivent être adaptés pour pleinement profiter du RT. De toute facon, si c'est faisable et pas pénalisant pour les performances, ca sera fait :).
J'ai regardé RTAI, c'est intéressant, mais ce n'est pas le kernel linux en lui-même qui est modifié, ils font tourner le kernel non RT linux sur un microkernel disposant de fonctions temps réel. C'est l'autre stratégie par rapport à la stratégie d'ingo, que j'ai expliqué plus haut. Peut être que ce n'était pas clair, mais je parlais de la stratégie consistant à modifier directement le noyau pour le rendre RT. La stratégie micronoyau est plus simple à mettre en oeuvre mais provoque des baisses très importantes de performances ( voir http://en.wikipedia.org/wiki/Microkernel par exemple)

4) oui

5) oui

edit : lien interessant

http://www-128.ibm.com/developerwo [...] vartsystem

memaster

Nonor_ a écrit :

Oki et ce flux vient d'où ? C'est probablement du h264 pour que tu lutte comme ça... Car le divx n'est de toutes manières pas utilisé (du moins à ma connaissance) pour ces trucs là...
Sinon en ce qui concerne le décodage, rapport à ce que disait thrak aussi, faut voir si le codec gère le multicore/proc.... Et voui... Enfin ça doit être le cas mais je suis pas sûr.
Sinon faudrait que t'analyse les logs et que tu tente de lire avec mplayer le flux, en verbose, pour en voir le détail, ça aiderait. Car ffmpeg peut lire le h264 mais aussi la lib x264 qui est faite pour (j'espère pas dire de conneries) donc tu peux toujours essayer l'un ou l'autre... Et des options exotiques, y'en a aussi pour le décodage, et ça peut aussi accélérer le processus...

peut etre qu'on devrais scinder se sujet? :??:
on en reparle dans un autre sujet ;)
http://forum.hardware.fr/hfr/OSAlt [...] 2908_1.htm

Nonor_

memaster

Nonor_ a écrit :

Ah pardon, autant pour moi, mais alors je pige pas.... il fait quelle résolution ton stream ? Et tu dis mpeg4, mais, précise le codec, parce que là tout est possible... Simple divx ou h264 ? Parce que bon, un divx alakon, donc un "mpeg4", mon p3 600 (monocore) il le lit parfaitement...

j'avoue que j'ai pas regardé :(
mais par exemple lorsque TF1 diffuse un evenement sportif (au hasard la F1) en 16/9 sur une resolution native de mon ecran
en 1680x1050, l'image prend plus de la moitié du bureau donc bon, la definition doit etre de 768 lignes
comme un dvd. et la ça rame sec et ça stoppe carrément vlc :heink:
ensuite je suppose que le son est diffusé en dolby stereo...
donc ce n'est pas un divx alakon :non:
qd au codec, c'est ffmpeg qui s'en charge. et faut pas dire que c'est le débit du cable ethernet qui
est insuffisant puisque le decodeur officiel, lui s'en sort très bien (sauf que lui possède
sans doute un buffer plus gros et decode accel materiel forcément).
sauf qu'a travers la peritel ==> s-video ==> ma carte tv-pci je recupere le signal en 576lignes

THRAK

En fait il était principalement question de IRIX, un UNIX développé par SGI.

Pour les autres UNIX je ne pourrais pas en dire plus, si ce n'est qu'il en existecertains développés spécifiquement pour le temps réel strict. J'imagine que ces derniers doivent être ce qu'il y a de mieux en la matière, mais ils ne sont pas vraiment adaptés à un usage autre que dans le domaine militaire, de la recherche ou de l'industrie, et plus spécialement sur de l'embarqué (micro-contrôleurs avec des contraintes strictes).

Ce qui me permet de réagir à cette phrase :

Citation :

A mon avis, le kernel linux possède trop de fonctionnalités, est trop complexe pour devenir totalement "hard realtime".

Ce n'est pas entièrement exact amha. À la base je pense qu'il s'agit plus d'une contrainte lié à l'orientation de Linux en terme d'usage (à qui il s'adresse) plutôt que de contraintes vraiment techniques (même si elles existent). La preuve est qu'il existe tout de même certains projets qui offrent du temps réel strict sous Linux, dont l'un des plus notables est certainement l'extension libre RTAI.

C'est peut-être la question la plus utile qu'il faut se poser : le temps réel strict a-t-il un réel intérêt pour la majorité des utilisateurs ? Il semble que non si j'en crois quelques infos glanées sur le web, notamment au niveau de la définition de système temps réel par Wikipédia :

Citation :

Source : http://fr.wikipedia.org/wiki/Système_temps_réel
On en déduit donc bien, en terme d'usage, que c'est moins le temps réel dur que souple qui importe dans le cas de Linux. Le temps réel souple posant moins de contraintes en terme de développement, il n'est pas impossible -loin de là- que nous le voyons prochainement intégrer en standard le noyau.

:)

enfoiro

THRAK a écrit :

Pour précision : les doutes que j'ai exprimés se basent sur quelques discussions que j'ai pu quelquefois avoir avec des gens beaucoup plus calés que moi sur ce sujet. À ces occasions, il ressortait que malgré l'âge de certains UNIX, certains conservent toujours une bonne longueur d'avance sur Linux en matière de RT pur, à moins de lourdement patcher ce dernier.

Oui, on est d'accord.
Le kernel linux n'est PAS construit comme un kernel hard RT à la base. Ce n'était pas le but lors de la conception. Le rendre hard RT est donc une tâche extrèmement difficile.
Un kernel hard RT garantit la disponibilité du kernel. Or, même avec le patch RT, on voit que cette disponibilité du kernel n'est pas toujours garantie.
Après, si l'API RT POSIX reste la même, par contre, ce qu'il y a derrière change.
Ce serait intéressant si tu pouvais te rappeler, ou essayer de classer les différents UNIX par rapport à leur conception/potentialités RT.
A mon avis, le kernel linux possède trop de fonctionnalités, est trop complexe pour devenir totalement "hard realtime". C'est la longue route sur laquelle est ingo molnar, et il doit aussi convaincre les devs du noyau, notamment linus, qui lui a récemment demandé de réecrire un algo qui ajoutait trop d'overhead. Ce qu'il a fait avec succès.

THRAK

enfoiro a écrit :

Mais oui, c'est ce que je m'escrime à expliquer. Regardez le pdf de suselabs il est TRES instructif.
Bon et pour le lien de memaster c'est un system linux HAUTEMENT MODIFIE, pas un kernel normal.

enfoiro

THRAK a écrit :

J'émets un certain doute à ce sujet : Linux n'est pas un noyau temps réel à la base.

Même avec les patchs d'ailleurs il n'excelle pas particulièrement dans ce domaine.

Mais oui, c'est ce que je m'escrime à expliquer. Regardez le pdf de suselabs il est TRES instructif.
Bon et pour le lien de memaster c'est un system linux HAUTEMENT MODIFIE, pas un kernel normal.

page linuxdevices :

An extended temperature Arcom PC/104 board based on a 400MHz Intel XScale processor now supports a hard, real-time Linux operating system from FSMLabs

Il y a plusieurs stratégies pour rendre le kernel RT
Voir le pdf slide 8 et 9 : 2 grandes méthodes pour rendre linux RT
- Utiliser des kernels linux qui tournent dans un micro noyau hard RT ou dans un autre noyau comme ITRON. slide 9
- Rendre le kernel linux hard RT en le modifiant. slide 8

J'ai regardé le kernel en question, c'est RTlinux (la techno a été rachetée par windriver). Eux utilisent la méthode de modification du kernel en permettant à l'utilisateur d'utiliser les API POSIX pour faire du RT : ca permet d'avoir une application qui reste quasi-identique mais qui peut être RT grâce au kernel modifié. C'est donc la 2e approche. Pour plus d'infos c'est ici : http://www.windriver.com/products/ [...] erview.pdf
(slide 5 pdf suselabs)

Et sinon, effectivement, je ne vois pas la différence entre un process "normal" nicé à -15 et un process kernel nicé à -15. Le truc c'est qu'il faut configurer/utiliser rlimits ou realtime-lsm pour avoir cet accès RT pour les applis normales.

De rien goldyfruit :)

THRAK

Nonor_ a écrit :

Voui c'est vrai mais si notre ami essaye de décoder par exemple france télévision en haute def sur la freebox tv (c'est l'exemple que je connais), ben là on se bouffe du h264 en 1080 et ouille le processeur. Mon P4 2.66 n'y arrive pas, et le p4E 3ghz de mon paternel y arrive.... avec des décrochages, donc bon...

La dernière fois que j'ai voulu tester une chaîne en HD avec Freebox TV ça avait l'air lourd effectivement (en fait chez moi VLC plantait carrément :whistle: ).

Bon cela dit avec les chaînes avec des flux 'normaux' ça passe pas mal du tout ; c'est déjà ça. :)

Après c'est sûr que pour traiter des flux HD en temps réel il faut avoir du matos derrière ; avec une bécane qui date d'il y a 5 ans c'est forcément limite pour ce genre d'application, à moins éventuellement d'avoir un système SMP (auquel cas 2 procs ou + arriveront sans doute à encaisser la charge).

Nonor_

THRAK

Pour avoir testé, avec un noyau PREEMPT il est aussi possible de lire des vidéos sans problème sur un PII 300 MHz avec 128 Mo de RAM et une carte vidéo de la même époque (PCI 8 Mo). :)

Ça reste globalement fluide avec des vidéos compressées avec les codecs divx ou xvid ; avec du ogm, mkv et autres h264 c'est trop limite et le frame clipping se fait vraiment ressentir. Mais bon, c'est pas mal quand on tiens compte de l'âge de la machine qui date de 1997 :D

goldyfruit

Un K6-2 450Mhz est capable de lire un DivX. ^^
enfoiro merci. :jap:

Nonor_

memaster a écrit :

raaahhhhlala,
j'ai tiré un cable de 20m pour relier mon ordi "plus puissant" (celeron 2.8Ghz, bon ok on rigole pas :kaola:
mais bon face à un bi-p3...)
et ben ça ramouille/decroche encore (beaucoup moins souvent cependant) pendant les pubs du multicast-orange.
mais c'est l'hallu :wahoo: , il va bientot me falloir un core2duo pour decoder/afficher en temps réel du mpeg4 :pt1cable: [:psywalk]

memaster

THRAK a écrit :

J'émets un certain doute à ce sujet : Linux n'est pas un noyau temps réel à la base.

Même avec les patchs d'ailleurs il n'excelle pas particulièrement dans ce domaine.

un p'ti lien (juste un exemple)?
http://linuxdevices.com/news/NS8774914399.html

en embedded sur xscale ça ro><e, moi meme ayant un xscale pxa, j'ai "compilé" un kernaille
pour mon pda ==> et installé un familiar sur sd-card.

THRAK

memaster a écrit :

les processus de bas niveau, ceux occupé par des fonctions fondamentales du systeme, il est normal qu'ils tournent en RT sur des kernel non patchés.

J'émets un certain doute à ce sujet : Linux n'est pas un noyau temps réel à la base.

Même avec les patchs d'ailleurs il n'excelle pas particulièrement dans ce domaine.

enfoiro

J'avais lu ca qque part ; en tout cas par morceaux, pour la globalité je sais pas. Ingo molnar code tellement que tu t'y retrouve meme plus :ouch:
http://kerneltrap.org/node/7753 (syslets & threadlets)
http://grmso.net:8090/changelog/all/ (si ca marche pas cache de google)
http://lwn.net/Articles/222315/ (voir clockevents and dynticks)

goldyfruit

Ce patch va être intégré au noyau ?

memaster

enfoiro a écrit :

Aucun argument, aucune page, rien d'intéressant en somme.
Discute tout seul, ca sera la même chose.

:hello:

edit : en plus, j'essaie de t'expliquer les choses clairement, mais si tu n'a pas envie d'apprendre, je n'y peux rien ;)

je soulignais juste que tu me faisais dire ce que je n'ai pas dit.
qd à mon envie d'apprendre, elle va aussi vite que mon anglais :( , donc je fais ce que je peux en lecture/traduction ;)

enfoiro

memaster a écrit :

non justement :non:
ce n'est pas ce que j'ai écrit, mais plutot le contraire.
même "nicé" en -15 un vlc/ffmpeg ne tourneras pas en RT :non:

Aucun argument, aucune page, rien d'intéressant en somme.
Discute tout seul, ca sera la même chose.

:hello:

edit : en plus, j'essaie de t'expliquer les choses clairement, mais si tu n'a pas envie d'apprendre, je n'y peux rien ;)

memaster

enfoiro a écrit :

non justement :non:
ce n'est pas ce que j'ai écrit, mais plutot le contraire.
même "nicé" en -15 un vlc/ffmpeg ne tourneras pas en RT :non:

enfoiro

un patch d'un mo pour ca :pfff: . je te réfère au pdf (slide 8) que j'ai cité pour comprendre pourquoi ce patch est nécessaire. La confusion vient de la différence entre le kernel qui à la base est "soft realtime" et les patchs d'ingo tendent à le rendre "hard realtime". Un patch d'1 mo avec 1 mec qui bosse dessus à plein temps, modifie le kernel en profondeur et fait plus que de permettre aux processes normaux comme tu dit (d'ailleurs la différence entre les process proche de l'utilisateur et les process kernel, à part le nice, je ne vois pas, suffit de lancer vlc en root pour le nicer en négatif, donc en RT selon toi) d'accéder aux fonctionnalités realtime du kernel. Pour ca, il suffit de se logguer en root et utiliser la commande rt.

Les patches RT ont aussi un effet sur les process du kernel, en slide 17 VS slide 18 sur le pdf, on a une diminution de la latence due uniquement au patch RT, qui permet de garantir la faible latence sur le slide 18 (latence contenue en dessous de 0,5 ms), contrairement au slide 17 où on voit que la latence est parfois supérieure à 3ms dans le kernel preempt, et n'est pas constante, et pourtant dans les deux cas, le code tourne en ring0.

La différence entre soft-RT et hard-RT est expliquée en slide 3, qui permet de comprendre la différence entre un kernel qui fonctionne "la plupart du temps à latence faible" en soft RT (le kernel preempt) et un kernel quasi hard RT qui garantit la latence faible.

Ensuite, l'auteur compare la latence avec d'autres types de taches (load X11 par exemple) et la conclusion est claire : le patch est efficace. Cependant, son efficacité peut dépendre des machines, comme expliqué dans le pdf. Sur le portable, ca merde.

Le patch RT permet d'implémenter des mécanismes génériques pour tous les processes (slide 8) qui permet parfois d'améliorer les perfs (slide 39) mais ce mécanisme ajoute un "overhead" qui au final diminue les perfs : on observe une diminution des performances avec le kernel RT pour le test LMBench (slide 38).
Pour illustrer une partie du patch, on peut prendre l'exemple de la "threadisation des IRQs" : dans un kernel preemptif, (slide 7) la tache suivante doit attendre la fin de la section critique, pendant laquelle l'irq est bloquée (monopolisée) pendant l'éxécution de la tache avant de commencer la tache suivante, ce qui n'est plus le cas avec un kernel RT, puisque l'irq peut être utilisée par deux taches en même temps. Ceci nécessite aussi d'autres mécanismes expliqués sur http://kerneltrap.org/node/3995?PH [...] cd664fd574 notamment la préhension des spinlocks (voir def wikipedia) ce qui permet quand un ressource matérielle est déjà bloquée de commencer tout de même l'execution d'une autre tache.

Au slide 42 on observe qu'effectivement, la plupart du temps un kernel normal suffit pour assurer une latence correcte. Cependant, le kernel RT permet d'avoir une meilleure latence donc un système plus réactif pour de fortes charges (slide 43).

Donc je répète si c'est intégré au kernel ca prouve bien la valeur générique du patch et ce patch modifie le kernel en profondeur il modifie des mécanismes critiques. Il modifie le kernel linux de soft RT vers hard RT. D'où la phrase, le kernel preempt permet une latence faible, mais il existe quand même des mécanismes bloquants, le kernel RT la garantit.

Bonne nuit :sleep:

memaster

enfoiro a écrit :

A quoi sert le patch d'ingo molnar alors :??: Comme je l'ai expliqué RT != accès en ring0

permet d'autoriser des processus de haut niveau en RT.
sur un kernel "normal" tu peux faire du nice comme tu veux mais ton processus concernéne sera jamais completement en RT.
qd je parle de processus de haut niveau, je parle d'applications proche de l'utilisateur, genre vlc ou un decodage dvd...
les processus de bas niveau, ceux occupé par des fonctions fondamentales du systeme, il est normal qu'ils tournent en RT sur des kernel non patchés.
regarde un top et tu verras ;)

enfoiro

memaster a écrit :

en même temps pas besoin d'un kernel RT pour faire tourner des processus en RT.
c'est juste qu'un kernel "normal" n'autorise pas des processus de haut niveau en priorité RT.

A quoi sert le patch d'ingo molnar alors :??: Comme je l'ai expliqué RT != accès en ring0

memaster

enfoiro a écrit :

Tout à fait d'accord.
Le kernel lowlatency permet une latence faible tandis que le kernel RT garantit cette latence faible.

Un petit lien sur la nouvelle méthode dont tu parles pour permettre un accès RT au kernel
http://alsa.opensrc.org/RealtimeKernelAndPAM

en même temps pas besoin d'un kernel RT pour faire tourner des processus en RT.
c'est juste qu'un kernel "normal" n'autorise pas des processus de haut niveau en priorité RT.

enfoiro

THRAK a écrit :

Il ne faut effectivement pas mélanger low-latency et realtime. :o
:)

memaster