Názory k článku
Real-time Linux se po dvaceti letech dostane do hlavní větve jádra

To mi přijde docela zásadní.

Samozrejme, hlavne, ak

1.tam bude

>aby reagoval na události a zpracovával data v přísně omezeném čase, který se
>často měří v milisekundách nebo mikrosekundách.

občas aj v desiatkach nanosekúnd

1. hlaven sa všetci boja, aby to zostalo, keďže na to majviac robili Ingo s Thomasom

02-23-2022

Last week at the Intel 2022 Investor Meeting, company leaders reiterated our commitment to foster an open ecosystem that ensures trust, choice and interoperability for our industry. Today, in a furtherance of that commitment, we are excited to announce Intel’s acquisition of Linutronix.

Linutronix is comprised of a team of highly qualified and motivated employees with a wealth of experience and involvement in the ongoing development of Linux. Led by CEO Heinz Egger and CTO Thomas Gleixner, Linutronix is the architect of PREEMPT_RT (Real Time) and the leading technology provider for industrial Linux. Gleixner has been the principal maintainer of x86 architecture in the Linux kernel since 2008.
https://community.intel.com/t5/Blogs/Products-and-Solutions/Software/Intel-Acquires-Linutronix/post/1362692

Ingo Molnár
Together with Thomas Gleixner, he worked on the real-time preemption (PREEMPT_RT) patch set, which aims to reduce the maximum thread switching latency of the Linux kernel from an unbounded number of milliseconds to down to bounded values in the order of tens of microseconds (depending on the system)https://­en.wikipedia.or­g/wiki/Ingo_Mol­n%C3%A1r
https://en.wikipedia.org/wiki/Ingo_Moln%C3%A1r

+ Dr. Carsten Emde a jeden pán profesor z Videne a potom z Číny (edit: napadol ma prof. Nicholas McGuire)

a k tomu
4. 8. 2024

Intel propustí minimálně 15 tisíc lidí
https://www.root.cz/clanky/intel-bude-masivne-propoustet-kde-vylepsuje-discover/

Tak by to mohlo "skapať.", ak by to neskončilo v hlavcnej vetve

19. 9. 2024, 11:15 editováno autorem komentáře

"02-23-2022" preboha to co je za datum?
;)

mesiac-den-rok parkrat som to uz videl v nejakych prikladoch. Tusim sa to pouziva v niektorych statoch usa. fajn vec, ak chces triedit data v ramci jedneho roka.

Tohle pořadí je typické pro americkou angličtinu, ale tam se části oddělují lomítkem. Právě proto v mezinárodní komunikaci radši používám ISO formát, protože pomlčky/spojovníky se jinde jako oddělovač nepoužívají, stejně jako rok na začátku, takže se to s ničím neplete.

USA, kde jsem to jen slysel ... jo pockej ty myslis tu zaostalou zemi co porad pouziva palce a mile?

Protože YYYY-MM-DD se v rámci roka třídí blbě, že?

Já jsem to ještě nikdy neviděl. Tenhle zápis je totiž naprosto nelogický. Právě že se to řadit moc nedá, protože je tam ten rok a tím pádem to stejně musíš naparsovat. Stejně mě neskutečně štve, že nejsme schopní se dohodnout na jednom zápisu ani u takových blbostí, jako je datum nebo jak budeme oddělovat čísla, jestli čárkou nebo tečkou. Vrcholem je už použití jiných jednotek.

Zásadní? Asi jak pro koho. Takto přesná zařízení jsou možná tak max 0,1% celkového trhu. V domácnosti nepotřebuješ žádné takto přesné zařízení.

Domácnost už dávno vývoj linuxu netáhne. A nejde ani tak o přesnost, ale o determinismus. Žádná nečekaná zdržení.

A tam už v mikro až milisekundách jedou telekomunikace, automotive, průmysl..

Často jim ani tak nevadí samotné zpoždění, ale vadí jitter.

... pokud chces deterministicky chovani, tak automaticky rikas, ze to nebuide x86 a pousta dalsich architektur. Nepripada v uvahu jakakoli predikce a podobny techniky.

Protoze jestli od toho neco chces predevsim, tak to, aby bylo naprosto jasny jak dlouho (= kolik cyklu) co bude trvat. A to nema nic spolecnyho s kernelem.

Nemluve o tom, ze na takovy aplikace se nepouziva zadny system, ale je to kod nasazeny na konkretni HW.

To co muzes resit na urovni kernelu je tak maximalne to, ze budes aplikaci garantovat nejaky podil na tech CPU cyklech. Ale vsechny nedostane nikdy, protoze nezbytne musis obsluhovat i ty veci kolem.

Deterministické maximální zpoždění může být i sekunda. RT neříká jak dlouhý ten interval může být. Řešil jsem jak 10 mikrosekund (telco), tak 1 milisekundu (industry 4.0) a dokonce i 200 milisekund (překvapivě taky telco).

