Hello,
 
J'ai mis ma Ubuntu à jour hier avec un kernel labellisé "linux-image-lowlatency-2.6.20-13". Ca fonctionne très bien, mais qu'est-ce que cette version patché avec les modules lowlatency apporte, en thérorie et en pratique ? Cela est-il plus intéressant qu'un kernel generic ?
J'imagine que cela inclus des patchs permettant de meilleures performances et une meilleure réactivité du système, mais j'aimerai bien savoir concrétement à quoi cela correspond. Le peu de doc que j'ai trouvé sur le net n'est pas très claire à ce sujet.
 
Merci d'avance.

ça serais pas un kernel realtime ça?

Ah ben je sais pas moi, c'est pour ça que je demande des précisions

voila un lien que tu as peut etre déjà lu, mais qui vient confirmer mon précédent post :
http://www.linuxmao.org/tikiwiki/t [...] oyau+2.6RT

La réponse que j'ai obtenue sur le topic Ubuntu à ce sujet là semble également confirmer tes dires quand à la spécialisation temps réel de ce kernel :
C'est ici que ça se passe

Ca semble n"anmoins assea adapté à un desktop d'après cette explication puisque cela vise à améliorer la réactivité du système par des accès plus rapide. Après peut être faut-il que les applications soient développées pour ?

les kernel temps réels sont adaptés pour des applications embarquées.
j'en ai un sur mon pda .
je savais pas qu'on pouvait appliquer cela pour des applications "bureautiques" maintenant.

Ben je tourne dessus depuis hier soir, mais je n'ai pas eu le temps de faire des tests de réactivité. A premières impressions, j'aurai tendance à dire que l'on ressent un léger mieux par rapport au kernel generic, mais est-ce psychologique ou réel, je ne sais pas. Dans tous les cas, je ne pense pas que cela puisse être négatif au système, donc autant en profiter.

j'attends patiemment tes impressions et tests alors

Après la MAJ de ce jour vers le kernel 2.6.20-14 de Feisty, je suis passé excluivement en lowlatency dans mon menu.lst en désinstallant tous les paquets generic. Après avoir viré powernowd qui me posait quelques problèmes de lag avec Beryl, je dois dire que le lowlatency apporte bel et bien quelque chose au système.
C'est très fluide, très réactif, et certaines applications qui traditionnellement avaient quelques lags (typiquement Gaim lors de l'ouverture d'une fenêtre de discussion) réagissent beaucoup mieux (plus aucun lag avec Gaim par exemple). J'en suis vraiment très content, on sent une réelle amélioration (pas un truc de oufs non plus), sans qu'il soit vraiment facile de décrire quoi exactement. En tout cas, c'est très agréable.

Juste pour info, mon uname -a :
Linux kortubuntu 2.6.20-14-lowlatency #2 SMP PREEMPT Mon Apr 2 20:41:03 UTC 2007 i686 GNU/Linux

je vais testé la version smp dans ce cas, j'ai actuellement besoin d'un petit "boost" supplémentaire pour decoder du mpeg4 avec vlc

Ne t'attends quand même pas à quelque chose de révolutionnaire hein

Avec un C2D, il faut la version SMP ou la version Lowlatency ?
 
Faut que je teste...

Je ne saurai pas te dire... Sur mon Turion64, j'ai installé le lowlatency et le uname -a semble indiquer une version lowlatency SMP. Je pense que ce dernier fait les deux du coup non ?

Dans ce cas... Faut plus hésiter

Je ne sais pas si le noyau lowlatency y est pour quelque chose, mais Beryl est désormais parfaitement fluide chez moi même lorsque je fais tourner Windows 2000 dans une machine virtuelle avec du travail en fond de tâche. En tout cas, c'est une preuve supplémentaire que cette Feisty fais des petits miracles

J'utilise le patch RT sur un 2.6.19 pour des serveurs qui ont besoin que la fonction nanosleep renvoie un résultat correct et c'est efficace par rapport à un kernel non patché

non bien sur mais il me manque pas grand chose pour que la lecture soit impec.
car au bout d'un moment mes 2 p3 "decrochent" endecodage de mpeg4

ca pourrait améliorer les choses en effet.
 
Il existe plusieurs implémentations visant à rendre linux realtime, précisées dans le PDF ci dessous.
En fait les différents niveaux de RT dans le patch d'ingo, permettent plusieurs stratégies pour avoir une latence faible : en gros soft RT, qui ne cherche pas à avoir une latence fixe à tout prix, et hard RT, qui garantit une réponse à latence faible mais qui n'est pas adapté pour les fortes charges car ce genre de mécanisme occupe beaucoup le proce pour avoir cette garantie (d'après ce que j'ai compris).
Et il est bien précisé dans le pdf, que le kernel RT permet une meilleure réponse.
De plus , apparemment pour la virtualisation le RT peut apporter des hausses de perf http://kerneltrap.org/node/7568
 
