Příspěvky

886

Hardware / Re:Disk mirroring

« kdy: 10. 09. 2021, 17:31:28 »

2) Když mám dva disky v raidu se zrcadlením, které z raidu odeberu, budou na každém zvlášť data čitelná?

Tohle obecně rozhodně neplatí. Pokud budete mít disky z RAIDu, nějaké disky disky z RAIDu odeberete (tolik, kolik daný RAID umožňuje), bude RAID v degradovaném stavu, ale data z toho RAIDu stále přečtete. Ale nepočítejte s tím, že vytáhnete disk z RAIDu, šoupnete ho do jiného počítače jako obyčejný disk a normálně budou data čitelná.

Stačí si uvědomit, že např. RAID 5 ukládá v třídiskové variantě tak, že na jeden disk uloží blok dat, na druhý disk druhý blok dat a na třetí disk XOR těchto dvou bloků. U dalších disků je to prohozené. Ve vícediskových variantách je to podobné, pokaždé tam někde bude XOR dat. Takže pokud z tohohle RAIDu vytáhnete disk, budete v některých blocích mít XOR dvou bloků dat, a z něj data bez jednoho z těch původních bloků nedostanete.

Tohle je klasicka Jirsakovina ... vlakno se jmenuje mirroring, tazatel se pta na dva disky v zrcadleni, ale tady se musi rozepisovat o R5 a xorovani.

Pokud by pouzival explicitni DM (device mapper) na tvorbu mirroru (metadata mimo disk), pripadne MD (linux sw raid) se superblokem na konci partisny, tak opravdu lze vzit disk a normalneho precist. Je to nestandardni uziti, ale jde to. Ale pak nepocitejte s tim, ze takovy disk lze zapojit zpet do puvodniho raidu, protoze tam muzete mit jine data - napr. zmenene last access time a pod.

887

Hardware / Re:Disk mirroring

« kdy: 10. 09. 2021, 03:27:52 »

nevim co chtel rict RDa tim "biosem, ktery o MD nic nevi", protoze to je vec bootloaderu(a Grub2 umi /boot na raidu,lvm,luks, atd..), kterej v pripade Legacy je v MBR (ktere neni mirrorovane), v pripade UEFI je v EFI oddilu(ktery nemuzes mirrorovat)

Proc bys ho nemohl mirrorovat? To mi chces rict, ze U/EFI boot je single point of failure?

Smyslem mirroru je prece mit dva (ci vic) zcela identickych disku, abych mohl bootovat z kterehokoliv. Pokud ten mirror nevytvari HW raid, coz je nejspis jednodussi pro EFI a cely bootovaci proces, tak je snad zadouci, abys mel na obou discich stejny obsah. A nez drzet dve EFI partisny ve stejnem stavu rucni synchronizaci, tak bych prave na to pouzil legacy metadat format, s MD superblokem na konci partisny.

888

Hardware / Re:Disk mirroring

« kdy: 07. 09. 2021, 20:28:54 »

1) v pripade MD (linux sw raid) je mozne specifikovat stary metadata format, ktery se pouziva pro boot partisny ktere maji byt citelne biosem, ktery o MD nic nevi. Pak potrebujete jen o trocha zmensit partisnu a raid pole vytvorit trikem s disk+missing, a pak pridat druhej disk az pozdeji

Alternativne lze pouzivat DM a raid vytvaret runtime, bez autokonfigurace. Ale to je drbani praveho ucha levou rukou.


2) ano, to je prece smysl toho mirroru. Ale nepocitej s tim, ze to lze bez ztraty dat pridat zpet do mirroru a sesynchronizovat korektne, pokud se nebudes chovat velice specialne k tomu odpojenemu disku (loop/ro a az pak mount)

889

Windows a jiné systémy / Re:Hypervisor / virtuálka na mobilnom zariadení (Android smartphone)

« kdy: 02. 09. 2021, 14:37:39 »

Pokud muzes zmenit HW, tak si vyber telefon kam jde nainstalovat klasicky linux (ony neslavne Ubuntu telefony) a pak si tam uprav to zakladni distro, aby tam bylo KVM nebo XEN A pak doufej, ze android pobezi v takove virtualce.. protoze vyresit gui/drivery bude oser

890

Hardware / Re:SPI blbne při programování

