Canonical brengt Ubuntu 22.04 LTS-versie met realtimekernel uit

Canonical maakt zijn realtimeversie van Ubuntu 22.04 LTS algemeen beschikbaar. Dat OS beschikt over een realtimevariant van de Linux-kernel. Realtime-Ubuntu is vooral bedoeld voor industriële toepassingen en bedrijven, maar komt ook gratis beschikbaar.

Canonical maakt realtime-Ubuntu op dinsdag beschikbaar als Server- en Core-variant, schrijft het bedrijf in een persbericht. Eerstgenoemde komt beschikbaar via Canonicals Ubuntu Pro-abonnement. Deze realtimeversie van Ubuntu Server is, zoals de naam doet vermoeden, bedoeld voor gebruik in servers. Ubuntu Core is op zijn beurt vooral geoptimaliseerd voor edgeapparaten en iot-toepassingen. De Core-versie met realtimekernel komt beschikbaar voor enterpriseklanten met een eigen appstore. Realtime-Ubuntu komt via Ubuntu Advantage ook gratis beschikbaar voor persoonlijk gebruik, meldde Canonical eerder al.

De realtimeversie van Ubuntu 22.04 LTS beschikt over versie 5.15 van de Linux-kernel met daarin de Preempt_rt-patchset geïntegreerd, zodat de kernel meer preemptive werkt. Een realtimekernel reageert ook deterministic op externe events en kan taken daardoor binnen een bepaalde, voorspelbare tijd uitvoeren, anders dan bij een 'normale' kernel waar de responstijden willekeuriger kunnen zijn. De responstijden van de kernel in de realtimeversie van Ubuntu moeten in het algemeen ook laag zijn, zo claimt Canonical.

Volgens Canonical is realtime-Ubuntu vooral bedoeld voor industriële applicaties, die baat hebben bij een realtimekernel met lage en voorspelbare latency's. Het bedrijf zegt bijvoorbeeld dat het OS gebruikt kan worden in de systemen van telecomproviders, automotive, luchtvaart en defensie, naast de publieke sector, de gezondheidszorg en retail. Het OS komt beschikbaar voor x86- en Arm-architecturen van 64bit.

Ubuntu 22.04 LTS 'Jammy Jellyfish', waarvan nu een realtimeversie beschikbaar is

Reacties (66)

[RxTweak]

Heeft dit ook nog voordelen of use-cases voor de normale huis tuin en keuken gebruiker?

[J_van_Ekris]

Ja en nee. Ik denk dat het belangrijk is om te beseffen dat de PREEMPT kernels niet tot doel hebben om het een Real Time Operating Systeem (RTOS) te maken en dus dingen hard real-time af te handelen, maar om bepaalde signaalafhandeling betrouwbaarder te maken, en de latency van signaalafhandeling dus te verkleinen en betrouwbaarder te maken. De afgelopen jaren zijn er al veel PREEMPT patches in de mainstream Linux kernel terecht gekomen omdat het gewoon een goed idee was, dus daar ga je de grote winst niet meer mee boeken.

De RT-patches zijn van belang om te voorkomen dat een real-time signaal te lang moet wachten om verwerkt te worden. Deels is dat te doen door links en rechts gewoon processen makkelijker te laten onderbreken (lees: taken worden minder monolitisch opgebouwd of afgehandeld), wat in zijn algemeenheid een goed ding is. Veel kleinere, minder monolitische taken maken een OS veel meer responsive, en dat is dus een algemeen goed effect van de PREEMPT. Maar dat zit vaak allang in de mainstream Linux kernel.

Er is een batch van patches die echt ontwerpkeuzes zijn, en nadelig zijn voor het generieke gebruik als PC. Met de verkeerde instellingen gaat de kernel zich gedragen als een cocainesnuivende ADHDer om maar de mogelijkheid van real time interrupts te manangen, waardoor je normale performance onderuit gaat. In essentie werkt een OS en een applicatie het meest efficient (net als mensen) als je lang aan een stuk gericht kunt werken. Onderbrekingen betekent task switching, en dat kost ook CPU cycles. Als het niet te vaak gebeurt of de processen niet teveel verstoord, dan is dat niet erg, maar als het uit de hand loopt dan is hij meer bezig met task switching dan met echt werk verzetten. Dit is waar de juiste tuning echt van belang is, en soms de moeilijke keuzes gemaakt moeten worden.

