Bonjour,
Je vois fleurir sur le web des avis qui suggèrent d'activer le noyau "temps réel" (real time ou RT) qui serait bienvenu pour un usage bureautique et/ou jeu (gaming).
Debian (13 "Trixie") rend l'activation de cette option assez facilement, puisqu'il suffit d'ajouter l'option "preempt=full" dans le fichier de configuration de GRUB (/etc/default/grub) à la ligne "GRUB_CMDLINE_LINUX_DEFAULT=" et de redémarrer.
exemple :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash preempt=full"
Quel serait l'intérêt de ce paramétrage ? Mais quels en seraient les inconvénients (s'il y en a) ?
# Explications
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Les modèles de prémption du noyau Linux https://wiki.linuxfoundation.org/realtime/documentation/technical_basics/preemption_models
On a donc bien l'explication que "full" donne un système d'exploitation temps réel.
L'idée, si je comprends bien, est que si de multiples tâches sont en cours, et que l'on a assez de cœurs processeur (probablement le cas de tout CPU désormais) on peut améliorer la latence (disons une vidéo plus fluide par exemple), éventuellement au détriment du débit de données traités (la recherche sur disque un peu plus lente car la vidéo sera privilégiée par exemple).
Pour du jeu ou de la MAO, ça me paraît assez logique sur le papier ; pour de la bureautique je ne vois pas trop pourquoi. D'autres seront sans doute à même de préciser/détailler.
Il y a des noyaux RT chez Debian sinon
https://packages.debian.org/search?suite=trixie&searchon=all&keywords=PREEMPT_RT
[^] # Re: Explications
Posté par Renault (site web personnel) . Évalué à 10 (+8/-0).
Le temps réel pour la bureautique n'est pas nécessaire. Ni même pour les jeux vidéo.
En fait le concept de temps réel pour un système d'exploitation est une notion plutôt industrielle et peu intuitive. L'idée est qu'un système d'exploitation réalise de nombreuses tâches provenant de plein de sources d'entrées (clavier, souris, réseau, autres) et doit aussi permettre d'exécuter des processus divers.
Sauf que dans de nombreux cas, on souhaite avoir la garantie que les entrées et que certains processus soient exécutés au plus tard dans (par exemple) 10 millisecondes. Dans le milieu industriel les cas d'exemple sont légions, on peut penser à un système pour lequel on souhaite que des vérifications ou procédures d'arrêt puissent s'exécuter dans tous les cas à une vitesse assez vite.
C'est le cas aussi dans certains protocoles avec des timings très précis, par exemple dans un projet industriel sur lequel je travaille, il faut être capable de renvoyer sur le port série une réponse 6 millisecondes au plus tard (et 3 millisecondes au plus tôt) après une requête. Sans temps réel, il est facile pour Linux de manquer ces objectifs et donc la communication va avoir beaucoup de rater selon l'état du système. Avec le temps réel on peut dire au noyau "ce processus a des contraintes temps réels" et le noyau fera en sorte que les réponses sortent à la bonne cadence pour respecter le protocole.
Cependant cette garantie de temps de réaction se fait souvent de manière contre intuitive au détriment de la performance brute. En fait on essaye de borner la latence maximale dans le pire cas du système mais pour cela on augmente en général la latence moyenne. L'utilisateur bureautique souhaite en général qu'en moyenne cela soit le plus rapide possible, et de temps en temps si le système a une latence un peu plus longue au niveau du système cela n'a aucune importance. D'autant plus que dans la majorité des cas, le soucis n'est pas au niveau de l'OS mais est au niveau applicatif.
Pour la MAO cela a du sens car la moindre latence en dehors de la limite acceptable dans le traitement du son peut se répercuter dans le rendu final. Mais c'est de moins en moins vrai avec l'amélioration des performances globales de la machine qui font que les situations où on est hors des clous pour ce cas d'usage sont de plus en plus rare même sans temps réel dur.
[^] # Re: Explications
Posté par Maderios . Évalué à 3 (+1/-0).
Chez Arch officiel, deux types de noyaux RT: linux-rt 6.14.0.rt3.arch1-1 et linux-rt-lts 6.6.87.rt54.arch1-1 (version longue durée)
https://archlinux.org/packages/?sort=&q=linux-rt&maintainer=&flagged=
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.