« kdy: 01. 09. 2021, 23:51:48 »

ja to programuji skrze FTDI modul (2232 nebo 4232) + flashrom ... a zda se to ok.
Pokud mas cestu pres prahu, muzem to zkusit.

Ale potkala me takova chyba, ze se pamet nechtela nekdy ani identifikovat - mohl za to plovouci #HOLD pin - takze az pote co jsem #HOLD (a pro jistotu i #WP) pripojil na napajeci vetve se to rozjelo. Asi tam cinsti kopirovaci opomneli interni pullup

891

Studium a uplatnění / Re:Zaměstnání nebo kontrakt?

« kdy: 30. 08. 2021, 23:43:40 »

a je tam taková ta vztahová logika

Pobavilo :-)

Tak slecna na postu "corporate hapiness manager" muze byt inspirativnim elementem v zamestnani :-)

892

Odkladiště / Re:Soukromí v dnešní době

« kdy: 30. 08. 2021, 01:26:27 »

Jedina moznost je zit na styl jasona bourna, odist na druhu stranu planety, platit len hotovostou a nikdy v zivote nenavstivit znovu rovnaky web, nevolat svojej rodine, kamaratom. Proste prestat existovat.

A presto, kdyz budete pak ve spravnou dobu na spravnem miste, i Jason, Ethan a James si muzou dat skolni sraz, nebo panaka :-)

893

Hardware / Re:PC pro CPU výpočty, nejlepší poměr cena/výkon?

« kdy: 29. 08. 2021, 15:16:58 »

Ty vidis svuj problem v potrebe nakupu CPU, ja vidim ze CPU ani nepotrebujes, jestli je ukol JENOM dekodovani. Proto se ptam - co s tim chces jako delat pak ?

Tak předně dodávám že tohle je můj side projekt abych se naučil víc kolem všeho co k tomu využiju.
Prakticky potřebuju ze vstupního videa udělat framy kde je porovnám mezi sebou, na což by mi stačilo je mít v rozlišení 8x8 nebo 16x16 grayscale, což i samotné převedení dost urychluje a nejspíš potvrzuje co píšeš. Pak promažu ty kde se nic nehýbe porovnáním těch zmenšenin, aby z každé takové situace zůstal jen jeden frame. To mi třeba počet 150k framů zmenší na 10-30k, což bude pokaždé jinak. Jenže pak ty zbylé chci zase ve větším rozlišení kde na ně budu aplikovat nějake operace, které už by měly bežet na GPU. Takže je vlastně otázka jestli to tím prohnat 2x, protože někdy to zmenšování na 8x8 jelo i 1500-3000 FPS, ale HD jede tak 500 max at z nich dělám 8x8 nebo 640x360... pak si udělat list jen toho co nechávám a vyzobat to zvlášt ve větším rozlišení. A nebo to vše převést najednou a promazat.

třeba by to šlo nějak chytřeji porovnat abych se vyvaroval zbytečnému zmenšování a převádění všeho když ve finale potřebuju 10-15% originalu.

Konecne se nekam dostavame:

1/
pokud jde o detekci rozdilu z komprimovane streamu (h264/h265) tak bych na to sel analyzou enkodovaneho streamu - protoze tyhle kodeky koduji keyframe + rozdilove snimky, a kdyz zadnej rozdil nebude, bitrate poklesne.

Jako neni to vsespasne - protoze kodek samozrejme povazuje za mezisnimkovy rozdil i sum v obraze. A s nim si tvuj algoritmus bude muset taky poradit, necekal bych ze na statickem obraze bude rozdil pixelu nula

V tomto smeru se nabizi jeste vyuziti hw enkoderu v roli "detektoru pohybu", protoze kodeky delaj presne tohle.


2/
Kdyby to video bylo i-frame only (napr. mjpeg stream), tak lze dekodovat jen DC slozku, tim se dostane 8x mensi obrazek (12.5% v kazde ose), tj. z FHD zbude jen 240x135 px - ale bude to >100x rychlejsi. Pokud je treba vetsi rozliseni, slo by rozbalit i AC a spocitat jen prvni nizkofrekvenci koeficienty. Pro bezne kodeky ale tohle moc nebude fungovat, tam se ocekava kodovani rozdilu vuci obrazu v plnem rozliseni.