Ik moest voor een applicatie op een Raspberry naar een soft real time OS toe, en gelukkig is de laatste release van Raspberry OS 64Bit Lite ook al standaard PREEMPT. In praktijk merk je weinig voordelen/nadelen in het normale gebruik van die kernel. Dingen lopen niet echt vlotter. Als je kijkt naar de kwaliteit van de data die we eruit halen, dan zien we wel verschillen: we meten met wat HW trucs tot op 1-5us nauwkeurig, waar dus latency echt een ding is. Bovendien moet de signaalafhandeling binnen 4ms gebeuren, wat een eeuwigheid lijkt, maar we moeten behoorlijk wat signal processing doen, dus we kunnen niet al teveel gezeur tussendoor hebben. Door processen op te splitsen en eigen dedicated CPU's te geven kom je een heel eind. Maar met de PREEMPT kernel merk je dat NICE-level een stuk verder kan zonder allerlei OS processen om zeep te helpen, en dat die processen ook minder vaak in de weg zitten. Dus de datakwaliteit gaat meetbaar omhoog. Maar dat is voor die specifieke applicatie, zonder algemeen gebruik van zo'n Pi.

[Maurits van Baerle]

Is de vuistregel niet zo'n beetje dat je moet kiezen tussen óf zo snel mogelijk (gewone kernel) óf berekenbaar (real time kernel)? Voor verreweg de meeste toepassingen is snelheid belangrijker dan berekenbaarheid, behalve dus in specifieke industriële toepassingen, muziek etc.

[Osiummaster]

In tegenstelling tot alle andere beweringen hier: Nee.

Ik gebruik al een tijd Xanmod wat een Realtime kernel heeft en mijn systeem voelt vele malen consistenter en soepeler aan en loopt minder vast dan voorheen. Vele alledaagse dingen zoals windows draggen gaan vele malen soepeler. Voor dagelijks gebruik zou ik dus ook RT aanraden,

Tijdens het trainen van Pytorch data waren mijn CPU en GPU onder full load en eerder praktisch niet meer te gebruiken. Nu kan ik rustig browsen terwijl ik neural networks train.

Zal het trainen net iets langzamer gaan? Vast. Maar dat is verwaarloosbaar, en ik kan mijn PC gewoon lekker gebruiken zonder stotteringen. Dit dus geld ook voor dagelijks gebruik, niet alleen tijdens trainen. Als iets tijdelijk al je processing power wil trekken verwaarloost hij niet alle andere processen om ALLEEN maar dat te gaan doen.

[Reactie gewijzigd door Osiummaster op 22 juli 2024 16:09]

[Maurits van Baerle]

Sluit jouw ervaring hier niet juist helemaal bij aan? Jij levert een minieme hoeveelheid rekensnelheid in maar krijgt er reactietijd voor terug en in jouw geval is die reactietijd meer waard dan de snelheid.

[Osiummaster]

Ja precies, maar volgens velen hier zou dit in dagelijks gebruik niet merkbaar moeten zijn. Ik merk echter juist het tegendeel uit mijn eigen subjectieve ervaring.

[HakanX]

Hmm das een beetje zoals Blackberry OS10 wat gebouwd was op de RTOS QNX. Maakt niet uit wat je deed, de GUI reagerde altijd direct en vlot.

[J_van_Ekris]

Is de vuistregel niet zo'n beetje dat je moet kiezen tussen óf zo snel mogelijk (gewone kernel) óf berekenbaar (real time kernel)? Voor verreweg de meeste toepassingen is snelheid belangrijker dan berekenbaarheid, behalve dus in specifieke industriële toepassingen, muziek etc.

Dat is inderdaad van een afstand nu de huidige tweesplitsing die we op kernel niveau allemaal (soms onbewust) maken. Door voor een algemene kernel te kiezen, kies je voor verwerkingssnelheid, door een PREEMPT kernel te gebruiken, kies je voor reactiesnelheid. Zelf denk ik dat vor verreweg de meeste toepassingen een normale kernel voldoet, dus eerlijk gezegd snap ik de toepassing op real-time servers dan ook niet zo: meestal is dat gewoon veel volume wegstouwen, en zijn de timing-eisen veel minder relevant. Maar ik overzie niet het hele toepassingsgebied van Ubuntu, dus wellicht zien zij meer dan ik .

[rvt1]

Als je ooit eens LinuxCNC hebt geprobeerd kun je zelf mooi horen dat je een realtime kernel had of niet.

Als je de RTOS aanzet, had je 'mooie' zingende stappen moteren, als de RToS uit stond dan hoorde je duidelijke onderbrekingen in de motoren en dan wat je ook maakte, het zag er niet mooi uit...

[Zsub]

Nauwelijks. Het enige mogelijke voordeel zou misschien kunnen zijn als je thuis een 3D-printer hebt, dat je dan Ubuntu voor de controller zou kunnen gebruiken.

[Accretion]

