Il faut d'abord rappelé qu'il faut que les logiciels soient écrits pour être temps réel,
Pour en tirer pleinement bénéfice, oui.
Mais les effets d'un noyau temps réels s'appliquent même si tes applications ne sont pas conçues dans cette optique.
C'est d'ailleurs aussi le problème, activer le temps réel sur un système où ça n'a pas d'intérêt peut réduire les performances globales car tu mets en place des restrictions qui n'ont pas de sens dans ce contexte.
Cependant il est possible que les moteurs de jeux ou d'autres puissent l'être.
Non, les OS grands publics tels que Windows ou macOS et même Linux jusqu'à récemment n'étaient pas temps réels durs. Peu d'intérêt de les développer avec cela en tête, surtout que les contraintes du JV sont souvent mou (si ton PC est trop lent, on saute une frame et voilà).
Typiquement, je ne pense pas que le navigateur soit conçu temps réel, il risque donc de souffrir car il ne préemptera pas or c'est le soft n°1 aujourd'hui.
Système temps réel n'implique pas préemption collaborative, c'est même jamais le cas sinon tu n'as que peu de moyen de garantir un délai d'exécution bornée.
D'ailleurs le fait que le noyau ne rendait pas la main dans certains cas (notamment lors des communications sur port séries / terminaux) était une limitation de Linux dans ce domaine et qui faisait qu'il fallait se trimballer le correctif RT pour lever ces obstacles.
Pour un PC de jeux, c'est peut-être utile pour améliorer la réactivité...
Mon message explique que globalement c'est faux. Tu donnes des garantie de réactivité minimale, mais souvent au détriment de la réactivité moyenne.
Puis bon le concept de temps réel alors qu'on implique un composant aussi complexe qu'un GPU à côté qui fait lui même des calculs très sophistiqués, c'est tout un programme. :D
Mais si tu en a tu peux petut-être gagner des mili-secondes au mouvement de souris
Non.
Car dans un JV le pipeline est très spécifique : entrée (souris) -> calculs d'actions -> rendu de l'image -> affichage sur écran en boucle. Le fait de capturer le mouvement de la souris un peu plus tôt n'a pas forcément d'impact si le JV est aux étapes suivantes dans sa suite de calcul. Cela sera toujours pris en compte pour la frame suivante.
En fait pour le JV ce n'est pas le temps réel qui compte vraiment, c'est l'ordonnancement global. Pour notamment s'assurer que tu n'interromps pas le JV pour d'autres tâches subsidiaires au mauvais moment. Ou que par exemple dans ta pile de threads qui compose ton jeu certains soient réveillés pour rien ou à un moment par propice car ce n'est pas le bon moment selon le statut du pipeline.
Il y a des démos de setup d'ordonnancements maisons avec sched_ext (en gros pouvoir modifier l'ordonnancement du noyau à la volée de manière sûre) dans le cadre des jeux et les gains étaient largement possibles en jouant dessus. Aucun rapport avec le temps réel cependant.
[^] # Re: Explications
Posté par Renault (site web personnel) . En réponse au message Utilité d'utiliser un noyau RT ?. Évalué à 6.
Pour en tirer pleinement bénéfice, oui.
Mais les effets d'un noyau temps réels s'appliquent même si tes applications ne sont pas conçues dans cette optique.
C'est d'ailleurs aussi le problème, activer le temps réel sur un système où ça n'a pas d'intérêt peut réduire les performances globales car tu mets en place des restrictions qui n'ont pas de sens dans ce contexte.
Non, les OS grands publics tels que Windows ou macOS et même Linux jusqu'à récemment n'étaient pas temps réels durs. Peu d'intérêt de les développer avec cela en tête, surtout que les contraintes du JV sont souvent mou (si ton PC est trop lent, on saute une frame et voilà).
Système temps réel n'implique pas préemption collaborative, c'est même jamais le cas sinon tu n'as que peu de moyen de garantir un délai d'exécution bornée.
D'ailleurs le fait que le noyau ne rendait pas la main dans certains cas (notamment lors des communications sur port séries / terminaux) était une limitation de Linux dans ce domaine et qui faisait qu'il fallait se trimballer le correctif RT pour lever ces obstacles.
Mon message explique que globalement c'est faux. Tu donnes des garantie de réactivité minimale, mais souvent au détriment de la réactivité moyenne.
Puis bon le concept de temps réel alors qu'on implique un composant aussi complexe qu'un GPU à côté qui fait lui même des calculs très sophistiqués, c'est tout un programme. :D
Non.
Car dans un JV le pipeline est très spécifique : entrée (souris) -> calculs d'actions -> rendu de l'image -> affichage sur écran en boucle. Le fait de capturer le mouvement de la souris un peu plus tôt n'a pas forcément d'impact si le JV est aux étapes suivantes dans sa suite de calcul. Cela sera toujours pris en compte pour la frame suivante.
En fait pour le JV ce n'est pas le temps réel qui compte vraiment, c'est l'ordonnancement global. Pour notamment s'assurer que tu n'interromps pas le JV pour d'autres tâches subsidiaires au mauvais moment. Ou que par exemple dans ta pile de threads qui compose ton jeu certains soient réveillés pour rien ou à un moment par propice car ce n'est pas le bon moment selon le statut du pipeline.
Il y a des démos de setup d'ordonnancements maisons avec sched_ext (en gros pouvoir modifier l'ordonnancement du noyau à la volée de manière sûre) dans le cadre des jeux et les gains étaient largement possibles en jouant dessus. Aucun rapport avec le temps réel cependant.