Pourquoi choisir un noyau à faible latence plutôt qu'un noyau générique ou en temps réel ?

Il s'agit de quelques lignes directrices simples destinées à vous aider à comprendre quels sont les éléments suivants noyau, et dans quel ordre, vous devez tester pour répondre à 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 latence (par exemple pour l'enregistrement audio), veuillez utiliser le noyau -preempt comme premier choix. Cela réduit la latence mais ne sacrifie pas les fonctions d'économie d'énergie. Il n'est disponible que pour systèmes 64 bits (également appelés amd64).
• Si le noyau -preempt ne fournit pas assez de basse latence 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, essayez le noyau -rt.
• Si le noyau -rt n'est pas assez stable pour vous, vous devriez essayer le noyau -realtime.

Source d'aide Ubuntu

Cela dépend donc de ce que vous allez faire avec votre distro de studio. Pour la plupart des utilisateurs qui ont besoin d'un temps de réponse rapide, le générique fera l'affaire, pour d'autres qui ont besoin de faire du montage vidéo professionnel où même une simple perte d'image est inacceptable, le noyau temps réel est nécessaire.

Pour un article de blog plus exhaustif et facile à comprendre, lire ce lien

Je suis l'auteur du billet de blog lié par ubuntu fan : http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/

Ce billet de blog ne présente aucun fait, il est seulement théorie . C'est ainsi que cela fonctionne, en fait : le processeur "s'arrête" plus fréquemment pour voir s'il y a des processus nécessitant une attention immédiate. Cela signifie que ces processus seront exécutés avant les autres, de sorte que vous ne sauterez pas d'images lors de l'encodage, ou n'aurez pas d'énormes délais entre les clics de souris et la mort des ennemis. Cela ne signifie pas que tous les processus se termineront plus tôt : en fait, le CPU perd une plus grande partie de son temps à décider quel processus sera exécuté ensuite, et à effectuer le changement de contexte. Le temps d'exécution total est donc plus long, et c'est pourquoi personne n'utilise un noyau préemptible sur les serveurs web ou les bases de données. Mais un noyau préemptible à 300Hz (ou même 1000Hz) est le meilleur pour les serveurs de jeux.

Mais de nos jours, les processeurs ont de nombreux cœurs, de sorte que lorsqu'il y a peu de processus nécessitant de l'attention, ils peuvent facilement être alloués sur un autre cœur plutôt que d'attendre qu'un cœur le prenne.

