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

Voici quelques directives simples fournies pour vous aider à comprendre quel noyau, et dans quel ordre, vous devriez tester pour correspondre à votre cas d'utilisation.

• Si vous n'avez pas besoin d'une faible latence pour votre système, veuillez utiliser le noyau -generic.
• Si vous avez besoin d'un système à faible latence (par exemple pour l'enregistrement audio), veuillez utiliser le noyau -preempt en premier choix. Cela réduit la latence sans sacrifier les fonctionnalités d'économie d'énergie. Il est disponible uniquement pour les systèmes 64 bits (également appelés amd64).
• Si le noyau -preempt ne fournit pas une latence suffisamment faible pour vos besoins (ou si vous avez un système 32 bits), alors vous devriez essayer le noyau -lowlatency.
• Si le noyau -lowlatency ne suffit pas, alors vous devriez essayer le noyau -rt.
• Si le noyau -rt n'est pas assez stable pour vous, alors vous devriez essayer le noyau -realtime.

Source d'aide Ubuntu

Donc, tout dépend de ce que vous ferez avec votre distribution studio. Pour la plupart des utilisateurs ayant besoin d'une réponse rapide de l'utilisateur final, le générique fera parfaitement l'affaire. Pour les autres ayant besoin de faire du montage vidéo professionnel où même une simple perte d'image est inacceptable, le noyau en temps réel est nécessaire.

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

Je suis l'auteur du billet 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, il s'agit uniquement d'une théorie. C'est la façon dont cela fonctionne en réalité : 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 n'aurez pas de sauts d'image lors de l'encodage, ni de gros délais entre les clics de souris et les morts 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 la commutation de contexte. Ainsi, le temps total d'exécution est plus long, c'est pourquoi personne n'exécute de noyau préemptif sur des serveurs web ou des machines de base de données. Mais un noyau préemptif à 300 Hz (ou même 1000 Hz) est le meilleur pour les serveurs de jeux.

Mais de nos jours, les processeurs ont de nombreux cœurs, donc lorsque peu de processus nécessitent une attention, ils peuvent facilement être alloués à un autre cœur plutôt que d'attendre qu'un cœur les prenne.

