Vlákno názorů k článku GNU/Linux pro řízení a rychlost jeho odezvy od vychylky ve 3D grafu - Hoj! Co jsou zac ty dva obrovske vykyvy v...
-
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.
ČLÁNKY DO MAILU