Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
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: