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í.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
aby se kešovaly i sekvenční operace a "read_promote_adjustment" nastavit na něco malého, aby se ti kešovalo skoro všechno, co budeš číst, ale jestli to bude mít nějaký výkonnostní bonus, to těžko říciJá měl za to, že metadata-device udržuje seznam bloků uložených v cache-device, tj. jak těch načtených při čtení tak těch určených k zápisu na origin-device(dirty blocks). Proč by se muselo znova cachovat čtením z origin-device, když úspěšně propsaný dirty block obsahuje shodná data (jako origin-device).
Navíc na to SSD pak budeš i ve velkým zapisovat i jen při samotném čtení, což nebude asi také moc ok.Pokud se budou číst stejná data (scrubbing po timeline), mělo by to na základě existence daných bloků v metadata-device snad pouze přečíst odpovídající bloky z cache-device?
ale jestli to bude mít nějaký výkonnostní bonus, to těžko říciPokud diskové operace v rámci aktivního projektu probíhají na 1TB+ dat z obsahu filesystému mělo by cache-device 2TB být schopno obsahovat prakticky vše k čemu se přistupuje? Prakticky "FIFO", pokud by vše mělo stejnou váhu.
Nemůžeš si udělat workflow dat v rámci userspace?Ano to mám jako náhradní řešení. Aktivní data leží v /NVMe/xyz a je na ně vytvořen symbolický link z /mount_raid5/xyz, který se využívá v rámci projektu (kromě toho leží stejná data ještě v /mount_raid5/xyz.hdd jako redundance). Po ukončení zpracování se link zrusi a přejmenuje xyz.hdd na xyz, cimz je v budoucnu zajisteno zachovani schodne cesty jako te pouzite v rámci referenci na klipy v projektu. Bude to chtit praktický pokus.
read_promote_adjustment: READ io, default 4 write_promote_adjustment: WRITE io, default 8 discard_promote_adjustment: READ/WRITE io to a discarded block, default 1Takže nezajistíš, aby se zapisovaný soubor udržel v cache hned automaticky pro čtení. Aspoň tak mi to dle dokumentace vychází. Každopádně asi si zkusím ve volné chvíli udělat nějaký test, docela mě to zajímá, jak se to reálně umí chovat.
metadata/cache-device dev/nvme0n1: Timing buffered disk reads: 9414 MB in 3.00 seconds = 3137.43 MB/sec origin-device /dev/sdf: Timing buffered disk reads: 1526 MB in 3.00 seconds = 508.19 MB/sec
Zápis prakticky rychlostí SSD (WD500 Blue) time dd if=/dev/zero of=/raid5/bigshit2 bs=1M count=32768 32768+0 records in 32768+0 records out 34359738368 bytes (34 GB, 32 GiB) copied, 117,671 s, 292 MB/s real 1m57,677s user 0m0,020s sys 0m23,641s Prvni cteni (cache na NVMe se dle iostat plni) time cat /raid5/bigshit2 >/dev/null real 2m8,042s user 0m0,110s sys 0m12,518s prvni cteni nacachovanych dat 32GB file time cat /raid5/bigshit2 >/dev/null real 0m33,120s user 0m0,050s sys 0m9,654s druhe cteni nacachovanych dat 32GB file time cat /raid5/bigshit2 >/dev/null real 0m14,718s user 0m0,037s sys 0m6,437s (base) root@xub184:~# time cat /raid5/bigshit2 >/dev/null real 0m28,535s user 0m0,046s sys 0m8,966s (base) root@xub184:~# time cat /raid5/bigshit2 >/dev/null real 0m14,718s user 0m0,037s sys 0m6,437s (base) root@xub184:~# time cat /raid5/bigshit2 >/dev/null real 0m11,885s user 0m0,029s sys 0m6,244s (base) root@xub184:~# time cat /raid5/bigshit2 >/dev/null real 0m13,743s user 0m0,045s sys 0m6,997sdle iostat cteni z NVMe(cache device) spickove presahuje 2GB/s Pozn. RAM je 32GB, takze by se tam 32GB soubor nemel soubor vejit (zkusim radeji soubor 96GB).
zapis na origin storage (limit SATA SSD) time dd if=/dev/zero of=/raid5/bigshit3 bs=1M count=98304 98304+0 records in 98304+0 records out 103079215104 bytes (103 GB, 96 GiB) copied, 375,234 s, 275 MB/s real 6m15,255s user 0m0,041s sys 1m13,642s prvni cteni (plneni cache) time cat /raid5/bigshit3 >/dev/null real 6m14,875s user 0m0,310s sys 0m35,797s prvni cteni s vyuzitim cache prumerne >1,5GB/s time cat /raid5/bigshit3 >/dev/null real 0m58,806s user 0m0,113s sys 0m27,762s druhe cteni s vyuzitim cache time cat /raid5/bigshit3 >/dev/null real 0m51,978s user 0m0,107s sys 0m26,724sVypada to, ze dochazi k aktualizaci metadat (zapisy na NVMe pri cteni), asi pro statistiky cetnosti vyuzivani dat (idealni by bylo kdyby toto slo vypnout, donutit to aby to nedavalo prednost zadnym datum). Potvrdilo se, ze zapsane informace se nepouziji pro read-cache. Znamenalo by to v ramci naplneni cache je po nakopirovani jednorazove vycist do /dev/null. Pokud se to ovsem nebude chovat jako ciste FIFO (proc jinak ty zapisy pri cteni), neni garance ze se s novym projektem nova data dostanou do cache (statistiky vyuzivani dosavadnich dat by mohly prevazit?). V pripade takoveho chovani by se cache by se asi nejspis musela znovu reincializovat, aby se umoznilo naplneni novym obsahem. Pri praci s timeline nemusi byt cten cely soubor (scrubbing jde po datově vzajemne vzdalenych snimcich). Bez prednaplneni cache by se stridaly rychle dostupne (jiz nacachovane snimky) a ty pomale (ktere jeste nebyly nacteny/obsazeny v cache). Vypada to, ze to funguje, ale pro dany ucel mam obavu ze to bude z hlediska cache-hit ratio asi nevypocitatelne. Dana uloha je asi prilis vzdalena cilum tohoto reseni.
. Ostatně to by pak i vysvětlovalo, proč další čtení (v příkladu třetí) jsou o kapánek rychlejší, než to první z cache (v příkladu to druhé čtení).
sudo hdparm -t /dev/nvme1n1 /dev/nvme1n1: Timing buffered disk reads: 4008 MB in 3.00 seconds = 1335.94 MB/secVýdrž má být 182,5TBW, což při velikosti 32GB znamená cca 5840 úplných přepisů. Velikost struktur metadata-device se údajně stanovuje výpočtem 4M + (16 * velikost_cache_device / velikost bloku), což by při 1TB cache-device a 256KB bloku představovalo asi 65MB (0,2% kapacity Optane). Zařízení disponuje dvěma PCIe 3.0 linkami, což ukazuje i lspci.
41:00.0 Non-Volatile memory controller: Intel Corporation Device 2522 (prog-if 02 [NVM Express]) Subsystem: Intel Corporation Device 3806 ... LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM not supported, Exit Latency L0s unlimited, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- ... Kernel driver in use: nvme
time dd if=/dev/zero of=/raid5/bigshit3 bs=1M count=98304 98304+0 records in 98304+0 records out 103079215104 bytes (103 GB, 96 GiB) copied, 377,044 s, 273 MB/s real 6m17,111s user 0m0,046s sys 1m12,945sPrvní čtení souboru z origin-device a plnění cache-device
time cat /raid5/bigshit3 >/dev/null real 6m8,772s user 0m0,280s sys 0m36,910sDruhé čtení souboru z origin-device (vypada to, že při prvním čtení se nenacacheovala všechna data, čte se i z origin) .. průměrná rychlost 96GB/83s cca 1GB/s+
time cat /raid5/bigshit3 >/dev/null real 1m23,199s user 0m0,123s sys 0m29,300sTřetí čtení souboru z origin device
time cat /raid5/bigshit3 >/dev/null real 1m18,568s user 0m0,140s sys 0m30,340sČtvrté čtení (podíl nacachovaných dat se zvětšuje)
time cat /raid5/bigshit3 >/dev/null real 1m6,874s user 0m0,148s sys 0m30,356sPáté čtení
time cat /raid5/bigshit3 >/dev/null real 0m53,109s user 0m0,114s sys 0m30,113sŠesté čtení
time cat /raid5/bigshit3 >/dev/null real 0m46,084s user 0m0,120s sys 0m29,251sSedmé čtení
time cat /raid5/bigshit3 >/dev/null real 0m42,074s user 0m0,124s sys 0m29,348sSedmé čtení
time cat /raid5/bigshit3 >/dev/null real 0m40,288s user 0m0,104s sys 0m29,255sOsmé čtení (z originu se čtou v průměru pouze jednotky MB/s)
time cat /raid5/bigshit3 >/dev/null real 0m38,916s user 0m0,123s sys 0m29,540sDeváté čtení (z originu se během celého čtení 96GB načetlo odhadem asi 10MB) .. 96GB/40s = 2,4GB/s
time cat /raid5/bigshit3 >/dev/null real 0m38,644s user 0m0,130s sys 0m29,469sAlgoritmus pro cachování má svou hlavu.
Perlička na závěr, mountpoint /raid5 nebyl nejšťastnějším. Právě mi do něj vlezl TimeShift a pokouší se bigshit3 zálohovat. 
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
4.4.2021 15:17