Nauwelijks. Het enige mogelijke voordeel zou misschien kunnen zijn als je thuis een 3D-printer hebt, dat je dan Ubuntu voor de controller zou kunnen gebruiken.

Het maakt voor 3D printen niet zo bar veel uit of d'r een variabele vertraging zit in het signaal?

[J_van_Ekris]

Het maakt voor 3D printen niet zo bar veel uit of d'r een variabele vertraging zit in het signaal?

Wel als dat signaal de positiebepaling is en de laser gewoon doorgaat met snijden, of de printer doorgaat met printen. Meest extreme voorbeeld: de positebepaling van de spuitkop van een 3D printer kan maar een keer per seconde vertellen waar hij zit, en de kop beweegt met 0,1 m/s. Dan kun je dus niet met 0,05 meter nauwkeurigheid printen. Hoe betrouwbaarder het signaal binnenkomt, hoe nauwkeuriger prints en cuts worden.

[Accretion]

Bij een 3D printer is het toch een open loop, als in stepper motor maakt x stappen?

Alsook je dus weet wanneer je de printkop uit kunt zetten?

Ja, wellicht maakt het 't bewegen van de kop minder "jerky", maar echt "real time" is het ook niet?

Bijvoorbeeld een quadcopter moet wel binnen x tijd reageren op een signaal omdat je anders een overcorrectie kunt krijgen en een systeem dat uit balans raakt.

[J_van_Ekris]

Bij een 3D printer is het toch een open loop, als in stepper motor maakt x stappen?

Alsook je dus weet wanneer je de printkop uit kunt zetten?

Ja, wellicht maakt het 't bewegen van de kop minder "jerky", maar echt "real time" is het ook niet?

Bijvoorbeeld een quadcopter moet wel binnen x tijd reageren op een signaal omdat je anders een overcorrectie kunt krijgen en een systeem dat uit balans raakt.

Ik werk voor Raspberry Pi met een GPIO library (pigpio) die krankzinnig hoge scanfrequentie heeft, en juist veel gebruikt wordt door 3D printers etc.. Ik weet niet exact hoe/waarvoor ze het gebruiken eerlijk gezegd, dus of ze blind de stepper motor gewoon aansturen of dat er een feedback lus in zit weet ik niet. Als ik zoiets zou bouwen, zou ik wel degelijk een closed loop gebruiken, al is het maar om zeker te weten of je kop niet blijft steken. Maar ik heb nog niet het plezier gehad om dit te bouwen

[GekkePrutser]

Dit verschilt per printer. De meesten sturen gewoon de stappenmotor aan en kunnen helemaal niet meten waar de kop zich werkelijk bevindt. De hele dure kunnen het wel checken of die inderdaad uithangt waar ze denken dat die zit.

De 'calibratie' gebeurt met de assen-stopswitches. Daarom springt hij voor het printen even alle hoeken in (en ook om de bedhoogte te meten als je bed levelling hebt).

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:09]

[rvt1]

je kijgt veel onderbrekingen en je stappen motoren willen ook 'netjes' sneller en langzamer lopen. Als je stappen gaat missen in tijd en worden je krachten op je constructie erg groot. Je systeem gaat resoneren of uit de pas lopen.
Ik heb eens een 2mx1m grote CNC machine aangestuurd met een 1.5KW spindel... dan wil je wel dat alles netjes loopt!

[Accretion]

Fair, je wil de stappen op het juiste moment uitsturen. Zoals de ontsteking van een auto ook exact op het juiste moment aangestuurd moet worden?

Maar worden deze commandos dan direct in het OS uitgestuurd naar de motoren, via IO pins?
Wat voor een moederbord gebruik je daarvoor of draait dat allemaal op een Pi?

[rvt1]

Fair, je wil de stappen op het juiste moment uitsturen. Zoals de ontsteking van een auto ook exact op het juiste moment aangestuurd moet worden?

Dat is een mooie analogy en dat is inderdaad juist..

Maar worden deze commandos dan direct in het OS uitgestuurd naar de motoren, via IO pins?
Wat voor een moederbord gebruik je daarvoor of draait dat allemaal op een Pi?

In de tijd draaide dat op een toen al oud laptop met een parallel poort... de pinnetjes waren voldoende voor 3 stappen motoren. De poort stuurde dan direct stappen motor drivers aan (Gecko drive).
In die tijd hadden we nog geen raspberry en als je als hooby of pro een krachtige CNC machine wilde dan kon je prima LinuxCNC gebruiken. Daar zat dan een UI in waar je snij/mil paden op kon volgen.
Er zat ook een zeer goede gcode interpreter in. Niet alleen voor CNC, maar heb ook eens begrepen dat LinuxCNC ingezet is om in bv een circus allelei touwen met motoren aan te sturen waar dan ook iemand aanhing, dus zeer betrouwbaar dat system. 5-Axis Kinematics wordt ook ondersteunt!

