Příspěvky

1

Hardware / Re:Záchrana dat z RAM zaseklého běžícího počítače

« kdy: 14. 12. 2023, 13:37:34 »

Pokud operační systém "tvz. zamrzne" neexistuje žádné software řešení jak data z RAM získat.

Existuje a celkem běžně se i používá, příkladem je linuxový kdump. Má to ale dva háčky: za prvé je potřeba ho mít nakonfigurovaný a připravený předem, za druhé nevím, jestli je něco podobného běžně dostupné i pro Windows, které používá tazatel.

2

Hardware / Re:UPS pro malou spotřebu a dlouhý čas

« kdy: 30. 06. 2023, 18:08:03 »

Pokud to má být určeno k zálohování kamer s předpokládaným odběrem 30-40W, nejsou ty navrhované akumulátory s kapacitou 1440Wh nebo dokonce 4800Wh trochu overkill? Pokud to nemá řešit výpadky napájení v řádu desítek hodin, mohla by stačit nějaká LiFePO4 s ~300Wh.

3

Software / Re:Disky s vysokým loadem způsobí „kernel tainted“

« kdy: 02. 06. 2023, 23:19:45 »

1. Taint flags jsou pomocný příznak upozorňující, na něco nestandardního, proto se vypisují u všech varování a paniců, aby. Out of tree modul je možná nejčastější, ale je i spousta dalších, hodně užitečný je i třeba W, který znamená, že už tam nějaký warning byl předtím, takže to, co vidíme v logu, může být až důsledek úplně jiného primárního problému.

2. Pozor, load average je trochu matoucí ukazatel, který automaticky neznamená, že je systém opravdu zatížený. Každý proces, který je ve stavu "D" (uninterruptible sleep), se započítá jako jednička, i kdyby nedělal vůbec nic a jen čekal na nějaký zámek, dokončení operace apod. Pokud je odchytil hung task detector, tak to téměř určitě znamená, že je to přesně tenhle případ. Může to být bug, kdy někdo ten zámek vůbec neuvolnil, když měl, může to být deadlock atd. Pokud se z toho ten systém vůbec nevzpamatuje ani po několika hodinách, tak to pravděpodobně nějaký takový případ bude.

3. Ano, potlačení hung task detektoru má smysl, pokud jde o falešný poplach, pokud je ten stav trvalý, nic to neřeší.

4. Může to být bug, který se vyskytuje jen v konkrétní verzi jádra. To by se někdo musel pořádně podívat na stav systému ve chvíli, kdy k tomu dojde. Ideálním prostředkem k tomu je crash dump, jednodušší (ale méně informačně hodnotnou) alternativou je výpis zásobníků všech tasků pomocí Alt-SysRq-T. V každém případě by bylo dobré, aby se na to podíval někdo, kdo se vyzná v příslušné části jádra, v tomto případě bych tipoval filesystém (spíš ne, pokud se to dá reprodukovat na dvou různých, leda že by to byla přímo obecná vrstva VFS), block layer nebo konkrétní storage.

4

Software / Re:Disky s vysokým loadem způsobí „kernel tainted“

« kdy: 02. 06. 2023, 17:46:48 »

1. "kernel tainted" nezpůsobila ta zátěž, ve vašem případě to znamená jen tolik, že tam máte nějaký out of tree modul, a to dávno předtím, než jste pustil tu zátěž, jak si můžete snadno ověřit čtením /proc/sys/kernel/tainted

2. Co se opravdu stalo při té zátěži, je, že hung task detector vyhodnotil, že nějaká úloha "visí", přesněji, že proces ve stavu "D" (uninterruptible sleep) nedostal po určitou dobu procesor. Za normálních okolností to může skutečně znamenat, že "se něco kouslo", ale při extrémní zátěži to docela dobře může být jen vedlejší efekt celkového přetížení. Takže bych prostě počkal, jestli se z toho systém nakonec zotaví; pokud ne, je to chyba, pokud ano, je to prostě jen dočasný stav, který je důsledkem toho testu. Mimochodem, přímo v tom logu máte návod, jak ten detektor vypnout.

5

/dev/null / Re:Vyssie dane v CR

« kdy: 23. 05. 2023, 08:08:59 »

https://www.kurzy.cz/zpravy/717759-posun-prahu-23-dane-z-prijmu-fyzickych-osob-ze-ctyrnasobku-na-trojnasobek-prumerne-mzdy-vladni/
Ze vraj vsetci v CR co beru nad 120k namiesto nad 160k budu platit dan 23% namiesto 15%? Tak to potes koste.

Ono se to často dezinterpretuje, ta vyšší sazba se samozřejmě vztahuje jen na příjem (u OSVČ zisk) nad příslušnou hranici, ne na celý příjem (zisk). Jinak by se mohlo snadno stát, že vyšší hrubý příjem (zisk) bude znamenat nižší čistý.

6

Software / Re:Škálování výkonu v dual-socket systému

« kdy: 04. 05. 2023, 09:34:33 »

