memaster a écrit :
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