Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
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: