Byla vydána Java 26 / JDK 26. Nových vlastností (JEP - JDK Enhancement Proposal) je 10. Odstraněno bylo Applet API.
Byla vydána nová verze 260 správce systému a služeb systemd (Wikipedie, GitHub). Odstraněna byla podpora skriptů System V. Aktualizovány byly závislosti. Minimální verze Linuxu z 5.4 na 5.10, OpenSSL z 1.1.0 na 3.0.0, Pythonu z 3.7.0 na 3.9.0…
Byla vydána nová verze 5.1 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v poznámkách k vydání. Videopředstavení na YouTube.
Bylo oznámeno vydání nové verze 8.1 "Hoare" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Doprovodný příspěvek na blogu Khronosu rozebírá kódování a dekódování videa pomocí Vulkan Compute Shaders v FFmpeg.
Byl představen open-source a open-hardware prototyp nízkonákladového raketometu kategorie MANPADS, který byl sestaven z běžně dostupné elektroniky a komponent vytištěných na 3D tiskárně. Raketa využívá skládací stabilizační křidélka a canardovou stabilizaci aktivně řízenou palubním letovým počítačem ESP32, vybaveným inerciální měřicí jednotkou MPU6050 (gyroskop a akcelerometr). Přenosné odpalovací zařízení obsahuje GPS,
… více »Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.
SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
Aktuální vývojové jádro je 3.19-rc1, vydané dne 20. prosince – o jeden den dříve, než se dalo očekávat.
Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace.
Wired hovořil s Linusem Torvaldsem o možnostech další chyby spojené s přestupnou sekundou.
Vy všichni ostatní opravdu berte tu přestupnou sekundu jako záminku k uspořádání malého absurdního večírku pro své nejbližší přátele. Nasaďte si srandovní klobouky, nechte si natisknout transparent se slovy „Večírek soudné přestupné sekundy“ a pořádně se opijte. Jednou mrknete a bude po všem, ale aspoň budete mít další den kocovinu, která vám připomene tu slavnou, ale prchavou sekundu navíc.
Přicházejí 100Gb síťové adaptéry, konstatoval Jesper Brouer ve své přednášce na minikonferenci jádra LCA 2015 (snímky [PDF]). Řízení těchto adaptérů v jejich plné podporované rychlosti bude pro linuxové jádro významnou výzvou; řešení tohoto problému je náplní jeho současné i budoucí práce. Dobrou zprávou je, že linuxové síťování se díky tomu trochu zrychlilo – i když je stále nutné vyřešit některé problémy.
Jak síťové adaptéry zrychlují, doba mezi pakety (tj. čas, ve kterém musí jádro zpracovat každý paket) se zkracuje. U současných 10Gb adaptérů je to 1 230 ns mezi dvěma 1538bajtovými pakety. Přenosová rychlost 40 Gb/s tuto dobu výrazně snižuje na 307 ns. 100 Gb/s tento problém přirozeně zhoršuje, protože zkracuje čas na paket na zhruba 120 ns; v tomto případě rozhraní zpracovává 8,15 milionů paketů za sekundu. To nenechává příliš času na to, aby systém zjistil, co se kterým paketem provést.
Co ale máte dělat, pokud – jako většina z nás – nemáte na hraní 100Gb adaptér? Místo něj použijete 10Gb adaptér s malými rámci. Nejmenší ethernetový rámec, který lze odeslat, je 84 bajtů; podle Jespera je u 10Gb adaptéru mezi pakety nejmenší velikosti prodleva 67,2 ns. Systém, který se s takovou zátěží dokáže vyrovnat, by měl být schopen rozumně zvládat 100Gb sítě, až budou k dispozici. Ale vyrovnat se s takovou zatížení je těžké: na 3GHz procesoru máte pro zpracování každého paketu k dispozici pouze asi 200 cyklů procesoru. To, jak poznamenal Jesper, není mnoho.
Jádro se tradičně s tímto druhem síťových intenzivních zatížení nevyrovnává nejlépe. To vedlo ke vzniku řady síťových implementací mimo hlavní strom, které zásobník síťové vrstvy jádra zcela obcházely. Poptávka po takových systémech naznačuje, že jádro nepoužívá hardware optimálně; implementace mimo hlavní strom může řídit adaptéry plnou dostupnou rychlostí z jediného procesoru, což jádro hlavní větve příliš nezvládá.
Problém je podle Jespera v tom, že vývojáři jádra se zaměřovali na škálování na velký počet jader. Během toho se jim dařilo skrývat regrese efektivity na jedno jádro. Zásobník síťové vrstvy v důsledku toho funguje dobře pro více zátěží, ale utrpěly pracovní zátěže, které jsou obzvláště citlivé na čekací doby. Jádro dnes dokáže předávat pouze něco mezi 1 M a 2 M pakety na jádro za sekundu, zatímco některé z nezávislých alternativ se blíží k rychlosti 15 M paketů na jádro za sekundu.
Pokud budete chtít tento druh problému řešit, musíte si důkladně posvítit na režii na každý krok ve zpracování paketu. Tak například řešení neúspěšného přístupu do mezipaměti na Jesperově 3GHz procesoru trvá asi 32 ns. Stačí tedy dva neúspěšné přístupy k vyčerpání celého času vyhrazeného zpracování paketu. Vzhledem k tomu, že vyrovnávací paměť soketů („SKB“) zabírá na 64bitovém systému čtyři řádky mezipaměti a že velká část SKB je zapsána během zpracování paketů, je první část problému jasná – čtyři neúspěšné přístupy do mezipaměti by spotřebovaly mnohem víc času, než je k dispozici.
Mimo to, použití prefixu x86 LOCK pro atomické operace trvá asi 8,25 ns. V praxi to znamená, že nejkratší cyklus uzamčení/odemčení trvá něco přes 16 ns. V takovém časovém limitu tedy není dost místa pro hodně zamykání.
K tomu se přičítá doba potřebná na provedení systémového volání. V systému s aktivní ochranou SELinux a auditováním to zabere lehce přes 75 ns – tedy celou vymezenou dobu. Deaktivace auditování a SELinuxu zkracuje potřebný čas těsně pod 42 ns, což je lepší, ale i tak je to značná část celkového času. Existují způsoby, jak tuto režii vyrovnat v rámci několika paketů; mezi ně patří systémová volání jako sendmmsg(),recvmmsg(),sendfile() nebo splice(). V praxi to ovšem podle něj nefunguje tak dobře, nezjistil ale prý důvod. Christoph Lameter z publika poznamenal, že uživatelé závislí na čekací době mají tendenci používat mechanismus InfiniBand „IB verbs“.
Jesper se potom zeptal, jak je možné, že řešení obcházející jádro dosahují lepších výsledků. Zdá se, že klíčem je dávkové zpracování operací, předběžná alokace a předběžné načítání zdrojů. Tato řešení pracují v režimu CPU-local a předcházejí tak zamykání. Také je důležité zmenšit metadata paketů a snížit počet systémových volání. Pomůžou také rychlejší datové struktury optimalizované pro vyrovnávací paměť. Ze všech těchto technik je nejdůležitější dávkové zpracování operací. Režii, která je nepřijatelná na úrovni paketů, lze lépe zvládnout, pokud se projevuje jednou za desítky paketů. 16ns zamykání na paket je příliš; pokud se současně zpracuje 16 paketů, toto zatížení klesne na 1 ns na paket.
Proto není divu, že Jesperova práce se zaměřuje na zlepšení dávkového zpracování v síťové vrstvě. To zahrnuje práci na hromadném přenosu TCP, o které jsme zde informovali v říjnu; podrobnosti o tom, jak všechno funguje, najdete v tomto článku. Stručně řečeno, jedná se o mechanismus pro informování síťových ovladačů o tom, že existují další pakety čekající na přenos; to umožní ovladači odložit nákladné operace, dokud nejsou všechny tyto pakety zařazeny do fronty. V případě nasazení tohoto mechanismu dokáže jeho systém přenášet 14,8 M paketů za sekundu – tedy, pokud se stále dokola posílá stále jeden malý paket.
Nejsložitější podle něj je přidání dávkově pracujících API do zásobníku síťové vrstvy bez zvýšení latence systému. Latence a propustnost si velmi často konkurují; tady je cílem optimalizace obou. Obzvlášť těžké je odolat spekulacím se zpožděním přenosu – vsadit na to, že se brzy objeví další paket. Takové triky často zlepší výsledky benchmarků, ale jsou méně vhodné pro skutečné zatížení.
Dávkové zpracování může – a mělo by – probíhat v několika vrstvách zásobníku. Vhodným místem pro dávkové zpracování je například systém disciplín ukládání do fronty („qdisc“); při řazení do fronty už tak jako tak dochází ke zpoždění. V nejlepším případě vyžaduje kód qdisc v současnosti šest operací LOCK na paket – 48 ns čisté režie uzamykání. Celková režie na řazení paketů do front je 58–68 ns, většinu času tedy spotřebují operace zamykání. Jesperova práce spočívala v přidání dávkového zpracování, aby se režie rozložila na několik paketů; to ale funguje jen v případě, že taková fronta paketů existuje.
Nominální rychlý průchod kódem qdisc nastává, když neexistuje žádná fronta; v takových situacích mohou být pakety často předány přímo do síťového rozhraní bez řazení do fronty. V současnosti takové pakety provází režie všech šesti operací LOCK. Podle něj by to mělo jít lépe. Subsystém qdisc bez zámků by mohl odstranit téměř veškerou režii na řazení paketů do fronty. Jesper má testovací implementaci, na které předvádí, čeho lze dosáhnout; eliminace minimálně 48ns režie za to podle něj stojí.
Zatímco výkon odesílání podle něj nyní vypadá poměrně dobře, zpracování příjmu by se stále mohlo ještě trochu zlepšit. Vysoce vyladěná konfigurace může dosáhnout rychlosti maximálně asi 6,5 M paketů za sekundu – a v takových případech se pakety jednoduše zahazují po příjmu. Probíhají určité práce na optimalizaci průběhu příjmu, které toto maximum zvýší na něco přes 9 M paketů za sekundu. Problém je ale v benchmarku: ten neukazuje režii na interakce se subsystémem správy paměti.
A ukazuje se, že tato interakce je velmi slabá. Přenosová cesta zásobníku síťové vrstvy má podle všeho některé vzorce chování, které nevedou k nejlepšímu způsobu práce alokátorů tabulek. Přijímací kód může přidělit prostor až pro 64 paketů současně, zatímco přenosová cesta může uvolňovat dávky až po 256 paketech. Tento vzorec podle všeho poměrně zpomaluje především alokátor SLUB. Jesper provedl nějaké mikrobenchmarky a zjistil, že jedno volání kmem_cache_alloc() následované voláním kmam_cache_free() vyžaduje asi 19 ns. Pokud se ale provádělo 256 přidělení a uvolnění, tato doba narostla na 40 ns. V zásobníku síťové vrstvy v reálném prostředí, kde současně probíhají další procesy, může ale režie přidělování a uvolňování narůst ještě více, na 77 ns – více než celý vyhrazený časový rámec.
Proto Jesper dospěl k závěru, že je nutné kód správy paměti vylepšit nebo nějakým způsobem zcela obejít. V rámci testů druhé z variant implementoval subsystém nazvaný qmempool; ten provádí hromadné operace přidělování a uvolňování bez zamykání. Díky qmempool byl schopen ušetřit 12 ns v jednoduchých testech a až 40 ns v testech předávání paketů. Existuje celá řada způsobů zrychlení používaných v qmempool, navrch má ale dávkové zpracování operací.
Jesper skončil tím, že uvedl, že qmempool implementoval jako jakousi provokaci: chtěl ukázat, co je možné, a přimět vývojáře správy paměti, aby s tím něco udělali. Odpověď z tábora správy paměti následovala v další přednášce, která bude zveřejněna samostatně.
[Editor by chtěl poděkovat linux.conf.au za financování jeho cesty na tuto akci.]
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
25.3.2015 11:11
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
26.3.2015 09:33
Conscript89
| Brno
26.3.2015 03:20
Jendа | skóre: 78
| blog: Jenda
| JO70FB
ale utrpěly pracovní zátěže, které jsou obzvláště citlivé na čekací dobyTo je workload? Přeložil bych to jako typy zátěží.
27.3.2015 10:09
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
LOCK (instrukčním) prefixem, což je hardwarová záležitost.
27.3.2015 13:40
Jendа | skóre: 78
| blog: Jenda
| JO70FB
. BTW to se už skoro dá implementovat raw video-out over ethernet ne?
30.3.2015 21:45
Petr Tomášek | skóre: 39
| blog: Vejšplechty