Pour ceux que ca intéresse :
 
Un comparo des perfs en RT / non RT (un peut dépassé, kernel 2.6.13, mais intéressant)
http://www.alsa-project.org/~iwai/ [...] l-test.pdf
 
Si vous patchez un kernel avec le patch d'ingo, lors de la configuration des options, on peut voir les différents mécanismes pour arriver à cela, entre autres les 3 niveaux de RT proposés et la configuration à laquelle ca aboutit. D'après ce que j'ai compris, ca représente 3 niveaux de préemption différents. Les techniques principalement utilisées : threading des IRQ (pour ne pas bloquer le proce lors des accès aux périphériques), spinlocks et RCU préemptifs (ne pas bloquer le kernel par les threads).
 
En regardant les patches d'ingo, on s'apercoit que c'est vraiment de la programmation de fou pour arriver à ca.
 
Définition : spinlock
http://en.wikipedia.org/wiki/Spinlock
 
Une page vieille mais intéressante
http://tree.celinuxforum.org/CelfP [...] Preemption
 
kernel RT pour la zik - gentoo
http://forums.gentoo.org/viewtopic-t-490095.html

ouais selon le moment avec vlc (surtout pendant les pub, à cause du manque d'imaes clefs je suppose) mes 2 p3 sont à la ramasse (99%) et l'image
se met à figer. sinon, ça tourne impec dans 75% du temps à environ 67%.

alors ça va etre la 1ere fois que je compil à la mano un kernel pour une distrib grand public
à moins qu'il existe des kernel-RT-smp dispo dans les contrib packages  

Compiler un kernel RT pour debian j'ai fait, mais ca merdait dans les coins. Ce qui est relou, c'est qu'ingo fournit les patches pour les versions en x.x.xx et donc que parfois, ben il y a des bugs kernel corrigés dans les versions x.x.xx-x . Tu peux ptet utiliser les packages d'ubuntu, d'après moi c'est les meilleurs pour le kernel RT : ils sont basés sur la dernière version du noyau 2.6.20 (-13) et bien testés. Ca marche nickel à la maison.

Si t'es en galère je peux poster un tuto pour faire cette compilation, mais la j'ai pas tous les éléments sous la main.

Tiens-nous au courant sur les perfs  

Je ne sais pas si tu a besoin, mais pour que les applis aient un vrai accès temps réel au noyal, il faut compiler le module realtime-lsm, et que les applis soient programmées pour s'en servir.

La commande pour lancer une appli en rt est (en root)

héhé, kernel 1000Hz powah, sa marche aussi tres bien sur des serveur tres chargé

rahhlala
https://www.redhat.com/archives/fed [...] 00211.html
ça existe pas pour fc4  
vais vraiment être obliger de faire une compil de rt smp

 
Le SMP n'apporte rien dans ton cas, je pense pas que le décodage mpeg4 de VLC soit capable d'utiliser plusieurs processeurs /cores

Je vais ptet dire une connerie mais il me semble que depuis récemment (2.6.1x), les kernels monoproc et multiproc ne sont de toute manière plus différenciés, le kernel détecte le nombre de cores au démarrage et s'adapte en fonction. A confirmer tout de même.
edit : bien sur il faut toujours activer les options smp dans la config du bouzin

 
le 1000hz seul ne suffit pas, il faut aussi le patch RT

pas pour le decodage mpeg4 (ce n'est qu'un seul thread), je sais
(encore que qd ça decode, je vois le process vlc changer de "main" régulièrement)
mais il ne fait pas que decoder du mpeg4 dans sa petite vie
je suis donc qd même obliger d'activer le smp pour mon kernel sinon je vois pas
a quoi ça servirais que j'ai un multi-proc pour n'en utiliser qu'un seul à 67% de ses capabilities...

Bon, attendez, je suis avec intérêt cette discussion mais y'a des trucs que je pige pas trop.
En résumé, un kernel RT, ça n'apporte que des avantages ? Y'a-t-il des inconvéniants ? Il me semblait comme a dit enfoiro que seules des applications désignées pour tirer parti du realtime en profitaient. Mais plusieurs d'entre vous semblent dire ou sous entendre que tout marche mieux, tout est plus réactif (notamment Kortex avec son beryl, etc...).
Alors, realtime, tout bénef ou pas ? Pour tout le système ou pas ?

à priori un kernel RT alloue un peu plus de temps processeur pour les tâches en "avant" plan.
donc il est clair que si tu n'utilises qu'une seule application très souvent, ce qui est le cas
dans les systeme embarqués (lecteur mp3 ou gps...). il est inutile de prevoir autant d'interruptions et faire le tri
dans les priorités.
il est clair qu'un systeme surchargé de petit processus ne sera pas avantagé par le RT.
moi pour mon decodage mpeg4 sur p3 1000 : un gros thread sur un seul proc, j'espere gagner
juste suffisament pour regarder la tv tranquilement, pendant
que l'autre proc travaille sur d'autres tâches moins prioritaires.
sinon je vais devoir changer mon materiel ==> $

j'avais essayé nice aussi, ça marche bien mais c'est un peu bourrin et pas pratique
(je vais pas faire un nice de vlc à chaque fois que je matte la tv)

On peut dire en tout cas, le patch RT permet d'augmenter la fréquence sur laquelle est calée le kernel (kernel timer jusqu'à 1000 Hz) et ca, ca augmente dans tous les cas la réactivité. Le souci c'est que l'apport du RT peut se faire aussi en sens inverse dans la mesure où on induit un "overhead" lié au fait qu'on complique la gestion des threads. Dans certains cas, ce n'est donc pas "rentable" mais dans une majorité d'utilisations "desktop", oui, comme celle de memaster62, le thread a un kernel qui répond dans un temps faible, mais comme l'a dit leto, vlc n'est pas optimisé smp, donc si l'overhead est trop grand les perfs pourraient même se dégrader. Au risque de le répéter, ces patches devraient rejoindre le "tree" principal du kernel, ce qui prouve la validité "générique" de ce patch.
Maintenant, pour un serveur, c'est pas la même chose, d'ailleurs même le scheduler des taches peut avoir une influence. Il me semble que le premier patch de l'approche rt apporté par ingo est le scheduler Complete Fair Queuing (CFQ) qui est au poil mais pas toujours top pour les serveurs, car pas assez conservatif.

J'ai pas encore compris la fonction de la commande "rt" c'est à éclaircir.

Bref on devrait voir des kernels plus variés dans les prochaines distribs. Un pour la maison, un pour le RT agressif, et d'autres plus conservatifs pour les purs servers. Comme sur ubuntu.

Bon sinon point de vue pratique, j'ai installé toussa et jack ne gueule plus, presque plus de xruns sauf un lors de ma dist-upgrade en faisant du MIDI en même temps  

Maintenant on attend les résultats de tes tests memaster62  

edit : memaster tu peux faire un script qui renice automatiquement ton vlc en cas de surcharge ou changer le raccourci de vlc pour que ca nice bieng

hum ceci dis je trouve ca bizard : vous parlez de RT, et de frequance ddu kernel time a 1000 hz ...
normalement, pour un os bureautique/multimedia, il vau mieu etre a 1000, par contre il ne faut p as etre en hard RT.  
Hard RT c est juste pour certain cas preci, par exemple la musique assiste par ordinateur, ou il faut des temps de reponse tres faible (moins de 20ms), alors qu on applique plusieur effects sur des son, en meme temps .
le probleme c est que ca fait ramer tout le reste du systeme.
 
Donc si vous faite pas de MAO, vous ne voulez pas etre en RT.
Maintenant je me demande comment sont configurer les kernel generic fourni par ubuntu desktop. J ai vu que par defaut , c est le scheduleur CFQ qui est choisi, ce qui laisse suposer que le kernel a ete configurer pour une utilisation bureautique/multimedia (le scheduleur CFQ est bien adapte pour ca). Donc logiquement, la frequence du kernel timer devrai etre elle par defaut a 1000 hz...
 
Si quelquun qui a une ubuntu et un kernel generic pouvai verifier ...
 
Pour finir, si il s avere que le kernel timer est a 1000, alors je conseil a tous de ne pas toucher a leur kernel et de garder le generic, deja bien optimiser pour une utilisation desktop en general.
 
Quand au kernel lowlatency, je ne voi pas trop ce que ca veu dire, peu etre que cela fait reference a l utilisation d un modure realtime-lsm, qui est en fait une utilisation ancienne pour acceder au Realtime ( pour la MAO par exemple), aujourdhui remplace par les patch RT, plus efficace.
 
A+

dans le noyau generic de feistey :
 

donc c'est du 250 hz par defaut

le truc un peu ennuyeux avec le noyau low latency d'ubuntu est qu'il est dans universe, donc a voir s'il beneficiera d'autant d'attention pour les mises a jour que le generic qui est dans main  
en tout cas, c'est le cas pour le moment