Dat was zo rond 2005

[GekkePrutser]

Jawel, als je steeds onderbrekingen hebt, dan blijft je nozzle een beetje 'oozen' (weet de Nederlandse term niet), dat ga je echt wel zien. Als het steeds op dezelfde plek gebeurt dan krijg je echt lijnen, en anders lelijke plekjes. Het materiaal is niet zo exact als je het zou willen.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:09]

[Accretion]

Het 'feeden' van het plastic gaat toch ook met een stappenmotor, je zet toch niet steeds de printkop uit tussendoor?

Maar dan maakt het alsnog niet zo veel uit of de response ergens tussen 1ms en 50ms zit.

Je hoeft geen garandeerde respons te hebben van 10ms. Ja, het is in theorie wel 'handig' en maar in de praktijk zal het wel meevallen.

[ocf81]

LinuxCNC is inderdaad een toepassing waar een real-time kernel belangrijk is. Maar die wordt vooral voor DIY Portaalfrezen en dat soort machines gebruikt.

[Annihlator]

Voor de letterlijke huis tuin en keukengebruiker wss niet, die zullen het zelf niet snel toepassen en voor zover anderen dat voor hen doen zullen die gebruikers er botweg geen weet van hebben.

Maar denk bijv aan klimaatcontrole: best fijn als de gui op het moment van aanraking kan reageren ipv met vertraging/na handelingen.

[the_shadow]

Maar denk bijv aan klimaatcontrole: best fijn als de gui op het moment van aanraking kan reageren ipv met vertraging/na handelingen.

Mwoa, ik denk dat het hier niet zo'n vaart in loopt. Grafische interfaces hebben altijd een bepaalde vorm van vertraging en die moet al erg hoog zijn wil het als hinderlijk worden ervaren. Een realtime kernel zal voornamelijk van nut zijn bij toepassingen waar je echt op enkele milliseconden nauwkeurig moet zijn, voorbeelden als audiobewerking zijn hierboven al genoemd.

[Soldaatje]

Blijkbaar niet, in ieder geval niet voor gaming: https://www.reddit.com/r/...rnel_make_any_difference/

[GeertJohan]

Ik heb erg lang een "realtime" kernel gedraaid omdat ik bezig was met audio. Digital Audio Workstations zoals Bitwig werken met JACK en daarbij kan een pre-emptive scheduling kernel er voor zorgen dat de audio-buffers optijd worden aangevuld en verwerkt. Op die manier kan je enorm kleine buffers aanhouden, waardoor de latency van audio in- en uit de computer laag blijft. Zo kan de DAW goed in sync blijven met andere audio-hardware, en kan je digitaal audio verwerken zonder veel latency toe te voegen.

[Reactie gewijzigd door GeertJohan op 22 juli 2024 16:09]

[HakanX]

Zou dit ook enig voordeel kunnen hebben voor een beveiligingscameraserver?

[Arrigi]

Lijkt me niet. Daar merk je geen verschil tussen meteen of lichte vertraging.

Zolang de inkomende data geëncodeerd/analyseerd/opgeslagen wordt maakt het weinig uit of dat in 1 milliseconde of 2000 millisecondes gebeurt.

[HakanX]

Ik dacht meer aan of de 2-3 seconde vertraging van een livestream misschien korter kon worden. Maar dat heeft niet hiermee te maken dus.

[geoffrey.vl]

dat is vermoedelijk buffering

[hottestbrain]

Dat is het in een DAW ook. Hoe kleiner die buffer, hoe prettiger het is om iets op te nemen (er zit minder vertraging tussen wat je doet en wat je vervolgens hoort). Dat betekend dus ook dat je betrouwbaar getimed de audiostream door moet krijgen en daarom kan ik me voorstellen dat realtime kernels *iets* uithalen. Neemt niet weg dat ik het verschil tussen 1 en 10 miliseconden niet groot vind (vanaf 14 ms begint het me persoonlijk te irriteren dat er vertraging is) en dus niet verwacht een betere muzikant te worden van een realtime kernel.

[Sando]

Bij het opnemen van muziek met een DAW of het live spelen van digitale instrumenten worden realtime kernels gebruikt.

Ardour, LMMS, etc.

Ubuntu Studio, voor hobbyisten, liefhebbers (en professionals denk ik) komt dan ook standaard met een realtime kernel.

[Reactie gewijzigd door Sando op 22 juli 2024 16:09]