(stackexchange me demande des références/une expérience personnelle : Je suis un ingénieur en électronique, un noobgamer assoiffé de sang qui gère plusieurs serveurs de jeux à l'adresse suivante http://www.gamezoo.it ).

Donc, en règle générale, je dirais : si votre processeur est un quad-core haute fréquence et puissant pour le traitement des nombres ET que vous n'avez pas l'habitude d'ouvrir des tonnes de pages web pendant le codage/décodage/jeu (hein), vous pouvez simplement essayer le noyau générique (ou i686, ou amd64 s'ils existent) et avoir le plus haut débit possible (c'est-à-dire le traitement brut des nombres 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 de gamme du marché, optez pour le -preempt.

Si vous êtes sur une machine bas de gamme qui n'a qu'un ou deux cœurs, alors essayez le -lowlatency. Vous pouvez également essayer -realtime, mais vous constaterez qu'il a tendance à bloquer les processus jusqu'à ce que les processus "temps réel" aient terminé leur travail. Je crois que le noyau en temps réel n'est pas le noyau "vanille", mais qu'il a le patch CONFIG_PREEMPT_RT appliqué. Je pense que les noyaux en temps réel ne sont destinés qu'à ceux qui doivent construire une seule application sur des systèmes embarqués. Les utilisateurs habituels d'ordinateurs de bureau ne devraient pas en tirer de réels avantages car ils exécutent généralement un bon nombre d'applications en même temps.

Enfin, les options du noyau les plus pertinentes si vous souhaitez recompiler vous-même votre noyau pour avoir un bureau à faible latence sont les suivantes :

PREEMPT=y

et :

CONFIG_1000_HZ=y

Pour ajouter un peu d'économie d'énergie, vous pouvez consulter celui-ci :

CONFIG_NO_HZ=y

J'ai ce vieil ordinateur portable avec deux AMD A6-4400M à 1600MHz, que j'utilise avec parcimonie lorsque je ne suis pas au bureau, principalement pour lire mes courriels et naviguer sur des sites Web occasionnels. Il y avait quelque chose, peut-être lié aux mises à jour logicielles, qui le rendait peu réactif. Quelque chose comme taper une douzaine de caractères sans voir le premier. Souvent le widget demandant si je dois forcer l'arrêt d'un processus.

Après sudo apt-get install linux-lowlatency et redémarrer, il est devenu fluide et réactif. (uname -r 5.0.0-20-lowlatency.) Merveilleux, j'aurais dû changer il y a des années. Laissez-moi insister sur la réponse de Seven : à moins que vous ne vouliez tirer le maximum d'un serveur de calcul, aller pour la -prémission !

Trois paramètres de performance majeurs régissent l'optimisation des noyaux, dont l'un est rarement discuté dans le contexte des deux autres et n'est presque jamais évalué. Cela a réduit et faussé notre perception des performances :

1. Débit : Ce qui est évalué et discuté par les médias. Il s'agit d'une mesure de la quantité de données pouvant être acheminées par le processeur dans un laps de temps donné.
2. Efficacité énergétique : Selon la façon dont on la mesure, il s'agit de savoir combien il est coûteux (en énergie ou en chaleur) de traiter une certaine quantité de données ou de maintenir un système en fonctionnement pendant une période donnée. Cela a des répercussions sur la durée de vie des batteries des ordinateurs portables et sur le coût de fonctionnement des serveurs ou d'autres matériels "toujours en service".
3. Latence : Elle n'est presque jamais évaluée, mais elle est tout aussi importante. Il s'agit de la mesure du temps moyen nécessaire à un signal ou à des données pour parcourir un chemin, généralement mesuré en millisecondes. Le terme "gigue" décrit les variations de la latence dans le temps et constitue une sous-composante de la performance de latence.

C'est un cas classique de "voici 3 options, choisissez-en deux". Vous pouvez avoir le débit et l'efficacité énergétique, mais vous sacrifiez la latence. Vous pouvez avoir un débit et une faible latence, mais vous sacrifierez l'efficacité énergétique. Vous pouvez avoir une faible latence et une efficacité énergétique, mais cela sacrifiera le débit.

Un exemple de ce compromis est la course au sommeil : https://en.wikipedia.org/wiki/Race_to_sleep . Malheureusement, il faut toujours plusieurs ms aux CPU pour se "réveiller" à partir de différents niveaux d'états de sommeil (plus le sommeil est profond, plus il faut de temps pour se réveiller), ce qui rend la mise à l'échelle de la fréquence du CPU horrible pour les performances de latence et probablement l'un des plus grands contrevenants. C'est pourquoi même les systèmes Mac OS bénéficient énormément de la désactivation de la mise à l'échelle de la fréquence du processeur pour éviter les dépassements et les sous-dépassements de la mémoire tampon (un dépassement de la mémoire tampon se produit lorsqu'un processus prend trop de temps pour se terminer et se réacheminer, et que le dernier bit est rejeté alors que la mémoire tampon se remplit à nouveau ; tandis qu'un sous-dépassement est un échec à remplir suffisamment la mémoire tampon à temps pour le traitement.)

Il y a aussi les cœurs logiques et le multithreading symétrique, qui est un sous-ensemble de la "course au sommeil" en utilisant tous les cœurs plus efficacement, mais au prix d'une augmentation du temps nécessaire à chaque processus individuel pour se terminer. Cela est également bon pour l'efficacité énergétique et le débit, mais pas pour la latence, qui concerne la fiabilité et la rapidité d'exécution des tâches individuelles "critiques", et non la somme totale des tâches.

-générique : pour tout cas d'utilisation qui ne concerne pas la latence et l'acheminement garanti d'une certaine quantité d'informations dans le processeur et vers sa destination. En général, le générique offre les meilleures performances en termes de débit et d'efficacité énergétique, mais il ne tient pas compte de la latence.

les noyaux -lowlatency, -rt et -realtime accordent une attention plus ou moins grande à la latence, avec un sacrifice ou une privatisation croissante du débit et/ou de l'efficacité énergétique. Les cas d'utilisation déterminent quels sont les plus appropriés pour quelles circonstances, et ce ne sont pas les seuls choix. Par exemple, il y a aussi https://liquorix.net/ qui prétend être optimisé pour les scénarios d'utilisation les plus courants en faisant de petits sacrifices en termes de débit pour des gains relativement importants en termes de latence.

Certains éléments de cette question se chevauchent de manière confuse avec d'autres questions, et certaines parties de cette question deviennent obsolètes à mesure que les distinctions de performance entre les lignes de noyau disparaissent. Par exemple, le noyau -générique a inclus de nombreuses optimisations à faible latence (comme PREEMPT) qui rendent les autres noyaux spécialisés encore plus spécialisés. Il est difficile de donner des chiffres précis, mais sur mon système, -generic peut maintenant gérer des latences allant jusqu'à environ 20 ms avec une certaine fiabilité (peu ou pas de dépassement ou d'insuffisance de tampon).

Je pense honnêtement que cette fragmentation existe depuis

1. un sous-produit des logiciels à code source ouvert, où l'on bifurque des lignes de noyau et des logiciels en général pour les optimiser en fonction de cas d'utilisation spécifiques (oui, "-générique" est un cas d'utilisation spécifique, mais qui se trouve couvrir la plupart des cas d'utilisation :) et
2. Ignorer presque complètement l'importance de l'ajustement des performances à faible latence pour l'expérience de l'utilisateur générique dans les paradigmes Linux et Windows.

Mac OS X est différent, et vous pouvez lire pourquoi ici : https://www.cse.unsw.edu.au/~cs9242/10/lectures/09-OSXAudiox4.pdf (c'était politique et économique, pas génial et visionnaire !). Le résultat a été un léger compromis dans les performances de débit pour un système qui gère mieux les problèmes de latence. Et c'est ainsi que Mac OS X - et son dérivé iOS - a fini par s'emparer du marché de la production multimédia numérique. Avec un seul noyau. Et les utilisateurs non multimédias ne se plaignent pas des performances de débit constamment inférieures de Mac OS X, parce que personne ne se soucie de 29 secondes contre 30 secondes pour transcoder un fichier, ou de 4,75 secondes contre 5 secondes pour lancer un programme (même les évaluateurs et les "fous de performances" ne remarquent pas ce genre d'écarts au quotidien, dans le monde réel), et tout le monde se soucie de savoir si l'interface utilisateur bégaie et si le son glisse. Il s'agit d'une question psychologique liée à l'importance de la latence et de la réactivité, et non d'une question de performance de débit (qui est la seule chose que les guerres de benchmarking considèrent), et jusqu'à présent, seul Mac OS X l'a vraiment pris sérieusement en considération dans la conception d'un système d'exploitation complet.

https://liquorix.net/ est peut-être plus en accord avec le noyau Mac en termes de priorités de performance (je suis en train de le confirmer). Et c'est la direction que prend le noyau générique, je crois (et j'espère). Ce qui sera suffisant pour 90 % des utilisateurs, à l'exception de ceux qui se trouvent aux deux extrêmes et qui ont VRAIMENT besoin a. de tout le débit possible ou b. d'une latence et d'une gigue extrêmement faibles. Et pour ces cas, il y aura toujours une sorte de noyau ou de noyaux personnalisés. Je crois que la NASA développe les siens, mais je peux me tromper :)

Extrait du document cité ci-dessus ( http://www.versalogic.com/mediacenter/whitepapers/wp_linux_rt.asp )

1. un système en temps réel souple permet de réduire le temps de latence moyen, mais pas de garantir un temps de réponse maximal.
2. Un système temps réel dur respecte les délais souhaités à tout moment (100 %), même dans le pire des cas de charge du système.
3. Selon Yaghmour [4], "le temps réel concerne les garanties, pas la vitesse brute".

L'article dit que pour les noyaux temps réel durs, la réactivité ou la limite de temps est la propriété la plus importante. Parfois, ils retardent les activités non critiques, ce qui entraîne un retard, mais pour les noyaux temps réel doux ou à faible latence, on essaie de réduire la latence générale, ce qui est utile dans la plupart des cas. Grâce à la réduction de la latence, le système semble être rapide. Lisez attentivement l'article.