La dernière mouture LTS (Long Term Support) d’Ubuntu a reçu il y a quelques jours son noyau « temps réel », qui « réduit la latence par rapport à Linux principal et améliore la capacité du système à gérer efficacement les opérations urgentes ».
Comme Ubuntu 22.04 avant elle, ce nouveau noyau Linux est réservé aux personnes inscrites à Ubuntu Pro, gratuit pour une utilisation personnelle ou commerciale si limitée à cinq appareils.
Ce noyau particulier est basé sur la version 6.8 et y ajoute notamment les modifications PREEMPT_RT pour les architectures AMD64 et ARM64. Il contient également des optimisations pour le matériel Raspberry Pi.
« Avec des réponses limitées dans le temps pour les exigences de latence critiques, Real-time Ubuntu 24.04 LTS fournit un traitement déterministe aux charges de travail les plus exigeantes dans tous les secteurs, de la fabrication à l'automobile en passant par l'infrastructure critique des opérateurs télécoms », indique Canonical.
Si vous bénéficiez de l’abonnement Ubuntu Pro, il suffit d’exécuter une commande pour activer le nouveau noyau :
pro attach pro enable realtime-kernelSi vous souhaitez l’activer sur un Raspberry Pi, il faudra ajouter « --variant=raspi » à cette même commande.
Notez que ce noyau est conçu pour des besoins spécifiques. Il n’est pas utile pour un usage standard.
Commentaires (23)
#1
#1.1
En RT, on te garanti la latence (ou au moins tu sais qu'elle n'est pas respectée) ou la durée de traitement - sans forcément chercher la meilleure. Mais avec une prévisibilité exemplaire.
Pour l'audio/le jeu, on a tendance à garantir la meilleure latence - ce qui liquorix revendique. Là on est pas sur de la prévisibilité.
#1.2
#1.3
Passer le kernel d'abord en low latency puis appliquer du RT permet d'être plus fin sur le RT.
#1.4
Par contre, il n'y a pas le patch preempt-rt par conséquent, certaines actions peuvent empêcher l'ordonnanceur de prendre la main et de ce faite empêcher de respecter les règles de priorité mise en place.
#2
Au début-milieu des années 2000, avec une carte son / platine firewire, tu descendais sans prb à quelques (dizaines de) millisecondes de latence entre le moment où tu cliques sur un effet et celui ou t'entends le rendu dans ton monitor. Sous windows c'était plutôt en dixième de seconde, soit quasi ingérable pour un mix en live.
Je mets ça au passé parce que j'ai l'impression que le firewire n'a pas eu de successeur, et l'USB par conception ne peut pas être en temps-réel, donc risque le lag à tout moment.
#2.1
Concernant la latence usb, en tant que pianiste jouant sur PC via un contrôleur midi, je n'ai jamais ressenti de problème avec un bon vieux usb 1.2.
#2.2
#3
#3.1
Par contre, je ne suis pas sûr que l'on se tourne naturellement vers Ubuntu pour ce genre de produits.
#3.2
En prime, comme c'est quand même pas le sport de masse sous Linux, rien que le fait de pour le user-space de pouvoir alors préempter jusqu'au kernel fait tomber dans des cas tordus largement non testés, à la croisée de la conception des modules noyaux et de celles du matériel qu'ils supportent.
Dans le passé, sur des cartes télécoms, j'ai ainsi eu des stockages eUSB d'un seul fabricant (pas le moins bon, en plus) qui parfois faisaient (très rarement) des usb-disconnect: Perte de tous les points de montage, ca finissait par un redémarrage. Après des semaines de tentatives de reproduction/debug, ce modèle précis d'eUSB, quand le module usb-storage se retrouvait préempté par notre applicatif RT pile dans les quelques instructions entre les phases commande et data, il faisait péter un timeout réglé très court dans le firmware du stockage qui initiait alors son reset.
C'est le genre de pb tordu dans lequel le patch preempt-rt peut envoyer, car on se retrouve vraiment hors des cas d'usage classiques de Linux. Bon courage avec Ubuntu pour espérer les voir rentrer dans ce type de problème, surtout si le patch à pousser derrière n'est pas forcément souhaitable dans le cas général...
Historique des modifications :
Posté le 03/06/2024 à 11h37
En effet, j'aimerais savoir quel marché Ubuntu pourrait décrocher en embarqué. Ils ont déjà échoué à devenir une sorte de "Red-Hat sur base Debian", AMHA pas sans raison, mais c'est un domaine ou on va coller un kernel strippé au max pour son matériel, pas du généraliste.
En prime, comme c'est quand même pas le sport de masse sous Linux, rien que le fait de pour le user-space de pouvoir alors préempter jusqu'au kernel fait tomber dans des cas tordus largement non testés, à la croisée de la conception des modules noyaux et de celles du matériel qu'ils supportent.
Dans le passé, sur des cartes télécoms, j'ai ainsi eu des stockages eUSB d'un seul fabricant (pas le moins bon, en plus) qui parfois faisaient (très rarement) des usb-disconnect: Perte de tous les points de montage, ca finissait par un redémarrage. Après des semaines de tentatives de reproduction/debug, ce modèle précis d'eUSB, quand le module usb-storage se retrouvait préempté par notre applicatif RT pile dans les quelques instructions entre les phases commande et data, il faisait péter un timeout réglé très court dans le firmware du stockage qui initiait alors son reset.
C'est le genre de pb tordu dans lequel le patch preempt-rt peut envoyer, car on se retrouve vraiment hors des cas d'usage de Linux. Bon courage avec Ubuntu pour espérer les voir rentrer dans ce type de problème, surtout si le patch à pousser derrière n'est pas forcément souhaitable dans le cas général...
Posté le 03/06/2024 à 11h39
En effet, j'aimerais savoir quel marché Ubuntu pourrait décrocher en embarqué. Ils ont déjà échoué à devenir une sorte de "Red-Hat sur base Debian", AMHA pas sans raison, mais c'est un domaine ou on va coller un kernel strippé au max pour son matériel, pas du généraliste.
En prime, comme c'est quand même pas le sport de masse sous Linux, rien que le fait de pour le user-space de pouvoir alors préempter jusqu'au kernel fait tomber dans des cas tordus largement non testés, à la croisée de la conception des modules noyaux et de celles du matériel qu'ils supportent.
Dans le passé, sur des cartes télécoms, j'ai ainsi eu des stockages eUSB d'un seul fabricant (pas le moins bon, en plus) qui parfois faisaient (très rarement) des usb-disconnect: Perte de tous les points de montage, ca finissait par un redémarrage. Après des semaines de tentatives de reproduction/debug, ce modèle précis d'eUSB, quand le module usb-storage se retrouvait préempté par notre applicatif RT pile dans les quelques instructions entre les phases commande et data, il faisait péter un timeout réglé très court dans le firmware du stockage qui initiait alors son reset.
C'est le genre de pb tordu dans lequel le patch preempt-rt peut envoyer, car on se retrouve vraiment hors des cas d'usage de Linux. Bon courage avec Ubuntu pour espérer les voir rentrer dans ce type de problème, surtout si le patch à pousser derrière n'est pas forcément souhaitable dans le cas général...
#3.3
12 ans de maintenance me parait très court pour les trucs genre informatique "embarqué". Ce que j'ai en tête c'est voiture, avion, machines industrielles, etc... Avec des machins qui vont rester en vente 10 ans et qui seront en usage 20-30 de plus.
(le traitement d'obsolescence dans ces domaines, c'est l'enfer)
A moins que je comprenne pas du tout à quel domaine ça puisse être marketé.
#3.4
les kernels LTS ne durent que 2 ans. Il existe aussi des Super-long-term support (SLTS) que je découvre et qui sont maintenus par CIP qui partent d'une version LTS tous les 2 à 3 ans et qui sont maintenues à peu près 10 à 11 ans. Ils gèrent d'ailleurs aussi la version RT du noyau.
Si tu veux supporter ton produit plus longtemps, il faut changer de version de kernel et bien le requalifier.
La plupart des boîtes le laisseront probablement en l'état quitte à patcher si un problème important survient, surtout qu'une partie du matériel ne sera peut-être plus supporté par le nouveau noyau ou le fournisseur du matériel.
Donc, sur ce point, Ubuntu n'a pas à rougir.
#4
Du coup, ça fait pas très pro
#4.1
Les beta testeurs peuvent donc le faire gratuitement aussi :)
En dehors de ça, c'est une pratique courante. Les CSP font souvent beta tester des fonctionnalités à leurs clients.
#4.2
Hormis des profils de type d'un admin unix qui a besoin d'anticiper les conneries que lui inventent les éditeurs logiciels, un professionnel a surtout besoin de stabilité de son environnement de travail.
Du coup, il faudrait qu'il installe la version grand public pour rester stable
#4.3
C'est devenu la norme dans le développement produit de fournir un accès anticipé pour avoir des retours.
Accessoirement, on évite d'utiliser un composant en Preview en prod. Après, c'est la responsabilité du client. Le fournisseur propose, il n'impose pas.
Dans tous les cas, la comm' d'Ubuntu ne semble pas indiquer que c'est une fonction en beta. L'association au service "Pro" est plutôt dans le sens de service à valeur ajoutée pour avoir des fonctions exclusives et le support associé. De ce fait, les clients de l'offre "Pro" ne sont pas des beta testeurs.
#4.4
Microsoft aussi teste ses patchs et ses fonctionnalités avant de les déployer.
Il n'empêche qu'il pousse parfois des patchs bogués.
Alors oui, c'est à chacun de prendre ses responsabilités et de ne pas pleurer le jour où un contrat majeur est planté à cause d'une fonctionnalité ou d'un outil pas trop fini qui était hyper cool mais que le développeur a arrêté sans prévenir personne.
J'ai vu cela plus d'une fois chez des grands clients, des décisions inconséquentes de ce type : "ah ben c'était super pratique, c'était gratuit, et on en avait besoin hyper vite en interne et puis on a mis ça un peu partout et depuis ça nous écroule le service pour 300 personnes"
#4.5
La perfection en prod, ça n'existe pas. L'avantage, c'est que ça m'a payé nombre d'astreintes.
Quoiqu'il en soit, la feature ici présentée ne semble pas être en bêta. Donc on peut difficilement dire que les clients en seront les testeurs.
Même si selon les rythmes de développement moderne, on est des beta testeurs permanents après tout.
#5
Ça peut suffire pour certain usage.
Historique des modifications :
Posté le 03/06/2024 à 12h27
Il y a pour les Kernel compilés avec PREEMPT_DYNAMIC un "faux" RT avec l'argument preempt=full (via gurb ou autres bootloader)
Ça peut suffire pour certain usage.
#6
Je confirme que ça fait plus de 10 ans que des variants PREEMPT-RT du noyau sont déjà distribués et compilés, juste ils n'étaient pas livrés par défaut et il fallait passer par 2 lignes de commandes... la première pour télécharger la version du kernel -preempt, la seconde pour changer le boot config pour lui dire de démarrer dessus...
Du coup ouai la seule nouveauté c'est que ça serait dispo en mainline et maintenu avec les update kernel sans avoir à repointer manuellement une version du kernel... rien d'extraordinaire en somme.
En ce qui concerne les usages industriels, personne a attendu Ubuntu pour ça et il existe des solutions bien plus performantes et/ou éprouvées à la fois dans l'inustrie et dans la recherche (je pense à Corbos Linux par exemple, ou encore Xenomai et autres co-kernels temps réel)...
En somme l'update est somme toute anecdotique, c'est surtout une introduction officielle du patch preempt rt pour le kernel.
#6.1
(Ses autres papiers: https://bristot.me/publications/ ).
Très intéressant à lire.
Historique des modifications :
Posté le 04/06/2024 à 00h23
En parlant de thèse, Daniel Bristot de Oliveira a fait la sienne (lorsqu'il était chez Redhat avec Steven Rostedt) sur la validation formelle du patch rt: https://bristot.me/files/research/papers/thesis/thesis.pdf
(Ses autres papiers: https://bristot.me/publications/ ).
Très intéressant à lire.
#6.2