3/
v pripade ze to musis dekodovat cely a pocitat rozdily svym zpusobem, abys treba sledoval tendenci, tak je idealni si sestavit tento tok: gpu decode (nvdec) + on-gpu scale + "svuj algoritmus (CUDA)". Zde opravdu nevyuzijes cpu ani trocha, neprijde mi to jako tak slozita uloha, aby to muselo bezet na cpu.



Pokud jede cpu na 100% behem hw/gpu akcelerace, tak je neco spatne (nejspis to dela to skalovani/konverzi formatu, ktere ale maji nekdy svoji GPU variantu, takze bych se zameril timto smerem).

894

Hardware / Re:HPE switch 1920-24G-PoE+, výměna větráčků

« kdy: 29. 08. 2021, 10:29:57 »

Takže když bios je neumí přečíst, tak obráceně HPE switch nebude umět přečíst ty nové koupené.

Asi to nemá řešení?

Samozrejme ze ma - Google je tvuj kamarad:
https://ryanfitton.co.uk/blog/replacing-noisy-stock-fans-on-a-hp-1920-24g-poe-switch-jg925a/

Puvodni (industrial) vetrak ma jednoduchy signal ktery rika ze se vetrak toci (binarne - toci/netoci).
Nove (klasicke) PC vetraky maji signal ktery indikuje pulzama otacky.

Reseni je ignorovat z noveho vetraku vystup (nezapojit), a na strane switche ten treti signal pripojit trvale na zem.
Tim se switchu rika, ze se vetrak toci, a povoli ti POE, zmizi Fault.

Samozrejme timto prichazis o moznost kontroly, zda se vetrak opravdu toci, takze pokud bys to chtel vyresit lepe - tak by reseni bylo udelat nejake jednoduche zapojeni treba na bazi mcu ktere nastnima otacky, a po aplikaci limitu to vytvori spravny signal.

895

Hardware / Re:PC pro CPU výpočty, nejlepší poměr cena/výkon?

« kdy: 29. 08. 2021, 08:23:13 »

Grafika může něco počítat třeba 10x rychleji, kdo tohle neví? Jenže v mem případě na tom nezáleží já chci z videí data v RGB, což můžeš vědět z mého předchozího threadu ohledne ffmpeg kde jsi se taky vyskytoval. Co mám optimalizovat? Stahnout zdrojaky FFmpeg a optimalizovat je? Zatím jsem řešil jak vubec nejrychleji ty data dekodovat aby z toho bylo datové pole snímků.. i s HW akcelerací se tam GPU moc neangažuje, protože samotné dekodování problem není ale spíš jak to dostat dál. Ono GPU není všespásný a posílat tam malý operace a vracet je zpátky taky není optimální...

Ad tento zacatek processingu: v HW akceleraci se angazuje jedine hw dekoder, ktery je soucasti GPU. Napr. ruzne graficke karty od nvidie maji ruzny pocet NVDEC jednotek: https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
Proto vytizeni CPU a GPU je v idealnim pripade 0%, pro ukol "dekoduj video".

Pokud data stahujes do RAM, tak pocitej na 1080p30 v YUV2 ze je 125MB/s - cca 1Gb/s pro kazdej stream. Typicka karta rady 1060/70/80 na jeden dekoder dava 650 fps ~ temer 26 videi v 1080p25, celkovy vystup bude kolem 22 Gb/s (2750 MB/s).

Po prevedeni na RGB je objem dat dvojnasobnej - 44 Gb/s (5500 MB/s) a to se GPU ani CPU jeste nezapojilo.

A ted se ptam - co s timto obrim tokem dat chces delat? Dekodovani videa neni "zpracovani". Pokud to chces jen takto v RGB ulozit na SSD, tak zadne CPU nepotrebujes, ale spis hodne rychle diskove pole.

Pouzitim vicero karet se vykon skaluje. Nebo volbou profi grafik lze ziskat vicero dekoderu - treba 2,3 ci 5 na kartu. Jestli das do kompu dve takove A100 grafiky a budes mit 10 NVDEC jednotek - byl bys schopen tocit tim 440 Gbit/s RGB dat (55GB/s) - coz saturuje dvakrat PCIe Gen4x16 - a na to potrebujes uz 2nd/3rd gen EPIC-a, jen abys mohl sva podelana RGB data stahnout do RAMky.