Přesnost na úrovni cyklů nikdo na téhle úrovni neřeší.

Všechno je deterministické

Ano, a proto existuje třeba teorie chaosu. Deterministické jevy s tolika vstupními proměnnými, že se výstup nedá předpovědět.

Determinističnost nemá zas tak moc společného s předpovídáním. Tím jsou akorát mnozí posedlí, protože si myslí, že z determinismu vyplývá, že si můžou všechno předpovědět.

To by jste se divil, kolik aplikací musí být, nebo je lepší když jsou RT. Ano, většinou to není vidět, ale je to důležité

Nevím teda, ale i ta nejlevnější pračka má PCM řízení motoru, ne?

PWM ? Popravdě spíš superlevný frekvenční měnič (frequency inverter drive), třífázový na výstupu, konstruovaný nejlevnějším možným způsobem. Vstup jednofázový, až po akumulační kondík na primáru to vypadá dost jako napájecí zdroj PC.

Hned bych jedno minimálně v mé domácnosti znal které z toho může težit (a které na RT spoléhá)... 3D tiskárna. Pokud se Vám začne nepředvídatelně zpomalovat klipper, nestačí se krmit board který se stará o tisk a celý to skončí tak trochu neslavně...

I obycejna tiskarna na papir kdyz jsme u toho:-)

Hm, moje obyč ink tiskárna přes wifi prostě zastaví a po pár sekundách pokračuje. 3D by se to samozřejmě nelíbilo, ale tam je arduino, jehož FW to naštěstí stíhá.

A tusite jak je na tom operacni system uvnitr te tiskarny? Jak je precizni timing dulezity?

Ono dost záleží na "architektuře" tiskárny. Mám tu třeba MK3S+, který má 8-bitovou Atmegu. Jak tušíte, 8-bitová atmega toho moc nespočítá. Proto na ní mám Klipper, kdy téměř všechny výpočty běží na RPi a atmega je jen na low-level komunikaci s HW. A to je ten kámen úrazu pokud nemáte RT. Pokud dojde k nějakému zpomalení RPi, je to problém...
V podstatě stejně fungují Vorony a řekl bych že stejně funguje téměř každá tiskárna postavená na Klipperu.
Marlin jde druhým směrem, kdy se to snaží upočítat na MCU. Jenže to přináší spoustu jiných problému, kdy na omezeném výkonu MCU horko-težko upočítáte spoustu advanced výpočtů (pressure advance, input shaper ...), ohandlujete zároveň komunikaci, kamery, atd. atd. Sice teď s nástupem 32-bitových desek to je o hodně lepší ale stále mě tahle architektura přijde mnohem lepší z hlediska budoucí kompatibility a rozšířitelnosti.

Naopak, i doma se to běžně používá třeba u zvukařů.

V mainline uz bolo threadirqs

No se to šikne třeba na zpracování muziky (ardour a spol..) Takže mainstream úplně ne,ale jeden z důvodů obliby applů pro muzikanty

Spis u jablka mam kompletne deterministicky audiosystem. Micsosoft ten svuj dodrbal kolem win 8.

Až na ten Ardour :)

Jako DAW mi naprosto vyhovuje Reaper. Stojí pár kaček a podpora linuxu perfektní.

Je to dávno co jsem koukal na RTlinux a RTAI. Nevýhodou těchto "out of tree" projektů je... že jsou out of tree. Musí se přizpůsobovat vývoji upstreamu, tj. za ním opožděně klopýtat.

Takhle bude možno některým úlohám dát poměrně solidně vyfutrovanou garanci latence v klíčových bodech, kde systém občas "tlačí bota" - samozřejmě především v plánování procesů. A tahle volitelná vlastnost se bude údržbovat jako součást mainstreamu.

Pokud správně chápu, PREEMPT_RT víceméně ovlivní chování aktuálního plánovače/plá­novačů. Což je rozdíl oproti RTlinux/RTAI, které do systému vkládají svůj vlastní nanokernel / starý dobrý Linux běží jako jedna z úloh nanokernelu.
On ale celý ten patch PREEMPT_RT dělá drobné změny v mnoha oblastech, a v průběhu let spousta jeho nápadů a "nutných podmínek" do mainstreamu dávno probublala.

VxWorks neznám. QNX jsem párkrát periferně zaznamenal... podpora pro nový hardware je docela dobrá, pokud jdete s vývojem a přijímáte nové verze QNX. Přesto si myslím, že Linux má ovladače pro širší a snad i čerstvější spektrum hardwaru. A má mnohem rozsáhlejší "ekosystém" = dostupný hotový software, a bohatší množinu fičur.

Jsem docela zvědav na nějaké benchmarky / měření, jak moc hard realtime bude tahle nová realtime podpora :-)

Další čtení:
https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf

Problém linuxu pro tento trh jsou bezpečnostní certifikace. Třeba zrovna to QNX je plně certifikované.