il faut installer le kernel lowlatency patché ET le module realtime-lsm qui permet aux tache d'avoir un accès RT au noyal sans être root. On le voit bien dans jack par exemple ; il ne peut pas se mettre en realtime avec un noyau patché si le module realtime-lsm n'est pas installé.
cf http://jackit.sourceforge.net/docs/faq.php
le noyau rt fonctionne ensuite comme une boite noire qui permet de diminuer la latence.
dans tous les tutos de mao, ils disent d'installer les deux. (mao-linux,demudi,64 studio...)
et je me suis gourré, pas besoin de patcher pour avoir le timer a 1000 hz    

Il ne faut effectivement pas mélanger low-latency et realtime.  
 
Il est possible d'avoir assez facilement un noyau low-latency actuellement, d'ailleurs de plus en plus de distributions fournissent leurs versions précompilées de Linux en activant ce type de fonctionnalité. Dans le pire des cas, une simple recompilation en activant les options qui vont bien permettront de bénéficier de ce mode.
 
 
Avec la commande uname -a on peut vérifier facilement si l'on est soit en low-latency, soit en realtime ou encore soit en rien du tout    
 
Par exemple :

C'est du low-latency, le terme 'PREEMPT' l'indique. Après, il est possible de plus ou moins le pousser en fonction des options qui sont activées dans la configuration du noyau.
Pour les noyaux realtime, il y aura le terme 'RT' qui figurera normalement dans la sortie du uname.
 
 
 
Niveau configuration du noyau :
 
 
1) Pour le low-latency en usage desktop, activez les options suivantes dans la rubrique Processor type and features  :

Note : si vous utilisez un système SMP (cela concerne plus particulièrement les vrais systèmes multi-processeurs, c'est moins évident pour les processeurs multi-coeurs) il est recommandé de ne pas dépasser 300 HZ pour le Timer Frequency, même en cas d'usage desktop. Comme cela à déjà été indiqué, un temps d'interruption trop court sur ce type de système va entraîner une dégradation des performances en raison d'un 'overhead' (trop d'interruptions).
 
 
2) Pour le realtime, il faut d'abord se procurer le patch RT qui va bien (utiliser de préférence les patchs fournis avec sa distribution, sinon utiliser des sources vanilla du noyau + le patch RT), ensuite dans les options c'est identique au low-latency, sauf pour l'option ajoutée par le patch qu'il faut activer :

À partir de là, vous disposez d'un noyau temps réel, mais il se pose un dernier problème : l'utilisation des applications en temps réel. En effet, pour avoir accès au fonctionnalités temps réel, les applications doivent s'exécuter en mode noyau, ce qui nécessite les privilèges de root et vont donc poser un certain nombre de problèmes lié à la sécurité.
 
Pour résoudre cela, il faut recourir à Realtime-lsm, un module permettant d'exécuter les applications à la priorité temps réel avec un minimum de sécurité. À noter que cette méthode est considéré désormais obsolète et remplacée par une solution plus sûre basé sur PAM (Pluggable Authentication Module) via rlimits (cf. RT-rlimits).
 
 

bon j'ai essayé plein de trucs :
nice a donf en root et ça decroche encore au bout d'un moment.
je vois qu'il y a des process qui sont en RT, je ne sais pas encore comment ils font.
j'ai overclocké un peu les proc ça s'ameliore encore mais ça decroche toujours, je me demande si ma version de ffmpeg n'est pas en cause?
je pense que je vais devoir investir dans du matos vraiment plus perfo...

J'ai testé le rt8 pour kernel 2.6.20 hier, la compilation se passe bien mais le uname -a me retourne toujours un preempt et il m'est impossible d'installer le pilote graphique nVidia.

@memaster62 : Je ne sais pas exactement quel est le but de ton encodage temps réel, mais, sachant la médiocrité d'un encodage une passe par rapport à un encodage deux passes, ne ferais tu pas mieux d'encoder en mpeg2 (par exemple) en temps réel pour réencoder ensuite ton flux en mpeg4, en xvid et pas via ffmpeg (le xvid c'est mieux quand même) et en deux passes pour faire les choses vraiment proprement ?
 
Sinon, pour avoir bidouillé un peu mencoder, je pense que jouer avec les paramètres d'encodage de ffmpeg peut te faire gagner des cycles...

   
en fait c'est du decodage temps réel, j'ai bidouillé deja les parametres decodage ffmpeg sans succès,
j'ai essayé avec mplayer aussi, mais il est moins bon que vlc.
je vais devoir changer de matos

raaahhhhlala,
j'ai tiré un cable de 20m pour relier mon ordi "plus puissant" (celeron 2.8Ghz, bon ok on rigole pas  
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 , il va bientot me falloir un core2duo pour decoder/afficher en temps réel du mpeg4