[paulvdb08]

Ik gebruik Arch linux met een realtime kernel om gitaar te spelen en demos op te nemen en dat werkt echt heel goed! Ik gebruik de JACK audio server met gitaar plugins van Neural DSP (via wine) en Bitwig Studio. De latency is zo laag dat ik geen verschil meer hoor met een analoge versterker

[haling]

Met PipeWire haal ik nog lagere latency dan met JACK. Sowieso begint met dingen als PipeWire Linux een echt volledig, makkelijk en stabiel pro-audio-OS te worden, en nu dus ook met real-time kernel!

[Hydranet]

Voor degene die een eigen Mars Rover willen ontwikkelen

[Verwijderd]

Ik weet niet in welke mate dit nog op gaat, maar Ubuntu Studio had altijd een RT kernel.
Deze gebruikte ik voor de aansturing van MIDI apparaten, dit om geen vertragingen te krijgen bij het maken van muziek.

[jvnknvlgl]

Interessant dat ze dit uitbrengen met ondersteuning. PREEMPT_RT zit erg dicht bij mainline Linux dezer dagen, de doelstelling is om binnen enkele releases het benodigde werk in de kernel zelf te hebben dus dan is er geen patchset meer nodig en kan je gewoon je kernel met andere instellingen compilen.

Ik heb ooit een vergelijking moeten maken tussen deze patchset en een andere methode (Xenomai), en daar kwam uit de bus dat Xenomai toch nog de betere optie was als je strictere real-time-requirements hebt (en kan accepteren dat je voor sommige zaken nieuwe drivers moet schrijven, zoals SPI), maar ik kan me voorstellen dat dit erg handig kan zijn voor bepaalde robotica-toepassingen omdat je een stuk minder zelf hoeft te onderhouden.

[blorf]

Ik snap het hele doel eigenlijk niet. Servers hebben andere activiteiten, maar wat bedoelen ze? Dat je xterm nog steeds meteen opkomt als je server op full load draait? Het moet iets zijn dat niet meer veranderd kan worden als de kernel is geladen, andders zou het ook wel een module kunnen zijn. Dat leidt logischerwijs weer tot de vraag waarom deze performance-setting op kernel-niveau moet bestaan.

[Reactie gewijzigd door blorf op 22 juli 2024 16:09]

[bzuidgeest]

Dat is niet wat realtime os betekend. In industrie worden typish real-time os gebruikt. Als je een lopende band bestuurd wil je niet dat de software even met iets anders bezig dan dopjes schroeven. Real-time slaat vooral op de hoge voorsspelbaarheid van taken en gegarandeerde afhandeling. Deze kernel is ook nauwelijks volledig realtime in de industriele zin.

Het heeft in ieder geval weinig te maken met desktop response tijden.

van wikipedia:
https://en.wikipedia.org/wiki/Real-time_operating_system
A real-time operating system (RTOS) is an operating system (OS) for real-time computing applications that processes data and events that have critically defined time constraints. An RTOS is distinct from a time-sharing operating system, such as Unix, which manages the sharing of system resources with a scheduler, data buffers, or fixed task prioritization in a multitasking or multiprogramming environment. Processing time requirements need to be fully understood and bound rather than just kept as a minimum. All processing must occur within the defined constraints. Real-time operating systems are event-driven and preemptive, meaning the OS can monitor the relevant priority of competing tasks, and make changes to the task priority. Event-driven systems switch between tasks based on their priorities, while time-sharing systems switch the task based on clock interrupts.

[blorf]

Ik vermoed zelf wel dat het gaat om een blijvend reactieve gebruikersinterface, dus meteen anticiperen op niet-voorspelde events. Om "real-time" te zijn hoeft het systeem alleen maar de maximale frequentie van handelingen in een proces te overtreffen om er nog iets anders bij te kunnen doen zonder dat dat het primaire proces beinvloedt.. Dat is bij computers nooit een probleem. Binnen is altijd veel sneller dan buiten.

Ik probeer iets te zoeken waar dit voor nodig zou zijn. Een industrieel proces dat vanwege de vereiste nauwkeurigheid de hele tijd zichzelf moet kalibreren en een constante stream aan correctie-data genereert... Dat ga je niet met een linux "distro" doen. Misschien een kaalgestripte kernel met een loop voor interactief beheren van het systeem. Dat mag dan niet meer opeisen dan de rest van het proces toe laat.

[Reactie gewijzigd door blorf op 22 juli 2024 16:09]

[bzuidgeest]