https://blackberry.qnx.com/en/developers/certifications

U linuxu to prakticky nejde udělat, právě proto, že je tak velký a složitý.

Ano, spousta vylepšení ohledně latence se do mainline už dostala, ale PREEMPT_RT přepne třeba mechanizmus zámků na preemptivní (tj dají se přerušit). Což stojí výkon, ale získáte determinizmus.

Pracoval na tom hodně Daniel Oliveira, který bohužel nedávno zemřel: https://lwn.net/Articles/979912/

RE. "předvídatelné chování":

Spíš "předvídatelněj­ším".
OS se skutečně předvídatelným chováním, to je ještě jiná liga.

Kdysi na takovém dělala DARPA, ale pak to utichlo.
Buď se jim to podařilo, nebo to šlo k ledu.

19. 9. 2024, 17:36 editováno autorem komentáře

Myslim, ze tady uz dost slovickarite... a pritom vam unika kontext. Absolutni predvidatelnost je chimera a nemyslim si, ze by az tak striktne si to kdokoliv vubec vykladal. Samozrejme, ze vzdy muze nastat neco zcela nepredvidatel­neho... ale je taky nutne zohlednit i to, zda-li ten stav realne zpusobi problem. Ono i samotne zhodnoceni te "predvidatelnosti" je... ehm.. subjektivni vjem.

Ano, je to slovíčkaření.

A jak jinak se dobrat relevantního popisu, než přesným vymezením pomocí slov?

Přídavné jméno "předvídatelný" najdete u RTOS i na Wikipedii, ale asi to tam bude potřeba upřesnit. I u klasického OS také chceme, aby fungoval předvídatelně, a u RTOS se oblast předvídatelnosti rozšiřuje i na fungování plánovače úloh, obsluhu vstupů, zpracování, v definovaných časových úsecích.

Uniká mi kontext?
Je to zprávička, která trochu nešťastně zabrousila do oblasti vysvětlování.
Podstatnější v kontextu dané zprávičky je, že realtime Linux tu s námi je desetiletí, a že kdo ho potřebuje používat, mohl ho používat. Také se hojně používá.
A od tohle začlenění se očekává, že usnadní nasazování, vývoj a údržbu.

Ak si uvedomíme, aký je x86 HW nedeterministický,

Experiment type Mean value [s] Standard deviation [s] Median [s]
C code without data transfer inside RAM 6.271 2.000 5.015
C code with data transfer inside RAM 14.530 3.662 12.180
OpenCL code without data transfer between VRAM and RAM 0.940 0.100 0.940
OpenCL code with data transfer between VRAM and RAM 1268.060 59.470 1276.820

Zdroj
Jedno moje meranie pri výpočte súčtu dvoch vektorov
ISBN: 978-1-61804-056-5 rok 2011

Tak na ňom urobiť deterministický SW je prakticky nemožné, to bude na fungovať na nejakom starom MIPS-e ako v PLC

20. 9. 2024, 11:32 editováno autorem komentáře

A kolik ukazoval hwlat tracer? Měl jste přesměrované interrupty, vyplý kernel scheduler atd?

Ono totiž nastavit x86 PC s linuxem do deterministického stavu jde. Jinak bych nemohl řešit systémy, kde zpoždění zpracování paketu je garantovaně do 10 us v 99.999999% času a zbytek do 20 us.

"Ono totiž nastavit x86 PC s linuxem do deterministického stavu jde"

a co treba SMI a SMM, to do toho trochu hazi vidle

To je přesně to, co hwlat měří a dá se to řešit. Velcí výrobci pro to moji Low latency profily v BIOSu, které hodně těch SMI vypnou.

Jak to chcete udelat kdyz u moderni x86 nevite presne jak dlouho trva vykonavani instrukce? A to se ani nebavim o deterministicky chovajicich se periferiich

Moderní PC je tak rychlé, že tohle je pro naprosto drtivou většinu aplikací nezajímavé.

Nebo vy znáte nějaký běžný problém, kde by délka PC instrukce hrála roli pro reakce v desítkách až stovkách nanosekund?

I těžké problémy (softwarová rádia s FEC) jsou o řád až dva výše (reakce do 10 us).

Napadají mě akorát řídící obvody pro samotné interní sběrnice jako PCI-e. Ale tam použijete specifický čip pro daný problém. Stejně jako pro akceleraci zpracování síťového provozu (pokud tedy nemáte NVidia BlueField karty, což je integrované "PC").

Samozřejmě je řada nástrojů a postupů, jak docílit větší predikovatelnosti obsluhy událostí a větší stability systému.

Traduje se, že obslužné programy kosmických sond testovali s upilovanými pouzdry procesorů a ostřelovali je za chodu elektronovým dělem.
Tam kde to bylo třeba běžely redundantně další systémy a arbitr porovnával výsledky.