Ty vidis svuj problem v potrebe nakupu CPU, ja vidim ze CPU ani nepotrebujes, jestli je ukol JENOM dekodovani. Proto se ptam - co s tim chces jako delat pak ?

896

Hardware / Re:PC pro CPU výpočty, nejlepší poměr cena/výkon?

« kdy: 28. 08. 2021, 23:44:49 »

Pokud ti jde o "všeobecný výkon" definovaný třeba tak, že pustíš nějakou kompilaci atd..., tak určitě nějaký Ryzen, pokud potřebuješ AVX-512, tak zatím na výběr moc nemáš

Já ani nevim kde se AVX-512 využívá, zřejmě to nepotřebuju, to co dělám jede na všem. Momentálně na tom chci zpracovávat terabajty videí a následne v z toho něco počítat a když něco pujde offloadovat na grafiky tak to udělám, ale taky by to měl byt univerzální stroj když budu třeba dělat něco jiného.

Takze uzivatel co ma pitome dotazy je zpet. Nic nevi ale chce to

Rozdil mezi CPU a GPU akceleraci v podobnych video ulohach (ackoliv nevime co vlastne delas) je cca 1:10 (memory bound problem), takze sis neudelal poradnou pripravu a nakupujes zbytecna CPU, namisto optimalizace aplikace.

897

Hardware / Re:PC pro CPU výpočty, nejlepší poměr cena/výkon?

« kdy: 28. 08. 2021, 20:22:28 »

Vykon v cem?
Protoze porovnavat benchmark zamereny na 3D nebo DSP co zere AVX512 je nesmysl napr. pri pozadavku na rychlou kompilaci v gcc :-)

898

Software / Re:Převod MP4 na JPG sekvence (nebo datové pole) co nejrychleji

« kdy: 28. 08. 2021, 12:29:39 »

Ty laciné redukce...přemýšlím, jestli to bude mít rozumné API...

Co použít něco jako tohle? (Pokud bych se dostal za fázi hrubého prototypu...)
https://www.avermedia.com/professional/product/ce314_hn/spec

Avermedia často mají solidní API......ve srovnání s nejčínovatější Čínou...

PCIe karty budou mit bud nejake custom SDK (blackmagic, deltacast) a pripadne adaptacni vrstvu na klasicke WDM video pro Win.
Ty levne karty budou mit jenom WDM. S V4L2 to je relativne marny v komercnich consumer produktech.

U USB budes mit na 90% nativni UVC video, tj. bezdriverove reseni, nektere slozitejsi vyrobky pak maji vlastni drivery a api (blackmagic ultrastudio usb3 / intensity shuttle).

899

Software / Re:Převod MP4 na JPG sekvence (nebo datové pole) co nejrychleji

« kdy: 28. 08. 2021, 12:24:25 »

Porid si HDMI-USB3 prevodnik, ty na FHD nejsou drahe.

Taky jsem mu to chtěl navrhnout, ale myslel jsem, že ty levné posílají MJPEG a možná snižujou framerate.

Ano - ty ultra lacine jsou takove, ale muze za to USB2, protoze 10080p30 @ 422/8bit je 124 MB/s a to se musi nejak redukovat. Pro USB3 model by tohle melo projit bez komprese. Take neni treba hledat "4K podporu", spis aby to bylo hlavne USB3.

900

Software / Re:Převod MP4 na JPG sekvence (nebo datové pole) co nejrychleji

« kdy: 28. 08. 2021, 02:08:16 »

Bohužel, dostat nekomprimovaný stream přes USB do pecka...třeba ve FHD...za rozumné peníze (řekněme do 1500 Kč) ...to je výzva.

Porid si HDMI-USB3 prevodnik, ty na FHD nejsou drahe. A FHD kameru s HDMI ti zastoupi jakykoliv suplikovej/bazarovej handycam nebo fotacek. Pokud jde o nizkou cenu, tak to bude nejaky bastl, ale pocitej, ze na tom prodelas pokud by sis mel zapocist svuj promarneny cas.

Pokud vyzadujes nezasumeny obraz, tak to chce svitit, svitit, svitit. Nebo pouzit velikej a drahej snimac, v jeste drazsi kamere.