Points clés pour l’ingénierie
- PREEMPT_RT seul dépassait encore la limite de gigue d'une milliseconde sur les deux appareils.
- PREEMPT_RT avec SCHED_FIFO priorité 80 a réussi quatre essais en régime établi.
- Ces résultats concernent un profil pilote précis de 10 ms, pas une homologation temps réel générale.
La gigue est une distribution, pas un adjectif
Qualifier Linux de déterministe sans préciser période, charge, durée et maximum n'aide aucune décision. Il faut vérifier que le pire cas observé reste dans le budget temporel de la machine.[3][4][5]
PREEMPT_RT rend davantage de chemins noyau préemptibles. SCHED_FIFO change la priorité entre tâches prêtes. Les deux traitent des causes différentes.[2][3]
Fixer le contrat d'acceptation avant l'essai
Pour réussir à 10 ms, la gigue devait rester sous 1 ms, sans cycle manqué ni dépassement, avec un âge d'instantané inférieur à 20 ms et une publication sous 1 ms.[1]
La configuration qui réussit
PREEMPT_RT avec SCHED_FIFO priorité 80 réussit sur les deux contrôleurs. La gigue maximale des quatre essais va de 0,063612 à 0,094448 ms, sans cycle manqué, dépassement ni croissance mémoire.[1]
| Contrôleur | Charge | Gigue max. | Âge instantané | Publication | Manqué / dépassement |
|---|---|---|---|---|---|
| A | Non | 0,085877 ms | 1,982421 ms | 0,096610 ms | 0 / 0 |
| B | Non | 0,063612 ms | 9,277714 ms | 0,064073 ms | 0 / 0 |
| A | Oui | 0,094448 ms | 3,851881 ms | 0,081295 ms | 0 / 0 |
| B | Oui | 0,067025 ms | 9,068315 ms | 0,079147 ms | 0 / 0 |
Les échecs expliquent la réussite
Les configurations standard ou ajustées atteignaient 2,258783 à 3,662989 ms. PREEMPT_RT sans FIFO s'améliorait, mais échouait encore à 1,014743 et 1,340064 ms.[1][2][3]
- Mesurer toute la configuration d'ordonnancement.
- Sortir réseau, journalisation et E/S bloquantes du thread cyclique.
- Archiver les échecs avec les meilleurs résultats.
Ce que cela prouve, et ce que cela ne prouve pas
Les données permettent de poursuivre le pilote à 10 ms. Elles ne prouvent ni validation finale, ni temporisation E/S, ni comportement longue durée, ni exactitude des valeurs, ni aptitude à la sécurité fonctionnelle.[1]
Restent à tester le démarrage à froid sous charge, les profils 100 ms, la contention sur un même cœur, la fraîcheur backend et la valeur de bout en bout.[1]
Le prochain essai doit chercher à casser le résultat
- Démarrer à froid avec toutes les charges.
- Faire concurrencer service et runtime sur le même cœur.
- Tester assez longtemps pour voir température et rotations de journaux.
- Mesurer les E/S physiques en plus des horodatages logiciels.
- Publier données brutes, configuration et échecs.
Questions fréquentes
PREEMPT_RT garantit-il une commande déterministe ?
Non. Matériel, pilotes, priorités, charge et application déterminent toujours le résultat mesuré.
Pourquoi SCHED_FIFO ?
Il permet au thread de commande prioritaire de préempter les tâches normales, à condition que son travail soit borné et surveillé.
S'agit-il d'une validation de production ?
Non. Il s'agit de quatre essais pilotes en régime établi sur deux appareils, avec des limites publiées.
Sources et normes
- MCR Demo 1 steady-state 10 ms timing evidenceBootCtrl, 26 July 2026
- PREEMPT_RT theory of operationLinux kernel documentation
- sched(7): overview of CPU schedulingLinux man-pages project
- clock_nanosleep(2): high-resolution process sleepLinux man-pages project
- Cyclictest documentationLinux Foundation Real-Time Linux project
BootCtrl Engineering a vérifié pour la dernière fois les affirmations techniques et les liens sources le 26 juillet 2026. Les déclarations produit sont confrontées aux dépôts d’implémentation actuels ; les éléments de feuille de route ne sont pas présentés comme disponibles.