Je kunt vermoeden wat je wil, maar dat is gewoon niet waar het voor bedoeld is en wat realtime-os betekend. Als er al iets met de gebruikersinterface zou gebeuren dan is het dat deze slechter gaat reageren omdat prio word toegekend aan het afhandelen van OS activiteiten die gegarandeerd moeten worden. Jou klik is niet spannend in een industrieel proces. Ubuntu server word overigens zonder desktop geinstalleerd standaard.

Zoek eens of QNX, freeRTOS, CHIBIOS allemaal voorbeelden van realtime os.

De reden dat ze dit in linux proberen te krijgen is simpel. De enorme hoeveelheid libs beschikbaar is enorm en er zijn best wel wat realtime toepassingen die een beetje minder kritiek zijn die een linux omgeving kunnen tolereren.

[blorf]

Hoezo is een kernel module niet afdoende? Kijk eens naar wat voor iteratie-snelheid die heeft in een gemiddelde linux. Wat voor proces vereist een hogere snelheid dan dat?

[bzuidgeest]

Nogmaals het gaat niet om snelheid. Dat is wat mensen denken bij die naam, maar dat is fout. Het gaat om garanties van tijd. Ofwel als een proces 10msec mag duren, dan moet het ook 10 zijn en niet 11 omdat het os even een venstertje aan het tekenen was. Een realtime proces kan uren duren. zolang het maar in de "afgesproken/verwachte" tijd geregeld word. Het gaat om proces prio's, interrupt afhandeling.
Heb je het gelinkte wikipedia artikel gelezen?

[blorf]

Als de maximale tijd die een proces mag duren langer is dan een kernel loop-interval lijkt me dat geen probleem. Het begint als je een cpu of controller gebruikt die eigenlijk ondermaats is voor wat je in totaal wil doen. En daar moet dan linux op draaien om een andere reden.

[bzuidgeest]

Ik geef het op. Het is mij duidelijk dat je het wikipedia artikel dat ik linkte niet begrepen hebt of niet gelezen. Je focust je op dingen die totaal irrelevant zijn voor de Realtime OS definitie.

[blorf]

Een OS dat op geen manier vertraagd kan worden door rand-processen. Ik denk dat real-mode ook een goed idee is... Dan heb je precies wat de specs vertellen. Een OS zonder subsystemen of achtergrondprocessen of wat dan ook... Multitasken kan, maar alleen met de resources die echt over zijn.

[Reactie gewijzigd door blorf op 22 juli 2024 16:09]

[J_van_Ekris]

Een OS dat op geen manier vertraagd kan worden door rand-processen. Ik denk dat real-mode ook een goed idee is... Dan heb je precies wat de specs vertellen. Een OS zonder subsystemen of achtergrondprocessen of wat dan ook... Multitasken kan, maar alleen met de resources die echt over zijn.

Dat is niet wat een PREEMPT kernel doet. Je kunt dat zelf doen, maar dat is niet wat PREEMPT doet. PREEMPT zorgt er voor dat grote processen geen langdurige exclusieve claim op de kernel kunnen leggen, en dat de kleine high HW-priority interrupts betrouwbaarder kunnen voordringen voor de slome logge applicatie-requests.

[blorf]

Een pre-emptive kernel maakt nog geen real-time OS. Dat is een gedrag waarbij de kernel onmiddelijk onderbroken kan worden voor iets anders zonder dat er een procedure afgemaakt hoeft te worden. Handig voor het directe reageren bij een RTOS.
Een RTOS vs gebruikelijk OS moet je zien als het verschil tussen tandwielen en een snaar-overbrenging. De tandwielen houden hoe dan ook een 100% vaste verbinding. Ze kunnen niet per tand afwijken.
Overigens had ik het daar helemaal niet over, dat doe je zelf. En dan mij vertellen wat het niet is, ok.
Nooit een RTOS op een PC gedraaid, maar ik denk dat het daardoor op een microcontroller/PLC gaat lijken die alleen maar procedureel instructies afwerkt met een absolute tijdsduur. Linux zal waarschijnlijk gaan bekijken of we ook nog iets er naast kunnen doen zonder dat proces te beinvloeden. Dat is bij een hedendaagse PC altijd het geval. Het is nogal jammer om 300 Watt te verstoken voor de activiteit van een dure rekenmachine.

[Reactie gewijzigd door blorf op 22 juli 2024 16:09]

[J_van_Ekris]

Je beseft dat je nu RTOS aan probeert uit te leggen aan iemand die 25+ jaar ervaring in embedded systemen heeft?

Nooit een RTOS op een PC gedraaid, maar ik denk dat het daardoor op een microcontroller/PLC gaat lijken die alleen maar procedureel instructies afwerkt met een absolute tijdsduur. Linux zal waarschijnlijk gaan bekijken of we ook nog iets er naast kunnen doen zonder dat proces te beinvloeden. Dat is bij een hedendaagse PC altijd het geval.