(stackexchange exige des références ou des expériences personnelles : je suis ingénieur électronique, noobgamer sanguinaire gérant plusieurs serveurs de jeux sur http://www.gamezoo.it).

Donc, en règle générale, je dirais : si votre processeur est un quad-core puissant à haute fréquence pour le calcul intensif ET que vous n'ouvrez généralement pas des tonnes de pages web pendant l'encodage/décodage/jeu (huh), vous pourriez simplement essayer le noyau générique (ou i686, ou amd64 s'ils existent) et obtenir le débit le plus élevé possible (c'est-à-dire le calcul intensif brut 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, optez pour le -preempt.

Si vous êtes sur une machine bas de gamme qui a un ou deux cœurs seulement, essayez alors le -lowlatency. Vous pouvez également essayer le -realtime, mais vous verrez qu'il a tendance à bloquer les processus jusqu'à ce que les processus "temps réel" aient terminé leur tâche. Je crois que le noyau en temps réel n'est pas le "standard", mais a le correctif CONFIG_PREEMPT_RT appliqué. Je pense que les noyaux temps réel ne sont destinés qu'à ceux qui doivent construire une application unique sur des systèmes embarqués, donc les utilisateurs de bureau classiques ne devraient pas en tirer réellement de bénéfices car ils exécutent généralement un bon nombre d'applications en même temps.

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

PREEMPT=y

et :

CONFIG_1000_HZ=y

Pour ajouter des économies d'énergie, vous pouvez vérifier celui-ci :

CONFIG_NO_HZ=y

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

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

Il existe trois principaux paramètres de performance qui régissent l'optimisation du noyau, dont l'un est rarement discuté dans le contexte des deux autres et presque jamais soumis à des tests de référence. Cela a réduit et faussé notre perception de la performance :

1. Le débit : Ce qui est testé et discuté par les médias. Une mesure de la quantité de données pouvant passer à travers le processeur dans un laps de temps donné.
2. Efficacité énergétique : Ce qui est également souvent testé ; en fonction de la manière dont vous le mesurez, le coût (en énergie ou en chaleur) pour traiter une certaine quantité de données ou pour maintenir un système en fonctionnement sur une certaine période de temps. Cela a des répercussions à la fois sur la durée de vie de la batterie des ordinateurs portables et sur le coût de fonctionnement des serveurs ou d'autres matériels "toujours actifs".
3. Latence : Presque jamais testée, mais tout aussi importante. C'est une mesure du temps moyen nécessaire à un signal ou à des données pour voyager à travers un chemin, généralement mesuré en millisecondes. Le mot "jitter" décrit les variations de latence au fil du temps, et est un sous-composant de la performance en matière de latence.

Il s'agit d'un cas classique de "voici 3 options, choisissez-en 2". Vous pouvez avoir le débit et l'efficacité énergétique, mais au détriment de la latence. Vous pouvez avoir le débit et une faible latence, mais au détriment de l'efficacité énergétique. Vous pouvez avoir une faible latence et une efficacité énergétique, mais cela se fera au détriment du 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 millisecondes aux CPU pour "se réveiller" de différents niveaux d'états de veille (plus le sommeil est profond, plus il faut de temps pour se réveiller), ce qui rend l'échelle de fréquence du CPU horrible en termes de performances en matière de latence et probablement l'une des plus grandes sources de problèmes. C'est pourquoi même les systèmes Mac OS bénéficient énormément de la désactivation de l'échelle de la fréquence du CPU pour éviter les dépassements et les sous-dépassements de tampon (un dépassement de tampon se produit lorsque le traitement prend trop de temps pour se terminer et se rerouter, et donc la dernière partie est jetée car le tampon se remplit ; tandis qu'un sous-dépassement se produit lorsqu'il n'y a pas suffisamment de remplissage du tampon à temps pour le traitement. les deux sont couramment appelés "xruns" et indiquent une perte potentielle de données)

Un autre exemple est constitué par les cœurs logiques et le multi-threading symétrique, qui est un sous-ensemble de la "course au sommeil" en utilisant tous les cœurs de manière plus efficace, mais au prix d'augmenter le temps nécessaire à l'achèvement de chaque processus individuel. Cela est également bon pour l'efficacité énergétique et le débit, mais pas pour la latence, qui est liée à la manière dont des tâches individuelles "critiques pour la mission" peuvent être accomplies de manière fiable et rapide, et non à un groupe total de tâches.

-générique : pour tout cas d'utilisation n'impliquant pas de latence et de routage garanti d'une certaine quantité d'informations dans le processeur et vers leur destination. Le mode générique fournit en général les meilleures performances en termes de débit ainsi que d'efficacité énergétique, mais dépriorise la latence

les noyaux -lowlatency, -rt et -temps réel offrent des nuances variables d'attention accrue à la latence, au détriment croissant ou à la dépriorisation du débit et/ou de l'efficacité énergétique. Les cas d'utilisation déterminent lesquels sont les plus adaptés à quelles circonstances, et ce ne sont pas les seules options. Par exemple, il y a aussi https://liquorix.net/ qui prétend être optimisé pour la plupart des scénarios d'utilisation courants en faisant de petits sacrifices en matière de débit pour des gains relativement importants en performances de latence.

Il y a des éléments de cette question qui se chevauchent de manière confuse avec d'autres questions, et certains éléments de cette question deviennent obsolètes alors que les distinctions de performance entre les lignes de noyaux disparaissent. Par exemple, le noyau -generic 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, le noyau -générique peut désormais gérer des latences d'environ 20 ms avec une certaine fiabilité (aucun ou peu de dépassements ou de sous-dépassements de tampon).

Je pense honnêtement que cette fragmentation découle :

1. d'un sous-produit des logiciels open source, où vous obtenez une divergence des lignes de noyaux et des logiciels en général pour les optimiser pour des cas d'utilisation spécifiques (oui, "-generic" est un cas d'utilisation spécifique, juste un qui couvre spécifiquement la plupart des cas d'utilisation :) et
2. du fait de pratiquement ignorer l'importance de l'optimisation des performances en matière de latence pour l'expérience de l'utilisateur -generic 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 un génie ou une vision!). Le résultat a été un léger compromis en termes de performances de débit pour un système qui gère mieux les problèmes de latence. Ainsi, Mac OS X -- et sa déclinaison iOS -- ont fini par dominer le marché de la production multimédia numérique. Avec un seul noyau. Et les utilisateurs non-multimédia ne se plaignent pas des performances de débit de Mac OS X constamment inférieures, car personne ne se soucie réellement d'avoir 29 sec contre 30 sec pour transcoder un fichier, ou de 4.75 sec contre 5 sec pour démarrer un programme (même les testeurs de performance et les "fanatiques de la performance" ne remarquent pas ce genre de disparités au quotidien, et tout le monde se soucie de savoir si l'UX donne des saccades et si l'audio présente des problèmes. C'est une question psychologique liée à l'importance de la latence et de la réactivité, et non une question de performances de débit (qui est la seule chose que les guerres des benchmarks considèrent), et jusqu'à présent seul Mac OS X a vraiment pris en compte cela dans la conception de tout un système d'exploitation.

https://liquorix.net/ pourrait être plus en phase avec le noyau de Mac en termes de ses priorités de performances ajustées (je le confirme actuellement). Et c'est la direction que prend le noyau -generic, je crois (et j'espère). Ce sera suffisant pour 90 et quelques pourcent des utilisateurs, sauf ceux aux extrêmes qui ont VRAIMENT besoin d'un. Tout le débit dont ils peuvent disposer ou b. d'une latence et d'une jittering sans problèmes. Et pour ces cas, il y aura toujours une sorte de noyau ou de noyaux personnalisés. Je crois que la NASA crée ses propres noyaux, mais je pourrais me tromper :)

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

1. Un système temps réel souple donnera une latence moyenne réduite mais pas de temps de réponse maximal garanti.
2. Un système temps réel dur respecte les échéances souhaitées à tout moment (100 %), même sous une charge système maximale.
3. Selon Yaghmour [4], "Le temps réel traite des garanties, pas de la vitesse brute."

L'article affirme que pour un noyau dur en temps réel, la réactivité ou la limitation du temps est la propriété la plus importante, donc parfois ils retardent des activités non critiques, ce qui entraîne des retards, mais pour les noyaux soft en basse latence ou d'autres systèmes temps réel doux, ils essaient de réduire la latence générale, ce qui aide dans la plupart des cas. En raison de la réduction de la latence, le système semble rapide. Lisez attentivement l'article.