Myslím, že kompilaci kernelu nelze ideálně (lineárně) škálovat.
Jsou tam závislosti, na které se čeká, některé operace se neškálují, atd...

Podle mých zkušeností naopak build jádra škáluje při běžném počtu CPU (nižší desítky) velmi dobře, pokud (1) je konfigurace dostatečně bohatá (třeba allmodconfig nebo distribuční jádra), (2) je dost paměti a (3) úzkým hrdlem je opravdu CPU, ne třeba disk (tj. překlad např. na tmpfs). Je potřeba si uvědomit, že většinu času se překládají jednotlivé soubory, které na sobě nezávisejí; v podstatě jediná část, která škáluje opravdu špatně, je linker (a i to se snad v dohledné době změní).

7

Software / Re:FFmpeg x264 na x265 u kontejneru mp4

« kdy: 13. 02. 2023, 19:24:05 »

Pokud člověk není omezený nějakým hloupým zařízením, které nic jiného neumí, tak je asi lepší se MP4 vyhýbat a používat Matrosku, případně webm.

8

Software / Re:FFmpeg x264 na x265 u kontejneru mp4

« kdy: 08. 02. 2023, 08:24:09 »

Kolega rikal ze to dava smysl, kdyz uz delam ten encoding do x265 ....

Smysl by to mělo, kdyby zdroj byl desetibitový, ale pokud není, tak tím nic (z hlediska kvality) nezískáte, jen bude výsledný soubor o něco větší. Naopak, tím CRF 28 si kvalitu ještě zhoršíte.

a ten "Title" stale chybi v kopii .....

To je divné, defaultně se metadata kopírují, kromě těch, které explicitně změníte. Já naopak potřeboval potlačit kopírování title (pomocí "-metadata title=") u Šťastného pondělí, kde tam dávali nějaké neužitečné interní identifikátory, které se pak zobrazovaly na televizi (přes DLNA) místo názvu souboru.

9

Sítě / Re:Může switch nebo router spojovat fragmenty TCP?

« kdy: 08. 02. 2023, 00:37:30 »

Co se LRO a forwardingu týká, nejlepší je si prostě pamatovat, že to nefunguje. Ono by to technicky při troše štěstí někdy i fungovat mohlo, ale těch případů, kdy se to rozbije, je tolik, že je lepší neriskovat. Ostatně jádro už docela dlouho při zapnutém forwardování automaticky LRO vypíná.

Co se týká jiných protkolů, existuje i jakási verze GSO/GRO pro UDP, ale je to poměrně nová záležitost a má to dost omezení. Dělá se to hlavně kvůli QUICu.

10

Sítě / Re:Může switch nebo router spojovat fragmenty TCP?

« kdy: 07. 02. 2023, 00:54:55 »

1. TSO/GSO se týká odchozích paketů, v podstatě to funguje tak, že skoro celým síťovým stackem projde paket, který je co největší (může to být až skoro 64 KB), a nasegmentuje se až těsně před předáním síťové kartě (GSO) nebo až v ní (TSO). Naopak, GRO/LRO se týká příchozích paketů. LRO dělá přímo síťová karta, ale protože je příliš agresivní v tom, co pospojuje dohromady, nefunguje to dobře s některými protokoly a hlavně to téměř nikdy nefunguje, pokud se ten paket pošle někam dál, takže jádro v mnoha případech automaticky LRO vypíná. Proto vzniklo GRO, které dělá software hned na začátku a které je opatrnější, takže mimo jiné nerozbíjí forwarding (při forwardování se sice pakety virtuálně spojí dohromady, ale dál se forwardují ty původní). Některé nové (a chytřejší) síťové karty podporují i "hardware GRO", kdy jde sice o GRO, ale dělá ho karta.

2. Tak jako tak ale xSO/xRO funguje tak, že po síti běhají krátké pakety a jen uvnitř síťového stacku vidíme ty dlouhé. Protože ale segmentace probíhá až hodně pozdě a sloučení naopak hodně brzy, i libpcap (tcpdump, wireshark, ...) vidí ty dlouhé pakety. Proto je také běžné, že když se díváte na TCP spojení na obou koncích, vidíte na obou stranách dlouhé pakety, ale na každé straně jiné.

3. TSO je naprosto běžný standard i v levných NIC, LRO je taky celkem běžné, ale vzhledem k notorickým problémům s ním bývá defaultně vypnuté. Intel byl jeden z mála, kdo ho měl tradičně defaultně zapnuté, ale nakonec se IIRC nechali přesvědčit, že to opravdu není dobrý nápad. GSO/GRO z podstaty věci nevyžaduje podporu v NIC, takže tam je úplně jedno, od jakého je karta výrobce a jaký je to model.

