Názory k článku GNU/Linux pro řízení a rychlost jeho odezvy
-
Systém je v testu po dlouhou dobu a často se po upgrade jádra zjistí, že některý ovladač nebo subsystém prošel úpravami, při kterých se na deterministické odezvy nemyslelo nebo obsahuje přímo chybu. Další možnost je, že je problematické chování způsobené přímo hardwarem a pak je žádoucí nalézt postup, algoritmus, který umožní takové chování hardware potlačit. Pokud se u sledovaných systémů problém/regrese vyskytne, tak je to informace pro vývojáře, že je potřeba začít ladit. OSADL je pak schopné takovou trvalou službu/údržbu platformy na základě kontraktu řešit.
Rozdíl mezi non-RT jádrem (aktuálně 4.1.19-v7+) na výkonnějším RPi2
https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs3.0.html?shadow=0
a RT jádrem na slabším RPi1
https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s3.0.html?shadow=0
Případně si projděte přehlídku jader,
https://www.osadl.org/Linux-kernels-under-test.qa-farm-kernels.0.html
kliknutím na pole Kernel version v záhlaví tabulky, si je lze pěkně srovnat.
Takto pak vidíte na x86 perfektní RT Linux 4.4.9-rt17https://www.osadl.org/Latency-plot-of-system-in-rack-2-slot.qa-latencyplot-r2s7.0.html?shadow=0
a bohužel k porovnání ekvivalentní no-RT zrovna není. Ale bude to podobné jako u toho RPi2.
-
Jen pro ujištění, myslíte ty dva široké pásy, kdy po odhadem desítku běhů mnohahodinového testu jsou histogramy roztažené přes celou šířku záznamu. Taková distribuce odezev je katastrofální a vylučuje použití v RT aplikacích. Za zdroj předpokládám upgrade jádra a boot non-RT varianty. Poté, předpokládám, následoval boot RT jádra. Takováto distribuce odezev není typická pro specifické chyby, tam je to většinou jedna, dvě špičky v rovné ploše a je jasné, že hledání takového zdroje je velmi náročné. Pokud to není problém HW, tak příčiny delší doby blokování plánovače nebo zakázání přerušení lze zjistit u RT jádra kompilací s nastavenými volbami
Interrupts-off Latency Tracer (IRQSOFF_TRACER)
atd. Jádro obsahuje subsystém Ftrace a ten může být zkompilovaný tak, že informace o blokujících úsecích zaznamenává a vyhodnocuje. Jedná se o záznamy událostí
irqsoff, preemptoff, preemptirqsoff, wakeup, wakeup_rtPopis viz již trochu starší článek
https://static.lwn.net/images/conf/rtlws11/papers/proc/p02.pdf
nebo
-
K D (neregistrovaný)
Ano, měl jsem na mysli ty dva široké pásy. Nechci být pedant, ale zmíněno to nebylo a přehlédnout to jaksi nešlo.
[A] Předpokládám, že frekvence je měřena ve smyslu příchozích požadavků přímo na měřeném RT/non-RT.
Nejsem si ale jistý, jestli je to pak rebootem + nějakými operacemi. Jde o to, že u rebootu - tedy dočasnému DOS - by tam frekvence musela být 0 a ne poloviční.
Prostě v nějakém čase by musel být plný výpadek. Buď to v grafu není a pak se nepodařilo zajistit naplnění Shannon-Kotělnikova vzorkovacího teorému a nebo to z něj není zřejmé a graf je tedy nevyhovující.To že je frekvence poloviční spíše ukazuje na nějaké vytížení zdrojů, kdy ani není schopno tolik přijímat a je to vykoupeno i vysokou latencí - spíš možná kvůli nějakým operacím uvnitř měřeného systému - třeba download nebo kompilace.
Ale je žádoucí při měření provádět tyto upgrady v podstatě náhodně? V reálném provozu je samovolný upgrade asi nežádoucí a tedy i při měření, akorát to rozbíjí celý graf a příčina se evidentně blbě hledá. Mě se teda nepodařilo zjistit čím to je . . . ale možná jsem to jen někde v těch zdrojích přehlédl . . .Děkuji, i za odkazy.
-
K D (neregistrovaný)
Dobrý den, děkuji za článek.
Na začátku se autor tázal, zda by byl zájem o další články v návaznosti na plánované dva, tak za mě určitě ANO.
K dnešnímu článku bych se chtěl zeptat, jestli mi může někdo odpovědět, co v grafu "Zaznamenané histogramy/profily latencí za měsíce běhu" znamenají ty dva výběžky v "latency", resp. čím jsou způsobeny, když nebyly do celkové maximální "latency", tedy 250 µm za měsíc, zahrnuty?
Děkuji
-
Viz předchozí odpověď. Jedná se téměř na 100% o přechody na nové neodladěné jádro nebo puštění non-RT varianty před provedením update RT jádra. Může se také jednat o mohlo by se také jednat o velmi sporadickou chybu, která by vedla ke změně chování v daném běhu, ale to by byl jen jeden záznam.
Jinak položka "Display most recent latency plot" zobrazuje právě profil jen posledního běhu, poslední řez 3-D plochou. Kompletní záznam historie je k dispozici jen členům OSADL. Chyby, které vývojáři ale většinou loví, se projevují občasným výskytem jednoho vzorku (jedné špičky) vpravo za "obalovou křivkou" a takové problémy trvá odlovit dlouho.
Co je naopak k dispozici všem, jsou patche, které byly v rámci práce OSADL vyvinuté
https://www.osadl.org/Profile-of-system-in-rack-b-slot-7.qa-profile-rbs7.0.html#patches
hlavní smysl je pak dostat tyto úpravy do mainline jádra nebo alespoň RT forku, který se stále zcela zaintegrovat do mainline nedaří - některé úpravy snižují propustnost, zvětšují komplexitu a nedaří se sehnat dostatek organizací, garantujících Linusem a Thomasem Gleixnerem požadovanou úroveň podpory.
-
K D (neregistrovaný)
Děkuji, tu nahoře jsem taky četl. V podstatě jsem si nevšiml, že už se tam na to někdo ptal. Nezkoušeli jste třeba Yocto?
https://www.yoctoproject.org/ -
sid (neregistrovaný)
pekny clanok a zaujimave informacie. Na okraj by mozno chcelo este podotknut, ze OS je len cast problemu. Zazil som uz rozhovor kde sa vazne riesil OS system a jeho odozvy a potom clovek videl ako v aplikacii sa veselo pouziju kniznice ktore maju daleko od nejakej predikovatelnosti.
-
robotron (neregistrovaný)
Pro me jako uzivatele je celkem jednoduchy psat v C s knihovnama, ktery si ohlidam (napr. nedavno mi stacilo ujistit se, ze neobsahuje jediny volani malloc()). Zato je pro me naprosto nepredstavitelny vrtat se v OS a snazit se tu chabymi pokusy neceho docilit. Pro me je teda docela uzitecny vedet, ze urcita podmnozina prg. prostredku je s ohledem na RT bezpecna a ty ostatni pouzit muzu, ale ne v castech, ktery vyzadujou definovanou odezvu.
Jinak moc prima clanek, diky, Pavle.
-
Pedro (neregistrovaný)
U KUKA pod Windows bezi jen GUI (v soucasnosti Windows Embedded 7), rizeni robota bezi pod vxWorks. Docist se o tom da tady: http://www.acontis.com/eng/products/windows-real-time-hypervisor/vxwin/index.php
