Question Pourquoi choisir un noyau à faible latence par rapport à un noyau générique ou temps réel?


Après avoir installé Ubuntu Studio 12.04, j'ai constaté qu'il utilisait 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é tellement couverte.

Q: Pourquoi choisir un noyau à faible latence par rapport à un noyau générique ou temps réel?

PS: j'ai déjà lu les réponses de ce question et ce poster.


93
2018-04-28 03:09


origine


+1 car ce doit être une très bonne question si tout le monde est déconcerté. Je ne sais toujours pas la différence entre les noyaux à faible latence, génériques et en temps réel. Si -realtime est en temps réel, alors qu'est-ce que -rt représenter? Et quoi de neuf avec le -preempt noyau? Je vais remercier gemue2010, il a fait un très bon travail en l'expliquant, mais ça n'explique toujours pas tout. - Hitechcomputergeek


Réponses:


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

  • Si vous n'avez pas besoin d'une faible latence sur votre système, veuillez utiliser le noyau -generic.
  • Si vous avez besoin d'un système à faible latence (par exemple pour l'enregistrement audio), utilisez le noyau -preempt comme premier choix. Cela réduit la latence   mais ne sacrifie pas les fonctionnalités d'économie d'énergie. Il est disponible uniquement pour   Systèmes 64 bits (également appelés amd64).
  • Si le noyau -preempt ne fournit pas suffisamment de latence pour vos besoins (ou si vous avez un système 32 bits), vous devriez essayer le   noyau de basse fréquence.
  • 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

https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel

Je suppose que cela dépend de ce que vous ferez avec votre studio de distribution. Pour certains utilisateurs, les génériques feront tout simplement l'affaire, d'autres pas.

FREEDOM SPEECH, essayez de lire ce lien: http://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf/


55
2018-04-28 03:21



J'ai déjà lu l'article précédent que vous avez posté. A propos de la seconde, combien sont fiables ces faits? - Starx
Eh bien, les tests mentionnés ici parlent d'eux-mêmes. Si l'équipe Ubuntu a choisi Latency en premier lieu, cela doit être une raison. Donc, vous vouliez connaître les différences, maintenant vous faites. Problème résolu ? - ubuntu fan
Non .. Je ne pense pas que le problème soit résolu. Si votre réponse fait quelque chose, cela augmente davantage ma curiosité. - Starx
Est-ce que l'une de ces choses est encore vraie en 2015? le -preempt, -rt, et -realtime les noyaux n'existent plus - naught101


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

Ce blog ne présente aucun fait, c'est seulement théorie. C'est comme ça que ça marche, en fait: le processeur «s'arrête» plus fréquemment pour voir si certains processus nécessitent une attention immédiate. Cela signifie que ces processus seront exécutés avant les autres, afin de ne pas ignorer les images lors du codage ou d’avoir des délais importants entre les clics de souris et les décès d’ennemis. Cela ne signifie pas que tous les processus se termineront plus tôt: en fait, le processeur perd une plus grande partie de son temps à décider quel processus sera exécuté ensuite et à changer de contexte. Le temps d'exécution total est donc plus long, et c'est pourquoi personne ne lance un noyau préemptible sur les machines de serveur Web ou de base de données. Mais un noyau préemptible de 300Hz (ou même 1000Hz) est le meilleur pour les serveurs de jeux.

Mais, de nos jours, les processeurs ont de nombreux cœurs. Par conséquent, lorsque peu de processus requièrent une attention particulière, ils peuvent facilement être alloués sur un autre noyau plutôt que d'attendre qu'un noyau les prenne en charge.

(stackexchange me demande des références / expérience personnelle: je suis un ingénieur en électronique, noobgamer assoiffé de sang qui conserve plusieurs http://www.gamezoo.it ).

Donc, en règle générale, je dirais: si votre processeur est un puissant quad-core haute fréquence et que vous n'ouvrez généralement pas des tonnes de pages Web lors de l'encodage / décodage / jeu (hein), vous pouvez il suffit d'essayer le noyau générique (ou i686 ou amd64 s'il existe) et d'avoir le débit le plus élevé possible (c.-à-d. le nombre brut que le processeur peut faire). Si vous rencontrez des problèmes (ils doivent vraiment être mineurs) ou si votre ordinateur est légèrement moins puissant que le haut du marché, optez pour le pré-test.

Si vous êtes sur un ordinateur bas de gamme qui ne dispose que d'un ou deux cœurs, essayez l'option -lowlatency. Vous pouvez également essayer le mode -realtime, mais vous constaterez qu'il a tendance à 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 le noyau "vanille", mais que le correctif CONFIG_PREEMPT_RT est appliqué. Je pense que les noyaux en temps réel sont uniquement destinés à ceux qui doivent créer une application unique sur les systèmes embarqués, de sorte que les utilisateurs de bureau habituels ne devraient pas avoir de réels avantages car ils exécutent généralement un grand nombre d'applications en même temps.

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

PREEMPT=y

et:

CONFIG_1000_HZ=y

Pour ajouter une économie d'énergie, vous pouvez vérifier celle-ci:

CONFIG_NO_HZ=y

45
2017-10-24 20:27



J'ai remarqué que vous mentionnez la maintenance des serveurs, j'essaie de trouver le meilleur noyau pour le serveur dédié aux sources de vannes (CSGO en particulier). la plupart des threads CS que je trouve sont liés à goldsrc qui nécessitait un noyau 1000Hz. Avec srcds, est-ce que lowlatency est mauvais? Si ce n'est pas grave, je m'en tiendrai à la lowlatency car c'est ce que j'ai maintenant (j'isole les cœurs de processeurs pour les serveurs srcds à 128 ticks car cela ne profite pas vraiment du multi threading). - Vincent De Smet
Utile pour connaître ces astuces, je changerai totalement pour préempter. Je ne suis pas si pressé que je veuille que mon noyau agisse comme un sale pirate. - userDepth


BTW: preemt-, lowlatency ou le noyau rt ne rendra pas votre système plus rapide. Ils sont légèrement Ralentissez que le noyau générique.


6
2018-04-28 03:53



Pouvez-vous expliquer votre raisonnement ou donner des sources? - hexafraction
Vouliez-vous dire ma réponse ObsessiveFOSS? Réponse courte: parce qu’elle introduit plus de surcharge dans le noyau. Vous pouvez lire cet article intéressant si vous souhaitez obtenir plus d'informations: versalogic.com/mediacenter/whitepapers/wp_linux_rt.asp - gemue2010
mauvaise formulation. "Plus rapide" pourrait signifier un débit ou une latence. - Eero Aaltonen
C'est un abus de langage bien que, dans de nombreux contextes, cela soit logique pour que les gens y soient habitués. Le contexte principal est le jeu où la moyenne des images par temps dénote la «vitesse» (un noyau à faible latence abaissera cette moyenne mais la latence sera meilleure). - j riv


D'après le 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 un temps de réponse maximal garanti.
  2. Un système dur en temps réel respecte les délais souhaités à tout moment (100%), même dans les pires conditions du système.
  3. Selon Yaghmour [4], "le temps réel traite des garanties, pas de la vitesse brute".

L’article dit que pour le noyau temps réel, la réactivité sans noyau ou la limite de temps est la propriété la plus importante. Ils retardent parfois les activités non critiques qui entraînent des retards, mais réduisent la latence générale qui aide dans la plupart des cas. En raison de la latence réduite, le système semble être rapide. Lisez l'article attentivement.


2
2017-08-17 05:34



C'est vrai, mais nous avons besoin de savoir quelle variante du noyau correspond à quelle «dureté» du système en temps réel. - Melebius