Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Ubuntu 24.04 a désormais son noyau temps réel

Ubuntu 24.04 a désormais son noyau temps réel

Le 03 juin à 08h33

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-kernel

Si 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.

Le 03 juin à 08h33

Commentaires (23)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Ou sinon... il existe https://liquorix.net/
votre avatar
Il ne faut pas confondre RT et faible latence. Ce n'est PAS le même sujet.

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é.
votre avatar
Au niveau config kernel liquorix utililse une config RT, sauf qu'ils restent sur du kernel vanilla donc ils n'ont pas mis le patch preempt-rt.
votre avatar
Tout ce que je lis sur liquorix, c'est qu'il est low latency, et pas RT. De ce que j'avais compris, les low latency permettent d'être plus réactifs, mais sans garantie, les RT permettent qu'une tâche RT puisse interrompre n'importe quelle autre tâche dans un temps défini - généralement non low latency.
Passer le kernel d'abord en low latency puis appliquer du RT permet d'être plus fin sur le RT.
votre avatar
Non, normalement quand on parle de "low latency" dans le kernel Linux, on fait référence au modèle de préemption de l'ordonnanceur. Cette config n'est pas configurée en Low Latency (CONFIG_PREEMPT) mais bien en Real time (CONFIG_PREEMPT_RT).

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.
votre avatar
Les noyaux temps réel servent aussi en MAO : ça permet de mixer depuis un PC avec une latence quasi imperceptible.
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.
votre avatar
Heu, faisant de la MAO sous Windows depuis les années 2000, l'ordre de grandeur de la latence en 10ièmes de secondes, tu exagère un peu. Les pilotes son par défaut des cartes son grand public avaient effectivement des problèmes de latence innacceptables pour un musicien, mais des drivers ASIO libres on été dispo très rapidement (quelques ms max, en fonction de la taille du buffer, ce qui nécessitait un processeur bien cadencé pour ne pas entendre de craquement lié à l'insuffisance du buffer). Avec une vraie carte son (dédié à la musique), pas de problème.
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.
votre avatar
Je confirme, et dans ces années là, les interfaces audio Pci/Pcie étaient reines, avec pour les meilleures (RME) des latences sous les 5 millisecondes, et encore moins avec l'exotique Gigasampler et ses drivers Gsif.
votre avatar
C'est curieux, le noyau PREEMPT_RT est disponible dans Debian depuis une quinzaine d'années, et Ubuntu étant basé sur Debian, ça m'aurait semblé logique que ce soit présent dans Ubuntu depuis au moins aussi longtemps...
votre avatar
Je ne sais pas si Ubuntu proposait un noyau compilé PREEMPT_RT, mais ici, c'est plus que le noyau qu'ils proposent, c'est jusqu'à 12 ans de maintenance (payante) et ils visent l'embarqué. Pour ce genre de produit, cette durée est un plus pour la sécurité.

Par contre, je ne suis pas sûr que l'on se tourne naturellement vers Ubuntu pour ce genre de produits.
votre avatar
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 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...
votre avatar
Voilà y a ça. et en plus...
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é.
votre avatar
Il ne faut pas cracher dans la soupe non plus !

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.
votre avatar
Si les pros sont les premiers à bénéficier de la fonctionnalité, c'est qu'ils en sont de fait les béta-testeurs pour les non-pros : qui eux, recevront une version stabilisée.

Du coup, ça fait pas très pro :nonnon:
votre avatar
Ubuntu Pro, gratuit pour une utilisation personnelle ou commerciale si limitée à cinq appareils.
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.
votre avatar
Mais est-ce un comportement bien pro que de faire son environnement béta-testeur à titre gracieux ?

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 :D
votre avatar
Ca dépend des besoins en fait. Je prenais l'exemple des Cloud Provider car ils peuvent mettre à disposition un composant en Preview (et donc en temps normal, sans support) mais dont les features sont tellement importantes que le client le voudra de suite et ne souhaitera pas attendre la GA. Parfois cela se traduit par un support exceptionnel du composant.

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.
votre avatar
Je ne peut que me réjouir de cette belle explication : c'est beau la théorie.

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" :bravo:
votre avatar
Bah perso je dirais juste que si l'IT était une science exacte, je serais chômeur :p

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.
votre avatar
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.
votre avatar
J'ai fais ma thèse sur le fait du système temps temps réel, avec toutes mes expérimentations sur du kernel Linux patché temps réel.

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.
votre avatar
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.
votre avatar
Il y a aussi plein de papiers très intéressants à lire sur la comparaison de performance d'un point de vue latence / temps de réponse entre les différentes solutions qu'il existe sur le kernel linux pour l'approcher d'un système temps réel. Donc les patches comme PREEMPT-RT, les solutions de co-kernel etc. :)

Ubuntu 24.04 a désormais son noyau temps réel

Fermer