Dat denk je totaal verkeerd, maar ik sluit me aan bij @bzuidgeest dat ik mijn tijd niet ga verspillen aan iemand die het gewoon niet gaat/wil snappen.

[Reactie gewijzigd door J_van_Ekris op 22 juli 2024 16:09]

[blorf]

De standaard reactie bij geen gelijk krijgen. Idd, doe geen moeite. Er is niemand die daar ooit iets mee heeft bereikt.

Hoe kom je trouwens bij dat "PREEMPT" ? Lijkt op een linux-achtig kernel config keyword...

[Reactie gewijzigd door blorf op 22 juli 2024 16:09]

[J_van_Ekris]

Als de maximale tijd die een proces mag duren langer is dan een kernel loop-interval lijkt me dat geen probleem. Het begint als je een cpu of controller gebruikt die eigenlijk ondermaats is voor wat je in totaal wil doen. En daar moet dan linux op draaien om een andere reden.

Ik denk dat je gewoon niet snapt wat real time betekent. Lees het wikipedia artikel.

Het gaat niet om ondermaats zijn van een CPU, maar responsive zijn op HW-interrupts en zonder dat andere rare processen en interrupts zaken kunnen frustreren dingen oppakken. Ik kan je vertellen, je kunt CPU load op 1% hebben staan, maar een fout proces kan de kernel-toegang gewoon 2ms (of langer) vasthouden, en dat kan je proces flink over de zeik helpen.

[Reactie gewijzigd door J_van_Ekris op 22 juli 2024 16:09]

[bzuidgeest]

Doe geen moeite, na 6 posts had ik het nog niet duidelijk voor @blorf, maar wellicht heb jij meer succes

[satya]

Lijkt mij niet verstandig dat zoiets virtueel draait dan.....

[J_van_Ekris]

Ik snap het hele doel eigenlijk niet. Servers hebben andere activiteiten, maar wat bedoelen ze? Dat je xterm nog steeds meteen opkomt als je server op full load draait? Het moet iets zijn dat niet meer veranderd kan worden als de kernel is geladen, andders zou het ook wel een module kunnen zijn. Dat leidt logischerwijs weer tot de vraag waarom deze performance-setting op kernel-niveau moet bestaan.

Dit gaat juist niet om servers, maar vaak om IoT achtige oplossingen, die near-real-time hardware aan het besturen is. Daar moet de kernel zijn werk doen, maar daar mag een ander proces geen road-block vormen voor de uitvoering van zijn primaire taak (hardware besturen). Dit moet juist grotendeels in de kernel opgelost worden, omdat die verantwoordelijk is welk proces wanneer tijd krijgt, en wanneer iets in de ijskast geduwd mag worden. Om de tijdskritische processen voorrang te geven op de momenten dat het moet, moet de kernel dat dus gaan doen.

[blorf]

Microcontrollers? Die kun je gewoon niet meer belasten dan waar ze voor gemaakt zijn. Of iets een IoT-apparaat is lijkt me niet relevant. Dat heeft een draadloze bediening en dat kun je logischerwijs ook nog via internet doen. Het hele kenmerk.

[Verwijderd]

Real Time heeft (duidelijk) te maken met 'echte tijd'. Dit betekent dat je als gebruiker van een systeem met een RT kernel ervan uit kan gaan dat een taak afgehandeld is binnen een voorspelbare 'echte' tijd, zonder de onduidelijkheid van hoe lang een taak in I/O blijft hangen of wacht op interrupts.

Voor normale desktop gebruikers (of zelfs het gebruik van servers) is een RT kernel juist niet de beste keuze, dit omdat bepaalde taken juist trager kunnen worden. (RT betekent niet snel, maar voorspelbaar).

Toen ik nog op school zat gebruikte we RT kernels voor de aansturing van ADC apparatuur om met een behoorlijke sample-rate analoge data te kunnen sampelen (Je wil dat de tijd tussen samples vrij exact is). (Normaliter is het de taak van de hardware zelf om de tijd tussen samples exact te houden, dus via een microcontroller oid, maar daar ging de les niet over )

[J_van_Ekris]

Interessant dat ze dit uitbrengen met ondersteuning. PREEMPT_RT zit erg dicht bij mainline Linux dezer dagen, de doelstelling is om binnen enkele releases het benodigde werk in de kernel zelf te hebben dus dan is er geen patchset meer nodig en kan je gewoon je kernel met andere instellingen compilen.

