Vývojáři postmarketOS vydali verzi 23.06 tohoto před šesti lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, Plasma a Sxmo. Aktuálně podporovaných zařízení je 30.
Byla vydána distribuce openSUSE Leap verze 15.5 (poznámky k vydání). Jde o konzervativní distribuci odpovídající komerčnímu SUSE Linux Enterprise 15, nyní Service Pack 5. Mělo jít o poslední aktualizaci Leap v současné podobě před přechodem na Adaptable Linux Platform s „neměnným“ základem, ale padlo rozhodnutí, že v roce 2024 ještě vyjde Leap 15.6 s podporou do konce roku 2025.
Alyssa Rosenzweig v příspěvku na blogu oznámila, že Asahi Linux už zvládá OpenGL 3.1. Dokončuje se podpora OpenGL ES 3.1. Dalším krokem bude Vulkan 1.0.
Intel nedávno představil a pod licencí SIL Open Font License (OFL) na GitHubu zveřejnil font Intel One Mono. Font je určen především pro zobrazování textu v emulátorech terminálu a vývojových prostředích (Přehled fontů s pevnou šířkou).
Na redditu byly publikovány zajímavé QR kódy vygenerované pomocí Stable Diffusion. Přehled použitého softwaru v článku na Ars Technica.
Byl vydán Mozilla Firefox 114.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Nově jsou také na Linuxu podporovány USB FIDO2/WebAuthn bezpečnostní klíče. WebTransport je ve výchozím stavu povolen. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 114 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána červnová aktualizace aneb verze 2023.06-1 linuxové distribuce OSMC (Open Source Media Center). Z novinek lze zdůraznit povýšení verze multimediálního centra Kodi na 20. Na léto je plánováno představení nového vlajkového zařízení Vero, jež nahradí Vero 4K +.
Už zítra 7. června od 17 hodin proběhne SUSE Czech Open House 2023 aneb den otevřených dveří pražské pobočky SUSE. Těšit se lze na komentovanou prohlídku nebo přednášku o spotřebě procesorů.
Na vývojářské konferenci Applu WWDC23 byla představena řada novinek (cz): brýle Apple Vision Pro, MacBook Air 15” s čipem M2, Mac Studio s čipem M2 Max nebo M2 Ultra, Mac Pro s čipem M2 Ultra, iOS 17, iPadOS 17, macOS Sonoma, watchOS 10, …
Chystá se poslední jarní Virtuální Bastlírna. Nachystejte si ledové kávy, mojita a vodní chladiče a pojďte se se strahovskými bastlíři pobavit o technice a bastlení! Ptáte se, co mají bastlíři za novinky? Například se ukázalo, že OLED s SSD1306 ve skutečnosti nejsou nutně jen černobílé. Vyšla také nová verze KiCADu včetně betaverze pluginu pro tvorbu databázových knihoven pro KiCAD v InvenTree a na internetu se objevil USB
… více »Nechápeš to správně. Specializované realtime kernely existují proto že jinak to udělat nejde.Ale samozrejme ze to jde - v linuxu si vypne pozadovany pocet jader a pusti si na nich real-time aplikaci napsanou primo pro to zelezo bez kernelu. Celkem bezny postup v embedded.
tu nejde o pravdepodobnst ze se to stihne ale o zarucnou odpoved do daneho casu ....
Já vím - pouze rozvádím co napsal výšed rADOn (že lze na RT rezignovat).tu nejde o pravdepodobnst ze se to stihne ale o zarucnou odpoved do daneho casu ....
tak default je i u desktopu 100Hz .. ale vetsina jader je distribuci/uzovatelem nakonfigurova jinak a nic ti nebrani si jadro pro tvuj arm prelozit s vlastnim nastavenim ...
ale mam pocit ze vubec netusis co RT znamena ..
Domnívám se, že nevýhoda realtime aplikace bez realtime kernelu je, že se nedokáží realtime využívat různé běžící služby, jako např. pro odesílání paketů po wifi. Ale spustit realtime třeba přečtení dat z I2C sběrnice by jít mohlo.
To není tak úplně pravda, problém je i v tom, že bez realtime jádra nemůžete mít ani jistotu, že vám jádro v nevhodnou chvíli neodscheduluje váš proces na dobu delší, než by se vám líbilo. Pomineme-li poněkud extrémní triky typu výše zmíněného dedikovaného procesoru, dá se to riziko omezit nastavením realtime priority, ale pak je potřeba být velmi opatrný. (Oblíbená zábava je nastavit realtime prioritu procesu, který vůbec nespí, a pak se divit, proč je celý systém mrtvý.)
Oblíbená zábava je nastavit realtime prioritu procesu, který vůbec nespí, a pak se divit, proč je celý systém mrtvý.A toto se vam stalo nebo jste si to vymyslel? Kernel totiz bude tu RT aplikaci postupne prerusovat. Vizte kernel.sched_rt_period_us a kernel.sched_rt_runtime_us a taky RTFM!
A toto se vam stalo nebo jste si to vymyslel?
Mně ne, protože realtime priority používám jen výjimečně a dávám si pozor, abych je nepřiřazoval CPU intensive procesům. Ale několika našim zákazníkům se to podařilo (a to vím jen o těch, u kterých se to coby bugreport dostalo ke mně; ve skutečnosti jich asi bylo víc).
Vizte kernel.sched_rt_period_us a kernel.sched_rt_runtime_us a taky RTFM!
Takhle jednoduše to bude fungovat na jednoprocesorovém systému. Na víceprocesorovém si může "vypůjčit" nevyužitý čas z ostatních procesorů. Ve výsledku sice udusí "jen" jeden procesor, ale protože na něm spolehlivě odblokuje kernel threads, dříve či později to znefunkční celý systém nobo jeho podstatnou část, např. jakmile někdo zavolá schedule_on_each_cpu()
nebo něco podobného.
Na víceprocesorovém si může "vypůjčit" nevyužitý čas z ostatních procesorů.
Viz balance_runtime()
and do_balance_runtime()
.
Pokud to spustíte na všech procesorech, tak už není odkud půjčovat, takže začne účinkovat ten 95% limit. Problémová je situace, kdy běží např. jen jeden takový realtime proces "utržený ze řetězu". Různé věci v systému (od kterých by to člověk na první pohled nečekal) se pak postupně začnou blokovat.
Jeden z prvních příkladů, který jsem na toto téma viděl, vypadal tak, že se na jednom CPU proces s realtime prioritou točil v nekonečné smyčce a vedle druhý zavolá mlock()
. (Původní testcase byl komplikovanější, oni tam volali v nekonečné smyčce ten mlock()
a spustili to dvakrát, ale tahle zjednodušená verze je názornější.)
udelal jsem 6 testu postupne pro 1 az 6 procesu a ani jeden z nich nezpusobil "zasek" systemu (konzole byla porad pouzitelna)
Já taky netvrdil, že okamžitě nebude fungovat vůbec nic. Místo toho se postupně budou zasekávat různé procesy, které měly tu smůlu, že potřebovaly počkat na blokovaný procesor. Koneckonců, sám jste pozoroval, že při vašem testu začala zlobit síť - to může být u serveru docela zásadní problém.
Pouzivat libovolne syscally z RT procesu neni dobry napad,
Ten druhý proces, který volá mlock()
, nemusí být realtime. Podstatné je, že se zasekne, protože čeká na worker z jiného CPU, který tam realtime CPU hog (ten žádný syscall volat nepotřebuje) nepustí na procesor. Skutečný problém je přiřazení realtime priority CPU intensive procesu. Realtime slouží k zajištění nízkých latencí, ne k tomu, aby CPU intensive proces mohl vyždímat procesor do poslední kapičky; od toho jsou úplně jiné nástroje.
coz treba konzole neni, takze neni problem ten RT proces z te konsole zabit.
Jen pokud se k ní lze snadno dostat, což nemusí být vždy pravda. A i když ano, je problémem už to, že je to vůbec potřeba. Nebo taky dřív nějaký watchdog odstřelí celý systém, protože nebude dostupná klíčová služba.
aby jaderna vlakna s omezenou afinitou mela vetsi prioritu nez pouzivane RT procesy … kompilacni volba, ktera umozni nastavit jadernym vlaknum prioritu vetsi, nez je mozne konfigurovat z uzivatelskeho prostoru
To už jsou jen berličky, které umožňují omezit následky, neodstraňují problém. Navíc mnohdy nemusejí být ani žádoucí, protože pak může dojít k opačnému problému - kernel thread nepustí aplikaci na procesor tak rychle, jak by potřebovala.
Tiskni
Sdílej: