Pourquoi choisir un noyau à faible temps de latence plutôt qu’un noyau générique ou en temps réel?
Après avoir installé Ubuntu Studio 12.04, j'ai découvert qu'il utilise un noyau à faible latence. J'ai cherché pourquoi et comment revenir à un temps réel ou générique. Mais on dirait que cette partie de Linux n’a pas été autant couverte.
Q: Pourquoi choisir un noyau à faible latence plutôt qu’un noyau générique ou en temps réel?
PS: J'ai déjà lu les réponses de this question et this post.
Voici quelques instructions simples fournies pour vous aider à comprendre quel noyau et dans quel ordre vous devez tester pour vous adapter à votre cas d'utilisation.
- Si vous n’avez pas besoin d’une faible latence pour votre système, veuillez utiliser le noyau générique.
- Si vous avez besoin d’un système à faible temps de latence (par exemple, pour l’enregistrement audio), veuillez utiliser le noyau -preempt en premier lieu. Cela réduit la latence mais ne sacrifie pas les fonctionnalités d'économie d'énergie. Il est disponible uniquement pour les systèmes 64 bits (également appelé AMD64).
- Si le noyau -preempt ne fournit pas assez de latence faible pour vos besoins (ou si vous avez un système 32 bits), vous devriez essayer le noyau -lowlatency.
- Si le noyau -lowlatency ne suffit pas, vous devriez essayer le noyau -rt
- Si le noyau -rt n'est pas assez stable pour vous, vous devriez essayer le noyau -realtime
https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel
Je suppose que cela dépend de ce que vous ferez avec votre studio distro. Pour certains utilisateurs, générique fera l'affaire, pour d'autres, ce ne sera pas le cas.
FREEDOM SPEECH, essayez de lire ce lien: http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/
Je suis l'auteur de l'article de blog lié par un fan d'ubuntu: http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/
Ce billet de blog ne présente aucun fait, c'est seulement la théorie . En fait, c'est ainsi que fonctionne le processeur: le processeur "s'arrête" plus souvent pour voir si certains processus nécessitent une attention immédiate. Cela signifie que ces processus seront exécutés avant les autres, vous ne passerez donc pas d'images lors de l'encodage, ni de longs délais entre les clics de souris et les morts de l'ennemi. Cela ne signifie pas que tous les processus se termineront plus tôt: en réalité, le processeur perd une plus grande partie de son temps à décider quel processus sera exécuté ensuite et à effectuer le changement de contexte. Le temps total d’exécution est donc plus long, raison pour laquelle personne n’exécute de noyau préemptible sur les serveurs de serveur Web ou de base de données. Mais un noyau préemptible de 300 Hz (voire de 1000 Hz) est le meilleur pour les serveurs de jeux.
Mais de nos jours, les processeurs ont plusieurs cœurs. Ainsi, lorsque peu de processus requièrent une attention particulière, ils peuvent facilement être attribués à un cœur différent plutôt que d’attendre qu’un cœur le prenne.
(stackexchange me demande références/expérience personnelle: je suis un ingénieur électronicien, un noobgamer sanguinaire possédant plusieurs serveurs de jeu sur http://www.gamezoo.it ).
Donc, en règle générale, je dirais: si votre processeur est un quadricœur à haute fréquence puissant et encombrant ET que vous n'ouvrez généralement pas des tonnes de pages Web lors du codage/décodage/jeu (hein), vous pourriez Il suffit d’essayer le noyau générique (ou i686, ou AMD64 s’ils existent) et d’avoir le débit le plus élevé possible (c’est-à-dire le traitement brut des chiffres que le processeur est capable de faire). Si vous rencontrez des problèmes (ils devraient vraiment être mineurs) ou si votre machine est légèrement moins puissante que le haut du marché, optez pour la prévention.
Si vous êtes sur une machine bas de gamme qui n’est équipée que d’un ou deux cœurs, essayez -lowlatency. Vous pouvez également essayer le -realtime, mais vous constaterez qu'il tend à bloquer les processus jusqu'à ce que ceux "en temps réel" aient terminé leur travail. Je crois que le noyau temps réel n’est pas celui de "Vanilla", mais il a le correctif CONFIG_PREEMPT_RT appliqué. Je pense que les noyaux temps réel ne sont destinés qu'à ceux qui doivent créer une seule application sur des systèmes embarqués. Par conséquent, les utilisateurs de bureau classiques ne devraient pas bénéficier d'avantages réels, car ils exécutent généralement un nombre non négligeable d'applications.
Enfin, les options de noyau les plus pertinentes si vous souhaitez recompiler vous-même votre noyau afin de disposer d’un bureau à faible latence sont les suivantes:
PREEMPT=y
et:
CONFIG_1000_HZ=y
Pour ajouter un peu d'économie d'énergie, vous pouvez vérifier celui-ci:
CONFIG_NO_HZ=y
BTW: preempt-, low latency ou le noyau RT ne rendra pas votre système plus rapide. Ils sont légèrement plus lent que le noyau générique.
Extrait du document cité ci-dessus ( http://www.versalogic.com/mediacenter/whitepapers/wp_linux_rt.asp )
- un système en temps réel mou donnera une latence moyenne réduite mais pas un temps de réponse maximum garanti.
- Un système en temps réel difficile respecte les délais souhaités à tout moment (100%), même lorsque la charge du système est la plus défavorable.
- Selon Yaghmour [4], "Le traitement en temps réel des garanties, pas de la vitesse brute".
L'article indique que, pour le noyau dur en temps réel, la propriété la plus importante est la propriété la plus importante. Par conséquent, ils retardent parfois les activités non critiques qui entraînent un retard, mais pour le noyau à faible latence ou un autre noyau temps réel souple, essayez de réduire la latence générale, ce qui est utile dans la plupart des cas. En raison de la latence réduite, le système semble être rapide. Lisez attentivement l'article.