Punt is wel dat de dingen die in zijn algemeenheid een goed idee waren in de afgelopen jaren de mainstream linux kernel wel bereikt hebben, en dat de resterende patches steeds meer negatieve impact op generieke toepassingen hebben. Dus ik vermoed dat de mainstream en PREEMPT kernel steeds dichter bij elkaar komen te liggen, maar dat de verschillen steeds taaier worden om nog weg te werken zonder dat de algemene gebruiker nadelen ondervind. Zoals je al zegt: mogelijk eindig je met een hoop compiler-opties voor de Kernel.

Maar Ubuntu heeft al een tijd als additionele kernel de IoT (PREEMPT) kernel gehad, en Raspberry Pi's OS 64Bit Lite variant is ook PREEMPT, dus je ziet wel dat men ontdekt heeft dat de behoefte er is. Voordeel van een standaard kernel is dat je een hoop packages gewoon niet meer zelf hoeft te compilen, wat een verademing is. Gewoon apt-get en het draait, zonder dependency hell en ellende met afwijkende compiler settings. Ik hoop dat deze trend doorzet, want voor soft-real-time spul is het echt een uitkomst.

[sdziscool]

Lijkt me superleuk om zelf is een keer aan de slag te gaan met linux kernel optimalisaties. Als je nagaat hoe bijvoorbeeld linus torvalds de originele scheduler from the ground up heeft gemaakt, nam dat (zeer onverwacht) ongeveer een dagje tijd, terwijl hij weken tot maanden had aangenomen.

Misschien leuk om een keer over te hebben op de fora ofzo.

[Accretion]

Bare metal programming is ook wel leuk, je hebt dan géén OS

Dat betekend dus dat je zélf kan programmeren wanneer bepaalde inputs afgehandeld worden.

[kabelmannetje]

Realtime kernel heeft niks met servers te maken. Maar, wel met toepassingen waar een maximale bepaalde latency voor nodig is. Dus met name voor een breed scala aan embedded besturing van machines.

[Dark Angel 58]

Real time OS = Levend OS?

[M3m3nt0m0r1]

Nee. Je moet aan dit denken: https://en.wikipedia.org/wiki/Real-time_computing

[beerse]

Hier staat 'real time' voor 'echte tijd' in de betekenis van 'van te voren bekende tijd': Als een real-time systeem een actie oppakt, dan zal ze het in de afgesproken tijd afronden. Niet langzamer maar ook niet sneller. Anders pakt ze de actie niet op of maakt ze de tijd-afspraak niet.

Vroeger werd wel eens verkondigd dat een real-time systeem het snelst is maar dat is per definitie niet zo. Het snelste systeem kijkt nergens naar en doet wat het wordt opgedragen zo snel mogelijk. In de praktijk zal zo'n systeem wel als 'real-time' ervaren als het slechts licht wordt belast. Maar zodra het zwaarder wordt belast...

Zoals op https://en.wikipedia.org/wiki/Real-time_computing staat zijn er verschillende gradaties.

[JBVisual]

Ik snap je opmerking niet....

Letterlijk vertaald zou het "Echte Tijd OS" zijn, maar "levend OS" zie ik op geen enkele manier terug in de benaming. (dan zou je "living OS" moeten hebben)

[Dark Angel 58]

Ik snap je opmerking niet....

Letterlijk vertaald zou het "Echte Tijd OS" zijn, maar "levend OS" zie ik op geen enkele manier terug in de benaming. (dan zou je "living OS" moeten hebben)

Denk maar aan een 1 computer dat hele mensheid moet bedienen, miljard opdrachten aan 1 computer die zonder onderbrekingen van andere opdrachten kunt uitvoeren. 24 uur lang per dag. Dan lijkt een computer meer levend, omdat het geen enkele rust kent.

[likewise]

Als je met Linux echt lage latencies wil is er naast PREEMPT_RT nog de mogelijkheid tot cpu task isolation, waarbij je een een applicatie op 1 core draait, die zoveel als mogelijk niks anders doet. De meeste patches daarvoor zitten inmiddels ook in de kernel.

Voor PREEMPT_Rt is deze site handig: https://www.osadl.org/Lat...owno=&shadow=1&slider=333

[likewise]

https://lwn.net/Articles/883940/

Dus grotendeels losstaand van PREEMPT_RT.

"Certain types of applications benefit from running uninterrupted by
background OS activities. Realtime systems and high-bandwidth
networking applications with user-space drivers can fall into the
category.

To create an OS noise free environment for the application, this
interface allows userspace to inform the kernel the start and end of
the latency sensitive application section (with configurable system
behaviour for that section)."

[Reactie gewijzigd door likewise op 22 juli 2024 16:09]