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 Renault (site web personnel) . En réponse au message Utilité d'utiliser un noyau RT ?. Évalué à 10.
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.