Le sched_setscheduler(2) et ses amis vous permettent d'utiliser deux ordonnanceurs en temps réel logiciels différents, SCHED_FIFO SCHED_RR. Les processus exécutés sous ces planificateurs ont une priorité plus élevée que les processus normaux. Donc, tant que vous n'avez que quelques-uns de ces processus et que vous contrôlez les priorités entre eux, vous pouvez en fait obtenir des réponses en temps réel assez décentes.
Comme demandé dans un commentaire, voici la différence entre SCHED_FIFO et SCHED_RR :
Avec les planificateurs "en temps réel", il y a jusqu'à 100 priorités différentes (POSIX ne nécessite que 32 niveaux distincts, il faut donc utiliser sched_get_priority_min(2) et sched_get_priority_max(2) pour obtenir le nombre réel. Les planificateurs fonctionnent tous les deux en préemptant les processus et les threads avec une priorité inférieure, la différence réside dans la façon dont ils gèrent les tâches avec la même priorité.
SCHED_FIFO, est un ordonnanceur premier entré premier sorti (d'où le nom). Cela signifie que la tâche qui arrive en premier dans la file d'attente d'exécution est autorisée à s'exécuter jusqu'à ce qu'elle soit terminée, abandonne volontairement son espace dans la file d'attente d'exécution ou est préemptée par une tâche de priorité supérieure.
SCHED_RR, est un planificateur circulaire. Cela signifie que les tâches avec la même priorité ne sont autorisées à s'exécuter que pendant un certain quantum de temps. Si la tâche est toujours en cours d'exécution lorsque ce quantum de temps s'épuise, la tâche est préemptée et la tâche suivante dans la file d'attente d'exécution (avec la même priorité) est autorisée à s'exécuter jusqu'à son quantum de temps. Comme avec SCHED_FIFO, les tâches de priorité supérieure prévalent sur les tâches de priorité inférieure, cependant, lorsqu'une tâche qui a été préemptée par une tâche de priorité supérieure est autorisée à s'exécuter à nouveau, elle n'est autorisée à s'exécuter que pendant le temps restant dans son quantum. Voir la section Noes dans sched_rr_get_interval(2) pour savoir comment définir le quantum de temps pour une tâche.
MRG
La sous-milliseconde va être difficile à garantir sur un noyau non RT. Je sais que beaucoup de très bon travail a eu lieu ces dernières années (par exemple, le gros verrou du noyau a disparu), mais ce n'est toujours pas suffisant pour le garantir.
Vous pourriez jeter un coup d'œil à Scientific Linux de ces sympathiques perturbateurs d'atomes du CERN et du Fermilab. Cela peut avoir MRG installé (voir mon lien), ce qui vous donne une configuration pré-pack du correctif PREEMPT_RT.
Ou si vous avez l'argent, vous pouvez obtenir Redhat MRG. Il s'agit d'une distribution Linux entièrement prise en charge avec le correctif PREEMPT-RT intégré, ce qui éliminerait les problèmes de correctifs du noyau.
Le fait est que Redhat facture beaucoup beaucoup pour cela (3000 $ PAR AN PAR INSTALLATION). Je pense qu'ils sont tombés sur le fait que l'un des plus gros clients pour cela est les investisseurs de trading à grande vitesse qui ont encore beaucoup de dollars et ne remarqueront donc pas que 3000 $/boîte/an sortent.
Comment j'ai commencé avec MRG
J'ai fait pas mal de travail avec MRG (en utilisant les deux éléments ci-dessus), et c'est plutôt bon. Il remplace les routines de service d'interruption dans le noyau stock par des threads pour traiter l'interruption. Cela signifie que vous pouvez exécuter votre logiciel avec des priorités supérieures aux threads IRQ ! C'est le genre de chose que vous devez faire si vous voulez vous rapprocher de la garantie une latence inférieure à la milliseconde sur votre application.
Il semble y avoir une dérive progressive des choses MRG dans le noyau principal, ce qui est une bonne chose à mon avis. Peut-être qu'un jour cela deviendra le truc principal.
Autres pièges
La gestion thermique du processeur moderne peut être un véritable casse-tête. J'ai eu des systèmes qui se sont bloqués pendant 0,3 seconde pendant qu'une interruption de gestion du système était en cours de maintenance (par le BIOS qui saigne, pas par le système d'exploitation), simplement parce que le processeur s'est un peu réchauffé. Regarde ça. Vous devez donc vous méfier de ce que fait votre matériel sous-jacent. En règle générale, vous devez commencer à vous soucier d'abandonner le refroidissement géré des PC modernes et de revenir à un gros ventilateur qui tourne vite tout le temps.
Vous pouvez aller assez loin avec Linux en supprimant la "perturbation" des autres processus vers le processus en temps réel. J'ai joué avec la même chose dans Windows, ce qui est une horreur beaucoup plus grande à faire correctement, mais cela montre la direction. Donc une sorte de check-list :
- Le plus important (étrange mais vrai) :le matériel. N'optez pas pour un ordinateur portable, celui-ci sera optimisé pour faire des choses étranges pendant les interruptions SMM. Vous ne pouvez rien faire.
- Les pilotes :Linux (et Windows) a de mauvais pilotes et de bons pilotes. Relatif au matériel. Et il n'y a qu'une seule façon de le savoir :l'analyse comparative.
Isoler du reste du système, désactiver tout partage :
- Isolez un processeur (
man cpuset). Créez deux ensembles de processeurs, un pour les processus normaux et un pour votre processus en temps réel. - Réduisez au minimum la partie temps réel de votre code. Communiquez avec un grand tampon avec d'autres parties du système. Réduisez les IO au strict minimum (puisque les IO ont de mauvaises garanties).
- Faites en sorte que le processus ait la priorité en temps réel la plus élevée (soft).
- Désactivez HyperThreading (vous ne voulez pas partager)
- préallouez la mémoire dont vous avez besoin et mlock() la mémoire.
- Isolez les appareils que vous utilisez. Commencez par allouer un IRQ dédié au périphérique (déplacez les autres périphériques vers un autre IRQ ou supprimez d'autres périphériques/pilotes).
- Isolez les E/S que vous utilisez.
Réduire l'activité du reste du système :
- démarrez uniquement les processus dont vous avez vraiment vraiment besoin.
- supprimez le matériel dont vous n'avez pas besoin, comme les disques et autres matériels.
- désactiver l'échange.
- n'utilisez pas de modules du noyau Linux et ne les chargez pas à l'avance. L'initialisation des modules est imprévisible.
- supprimez de préférence l'utilisateur également :)
Rendez-le stable et reproductible :
- désactiver toutes les économies d'énergie. Vous voulez les mêmes performances tout le temps.
- passez en revue tous les paramètres du BIOS et supprimez-en tous les "événements" et "partages". Donc, pas d'étapes de vitesse fantaisistes, de gestion thermique, etc. Choisissez une faible latence, ne choisissez pas des choses avec "rafale" dans le nom car cela échange généralement le débit pour de moins bonnes performances.
- passez en revue les paramètres du pilote Linux et réduisez les latences (le cas échéant).
- utiliser un noyau récent qui essaie chaque jour un peu plus de ressembler à un noyau temps réel.
Et puis comparer, en utilisant des tests de résistance et en laissant la machine allumée pendant des jours tout en enregistrant max. latences.
Alors :bonne chance :)