4. S přerušeními to moc společného nemá. Tvrzení, že co příchozí paket, to přerušení, neplatí už opravdu hodně dlouho (15-20 let). Navíc i kdyby to tak bylo, týkalo by se to stejně jen LRO, kterému je tak jako tak lepší se vyhnout. Skutečný důvod je ten, že většina toho, co se s paketem děje u příchozích i odchozích, pracuje jen s metadaty a hlavičkami, takže je jedno, jak je paket dlouhý; proto je efektivnější pakety, u kterých to jde, zpracovávat dohromady jako jeden velký. U vyšších rychlostí to ani jinak nejde, 10 Gb/s je asi tak hranice toho, co se dá ještě v jednom spojení zvládnout bez GSO/GRO (na dostatečně rychlém procesoru).

11

Software / Re:FFmpeg x264 na x265 u kontejneru mp4

« kdy: 03. 02. 2023, 13:50:56 »

Já na video z ČT používám jednoduše

Kód: [Vybrat]

-c:v libx265 -preset medium -crf 26V konverzi na 10 bitů moc smyslu nevidím a CRF 28 bych nechal jen na nekvalitní pořady (konvertované ze starých analogových záznamů), u nových by to bylo zbytečně degradující a tolik místa to neušetří. Na jazyk titulků lze použít

Kód: [Vybrat]

-metadata:s:a language=cze -metadata:s:s language=czeČT používá identifikátor "ces", ale co jsem vypozoroval, ostatní vesměs používají "cze" a i přehrávače to, zdá se, preferují. Pro angličtinu je to samozřejmě "eng". Pokud by tam byly dvoje titulky, tak za to "metadata:s:s" lze přidat ještě ":0" nebo ":1" pro nastavení jazyka jen konkrétního streamu. Výběr konkrétních streamů např.

Kód: [Vybrat]

-map 0:v -map 0:a -map 0:s:m:language:eng\? -map 0:s:m:language:cze\?Ten otazník je tam proto, aby ffmpeg neskončil chybou, když ve vstupu odpovídající stream není, když si jste jistý, že tam je, můžete ho vynechat. Ale nejsem si jistý, jestli kontejner MP4, který iVysilani používá, vůbec umožňuje víc titulků v jednom souboru.

12

Desktop / Re:Poraďte zajímavé využití RAM disku v Linuxu

« kdy: 20. 01. 2023, 10:30:02 »

Pokud máte dost paměti a nepotřebujete v /tmp nic extrémně velkého, je dobré ho mountovat jako tmpfs, např.:

Kód: [Vybrat]

tmpfs                     /tmp          tmpfs  mode=1777,size=8g          0  0
(Ten parametr size je trochu zavádějící, IMHO by se spíš měl jmenovat limit.) Potom mám ještě jeden větší, který používám na prakticky všechny buildy a všechno ostatní, co je potřeba jen na chvíli. Občas ho používám i tak, že tam zkopíruju celý virtuální stroj, který potřebuju na nějaký jednorázový experiment.

Kromě jiného to má výhodu, že není potřeba řešit úklid, nejpozději při příštím rebootu všechno zmizí. A když ho potřebuju vyčistit dřív, stačí odmountovat a přimountovat, u složitějších adresářových struktur to bývá i rychlejší než "rm -r". (Mám na to skript a příslušnou položku v sudoers.) Jen je potřeba, aby tam žádný proces v tu chvíli neměl otevřený soubor nebo pracovní adresář.

13

Hardware / Re:Výběr klávesnice pro pracovní účely

« kdy: 05. 01. 2023, 13:57:25 »

...uz pred lety narazil na problem zminovany vyse, ze u nas jsou jen same herni co sviti jak vanocni stromek.

Pokud se podsvícení dá vypnout a klávesnice si to pamatuje, aby ho nebylo nutné vypínat pokaždé znovu, tak je mi to celkem jedno. Před pár lety jsem takhle pořídil HyperX Alloy FPS (dělali ji v Blue, Brown i Red verzi, teď už se bohužel nevyrábí), ta sice i při nejnižší úrovni svítí o dost víc, než by bylo ve tmě snesitelné, ale dá se to snadno vypnout (přímo kombinací kláves, bez nějaké utilitky), takže ať si tam ty LEDky klidně jsou, když mne neruší.

14

Hardware / Re:Upgrade z AMD Ryzen 2700x na 5800x alebo 5900x?

« kdy: 03. 01. 2023, 13:48:48 »

Pokud pošlete projekt k vyzkoušení, mohu porovnat různé přístupy.

Posílat nic netřeba, máme open source... pro mne je konkrétně nejzajímavější linuxové jádro. Když jsem to před časem měřil, vycházely rozdíly někde v rozsahu 5-10%. Teď jsem to cvičně zkusil a bylo to méně, ale to byl jen jeden build a navíc z běžícího KDE; na pořádný test teď moc času nemám.

15

Hardware / Re:Upgrade z AMD Ryzen 2700x na 5800x alebo 5900x?

« kdy: 02. 01. 2023, 13:17:25 »

To si holt každý musí rozhodnout sám za sebe. Ale jak už jsem psal, je to poznat i na rychlosti, takže moje volba je jasná.