Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: RDa 28. 12. 2014, 15:10:56
-
Zdravim takto o svatcich - shanim vadne SSD disky se zamerem navrhnout vlastni disk s dokumentovanym FTL, tj. s moznosti obnovy dat pri selhani nekterych bunek. A take lidi kteri by meli zajem se podilet na sw realizaci (ftl, ecc). Vim ze existuje openssd-project, ale ten hw neni dostupny pro bezne lidi.
Primarni cil je rychle uloziste pro nasi 4K kameru s nekomprimovanym zaznamem (hodne sekvencnich dat) a pak z toho udelat obecne uloziste treba s PCIe nebo SATA rozhranim. Kdo jde do toho a kdo nas podpori?
Viz: http://diit.cz/clanek/ssd-even-deeper-hell-pitva - pameti i z mrtveho SSD jdou cist, ale nikdo vam dokumentaci k rozlozeni dat neposkytne
-
no prave,nejake mrtvoly nekde lezi,ale od zakosu, buhvi, co tam je za data, do sveta nesmi.
jak vidim FTL vybavi se mi faster-than-light ale to bude asi z jine pohadky :)
nekomprimovane 4k je dobre zverstvo - k cemu to ma byt dobre ? na kompresi jsou cipy na h.264 a dekompresi i h.265, na kompu muzete pouzit nvidia/cuda,hral jsem si s tim pred x lety, tak proc plytvat mistem ?
-
Data z cipu na SSD tezko obnovis.. to je duvod proc chci udelat vlastni (jen USB klicenky ukladaji plaintext).
Tak nekomprimovane 4K je kvalitativne o nekolik levelu vyse... je tam videt vse - treba i prirozeny sum senzoru (kdy odstin pak osciluje mezi ruznymi hodnotami). Duvod proc jit do nekomprimovaneho zaznamu je prosty - uloziste se skaluje omnoho lepe nez kompresni jadra. Muzeme generovat cca 2-3 GB/s a pro ulozeni postaci "par disku v raidu", ale jestli to chces prohnat kompresi (4K/240fps) tak na to reseni neexistuje, nemluvne o spotrebe kolem 100W pro asic reseni. A vysledek by za to nestal - zdrojova data jsou 12bit, to zadna h264/h265 komprese nezvladne.
-
Pokud jsi pisatel tohoto článku: http://diit.cz/clanek/ssd-even-deeper-hell-pitva/detektivni-prace-zpetneho-inzenyra
Pak nerozumíš rozdílu mezi KOMPRESÍ A ŠIFROVÁNÍM.
Hodinky nebo holínky, obojí se natahuje viď.
Data z SSD samozřejmě obnovit lze, několik firem i tady v ČR přišlo na postup, jak jsou data komprimována.
http://www.zachrana-dat-ssd.cz/
•Vybavili jsme laboratoř novým zařízení pro pájení BGA čipů
Chtěl bych je vidět, jak by rozlouskli data šifrovaná i starým blbým AES 128 ;D
Tím nechci tvrdit, že neexistují SSD, která data šifrují, dokonce náhodou tvoje Intel 320 SSD data šifruje - jako jedna z hodně mála!
Pokud nemáš nastavený ATA lock, pak jsou klíče k rozšifrování disku v "plaintextu" na začátku disku.
Pokud MÁŠ nastavený ATA lock, pak jsou klíče k rozšifrování disku zašifrována tímto heslem.
Zatímco ATA lock je uložený přímo v řadiči a jen tak se k němu nedostaneš, tak (nařízení NSA) klíč k rozšifrování disku je uložený právě na začátku.
Důvod, proč je to takhle, je docela prostý.
Při změně ATA locku není nutné "přešifrovat" celý disk změněným heslem, ale jen ten jeden samotný klíč.
A kdybys o tom něco věděl, tak si AES heslo stáhneš a data si poměrně hodně jednoduše rozšifruješ.
Dokud nepochopíš rozdíl mezi šifrováním a komprimováním dat, nemá smysl s tebou o tom diskutovat.
-
Dokud nepochopíš rozdíl mezi šifrováním a komprimováním dat, nemá smysl s tebou o tom diskutovat.
Na to ze vubec nevis, s kym mluvis (jestli je to tentyz clovek), tak jsi se ale pekne rozhonil :)))
-
Data z cipu na SSD tezko obnovis.. to je duvod proc chci udelat vlastni (jen USB klicenky ukladaji plaintext).
Tak nekomprimovane 4K je kvalitativne o nekolik levelu vyse... je tam videt vse - treba i prirozeny sum senzoru (kdy odstin pak osciluje mezi ruznymi hodnotami). Duvod proc jit do nekomprimovaneho zaznamu je prosty - uloziste se skaluje omnoho lepe nez kompresni jadra. Muzeme generovat cca 2-3 GB/s a pro ulozeni postaci "par disku v raidu", ale jestli to chces prohnat kompresi (4K/240fps) tak na to reseni neexistuje, nemluvne o spotrebe kolem 100W pro asic reseni. A vysledek by za to nestal - zdrojova data jsou 12bit, to zadna h264/h265 komprese nezvladne.
nekomprimovane!=RAW... jenom pro jistotu, protoze nekomprimovane 4K a lossless komprimovane 4K je to same z pohledu kvality, z pohledu mista je to samozrejme o necem jinem. Reseni pro ukladani RAW 4K videa je nekolik, cenove se ale bavime o nekolik desitkach tisic EUR... Jinak nic ve zlym, ale proc si myslis, ze 1 clovek udela reseni lepsi/levnejsi nez treba 50 lidi u Sony pracujicich full time? Doporucuji se podivat po internetu, nekolik projektu existuje, ale ukladat RAW nekomprimovane je momentalne porad cenove nedostupne i pro profesionalni produkce.
-
2:
Oba máte pravdu.
Mimo to, nekomprimované, jsou komprese ztrátové a bezeztrátové, na bezeztrátové nevidím nic špatného.
Hodinky nebo holínky, obojí se natahuje viď.[/b][/u]
Tak nějak.
1 snímek v RAW / TIFF má tak 20-30MB.
Na 1 vteřinu jich potřebuješ 25, tedy 25 snímků po 20 MB = 500MB na sekundu záznamu.
Tady je nějaká kalkulačka: http://web.forret.com/tools/video_fps.asp?width=4096&height=2160&fps=24&interlace=on&depth=12&title=Digital+Cinema+4K
IMHO: Kdyby RDa něco tušil o flash pamětech, tak by věděl, že zápis je řádově pomalejší než čtení, takže tam těch čipů bude potřeba vážně hodně a bude to mít dost malou kapacitu.
Ukládat 250-400MB za sekundu zvládne pole, které poskládám z dílů z Aukra bratru za dva litry a bude mít kapacitu řádově v jednotkách TB.
-
2:
Oba máte pravdu.
Mimo to, nekomprimované, jsou komprese ztrátové a bezeztrátové, na bezeztrátové nevidím nic špatného.
Hodinky nebo holínky, obojí se natahuje viď.[/b][/u]
Tak nějak.
1 snímek v RAW / TIFF má tak 20-30MB.
Na 1 vteřinu jich potřebuješ 25, tedy 25 snímků po 20 MB = 500MB na sekundu záznamu.
Tady je nějaká kalkulačka: http://web.forret.com/tools/video_fps.asp?width=4096&height=2160&fps=24&interlace=on&depth=12&title=Digital+Cinema+4K
IMHO: Kdyby RDa něco tušil o flash pamětech, tak by věděl, že zápis je řádově pomalejší než čtení, takže tam těch čipů bude potřeba vážně hodně a bude to mít dost malou kapacitu.
Ukládat 250-400MB za sekundu zvládne pole, které poskládám z dílů z Aukra bratru za dva litry a bude mít kapacitu řádově v jednotkách TB.
Vyuziju tveho linku: http://web.forret.com/tools/video_fps.asp?width=4096&height=2160&fps=60&space=raw&depth=12
Prosim o link na diskove pole za 2 litry ktere zvladne treba hodinu zaznamu 4K v 60fps RAW pri datovem toku 6,37 Gbps
-
To nevím, moje pole za dva litry zvládá datový tok okolo 3,6Gbps ;)
(http://i.imgur.com/BpFGE2v.png)
http://imgur.com/BpFGE2v
To na 25FPS bude tuším stačit, celková kapacita je necelé tera.
-
zaujalo me to 4k/240 fps - sice mi to prijde zbytecne moc, ale asi to bude nejakej bezva tunel projekt z dotaci, tam se na nejakou korunu nehledi, tak proc se trochu nerozmachnout ;)
pro orientaci v terenu - iphone 6 plus nahrava 720p @ 240 fps, takze vlastne staci 6 ajfounu + nejaka optika, a je to hotovy i se snimanim a ukladanim :)
h.264 kompresi na kompu date v realtime za mesic, pravda, bude to zrat spis 400w +
bezeztratove jsem nezkoumal,ale gugl najde : http://lmgtfy.com/?q=4k+loseless+codes (http://lmgtfy.com/?q=4k+loseless+codes)
-
Pro vsechny negativisty - 4K kameru s nekomprimovanym zaznamem jsme si postavili from scratch. A nahrava to 4k/24fps @ 16bit zatim (400MB/s), na pole ze dvou 240GB SM843T v RAID0. Dalsi krok bude nasazeni pcie disku XP941 - 900MB/s by melo postacit na 60fps.
Ale ani jedno z reseni nezaruci ze data pujdou obnovit pri selhani radice - bude tam zaber za X milionu nebo zaber neopakovatelny - co s tim pak? Proto chci udelat vlatni disk.
Nez zacnete psat sve blaboly, ujasnete si velikost dat. Pri 4k se jedna o cca 8MPx x 10 nebo 12 bitu tj 10 az 12 MB soubor na frame. Jestli tak prosazujete kompresi, ukazte mi lossless algoritmus, ktery realtime dokaze zpracovat 2000 MB/s dat... realna komprimovatelnost dat je pri lossless cca 60-80% puvodnich. A znova - pri jake energeticke narocnosti? Zadna komprese neni efektivnejsi, nez adekvatne vetsi a rychlejsi uloziste zalozene na flash pametich.
-
zaujalo me to 4k/240 fps - sice mi to prijde zbytecne moc, ale asi to bude nejakej bezva tunel projekt z dotaci, tam se na nejakou korunu nehledi, tak proc se trochu nerozmachnout ;)
Nebudes verit, ale delame to z vlastni iniciativy a vlastnich zdroju.
pro orientaci v terenu - iphone 6 plus nahrava 720p @ 240 fps, takze vlastne staci 6 ajfounu + nejaka optika, a je to hotovy i se snimanim a ukladanim :)
Mel jsem cest s 4K zaznamem z Galaxy S5... cca na urovni youtube v 1080p. Lidi maji dneska hodne zkreslene predstavy o rozliseni - hlavne ztratova komprese ti ihned odstrani vsechny jemne detaily.
A pak je tu dalsi nesvar typu rolling shutter - podstatne to omezuje tvurci moznosti a kdyz si kameraman neda pozor, je z toho na bliti. My mame volitelne rolling / global shutter (v GS to sumi vice ale obraz se nedeformuje pri pohybech kameru nebo sceny).
-
Chyby se proste stavaj. Data pak co nejdrive prelej nekam jinam a mas to. Neres nesmysly. Pouzit RAID10 bude vyhodnejsi nez lepit svuj vlastni SSD.
-
No, mám lepší věci na práci, než se tu s vámi drbat hovada nevzdělaný ;)
Dovolím si zopakovat několik faktů:
- chceš ukládat 12MB * 240 FPS = tj. ~2.5GB/s slovy 2.5GB za vteřinu
- propustnost SATA 6 portu je 6 Gb/s tj ~600 MB/s
- řadiče na desce jsou připojené pomocí JEDNÉ PCIexpress x1 linky
- propustnost PCIexpress 3.0 x1 je 1 GB/s v jednom směru (nové desky, staré desky mají jen 500MB), takže je uzadeke, kolik disků tam připojíš a jak budou rychlé, protože víc než 1GB/s do toho stejně nedostaneš
- ale jistě můžeš použít PCIexpress x4 řadič, ten má teoretickou propustnost až 4 GB/s
- x4 PCIexpress verze 3.0 řadič bude stát víc než ty rozebranej na drůbky a prodanej do Číny
Howg.
PS: Pole za dva litry uloží skutečně těch 400-500MB/s a za ty dva litry se dá sehnat včetně řadiče, stačí si jen počkat.
A netvrdím, že je nemožné ty data uložit, naopak je to prosté, stačí těch polí použít víc a vhodně je škálovat.
Ještě úplně mimochodem, napsat ovladač pro bezztrátovou kompresi na grafické kartě bude tuším o řád jednodušší, než vyrábět megapole s vlastním firmwarem.
-
Pánové, RDa dobře ví, o čem mluví, zabývá se tím několik let a má skvělé výsledky. Rady, které jste si právě teď vycucali z prstu, si myslím celkem v klidu můžete nechat od cesty. RDa vás poprosil, jestli nemáte nějaký plonkovní ssd disk. Co s ním dělat už nechte na něj...
Já bohužel žádný nemám, jinak bych ho na tenhle projekt s radostí daroval, sorry, RDa.
-
Chyby se proste stavaj. Data pak co nejdrive prelej nekam jinam a mas to. Neres nesmysly. Pouzit RAID10 bude vyhodnejsi nez lepit svuj vlastni SSD.
Dvakrat vetsi spotreba a dvakrat vetsi rozmer? To neni reseni.
Udelat si vlastni otevrene reseni ma smysl (taky snad pouzivate linux namisto jineho OS z duvodu toho, ze vite co je uvnitr). Muzeme mit obvody v RAID5 nebo 6 - nejmensi narust rozmeru a spotreby. Navic pri pristupu ke kazdemu cipu muzeme ridit co kam pujde - rozkladat radky nebo snimky tak, aby pri ztrate treba pulky pole slo obnovit obraz alespon s polovicnim rozlisenim, nebo polovicnim fps pri HFR snimani.
-
Dovolím si zopakovat několik faktů:
- řadiče na desce jsou připojené pomocí JEDNÉ PCIexpress x1 linky
- propustnost PCIexpress 3.0 x1 je 1 GB/s v jednom směru (nové desky, staré desky mají jen 500MB), takže je uzadeke, kolik disků tam připojíš a jak budou rychlé, protože víc než 1GB/s do toho stejně nedostaneš
- ale jistě můžeš použít PCIexpress x4 řadič, ten má teoretickou propustnost až 4 GB/s
Nejsou. "Radice" na desce (reseni Intel) jsou pripojeny pres DMI, coz je ekvivalent x4 PCIe Gen2 = 2GB/s. Ale nekde uvnitr je tam jeste uzke hrdlo, protoze pri cteni z vice disku to neda vic nez 1.2GB/s. Pri zapisu to bude podobne, at mate tech sata portu treba 6.
PCIe x1 gen3 radice neexistuji.
A jedna se o kameru, o rozmeru 12x12x12 cm, ne o standardni PC.
-
Pánové, RDa dobře ví, o čem mluví, zabývá se tím několik let a má skvělé výsledky.
Výsledky?
Zatím vidím jen to, že nemá páru o tom, že skrz PCIexpress 1x dva a půl gigabajtu neprotlačí ani omylem.
A taky vidím to, že na to jde stylem "když to nejde opravit kladivem, udělám si kladivo větší".
SATA 6 je jen mokrý sen, protože i kdyby použil několik SATA 6, tak pořád před to bude muset vrazit extra řadič.
Tj. je to kravina.
Pokud chci zpracovat data, která jsou přes hardwarové limity, musím na to jít chytře.
Byť přiznávám, hodně vytrvalých tupců uspělo i s tím "větším" kladivem.
Kdybych měl řešit danou úlohu sám, mám dvě možnosti:
A) Změnit zadání úlohy tak, aby se dala realizovat pomocí existujícího HW.
B) Upravit úlohu tak, aby jí existující HW dostačoval.
Netuším, jakým způsobem do toho počítače rve ty dvě a půl gigabajtu dat, přes USBčka těžko, protože USBčka budou nejspíš bydlet na stejné sběrnici jako diskový řadič, což je PCIexpress 1x, takže v jistém smyslu ...ano...to bych rád věděl, jak do toho pecka těch dvě a půl gigabajtu dat vůbec dostává. Ale je tu možnost zpracování a dost možná nejlépe grafickou kartou.
Možná natáčí něco vůči bílému pozadí, tam by třeba šlo vynechávat duplicitní bloky, což by mohlo poněkud zkrotit datový tok.
Možná natáčí porno, tam ale netuším, proč to potřebuje bezeztrátově, no, komprimování porna není můj obor.
Uložit cca 1 až 2 GB dat/s není vážnější problém a je to realizovatelné levně, předpokládá to velkou ram, která bude sloužit na vyrovnávání občasných zamyšlení disku a dvě řadiče. Lacino půjde uložit cca 1gigabajt za vteřinu, ty dvě giga jsou už trochu problém.
Pokud nechceš snímky distribuovat, což by byl problém sám o sobě s ohledem na cenu a propustnost 10GB adaptérů, stejně ti nezbývá nic jiného, než:
A) vyrobit si vlastní PCIexpress 4x 3.0 kartu, což je z té uvedené kategorie vlhkých snů
B) jít cestou více řadičů, každý obývající vlastní PCIexpress 1x slot.
Zkrátka a jednoduše, začít vyrábět vlastní "SSD" disk, když nemám páru o tom, jak je to v pecku zadrátované, je dle mého názoru nedoukovina. Ale prosím, rád si poslechnu, jak chce těch dvě a půl gigabajtu dostat na to rozhraní toho SSD disku, třeba mi něco uniká.
-
Netuším, jakým způsobem do toho počítače rve ty dvě a půl gigabajtu dat
Senzorova hlava je x8 PCIe gen2. Do "pocitace" to nejde - cela kamera je system sam o sobe - je mozne v nem vyuzit standardni PCIe komponenty, ale karty nemaji tvar desktopovych PCIe karet, takze vse navrhujeme po svem. Hlavne kvuli tomu, ze chlazeni je zcela pasivni. K dispozici je 6 slotu, kazdy max x8 gen2 (gen3 bude pozdeji), objemove 110x100x15mm.
A) vyrobit si vlastní PCIexpress 4x 3.0 kartu, což je z té uvedené kategorie vlhkých snů
Dnes to neni zadny sen (x8 gen 2.0 nam udela stejnou sluzbu a levneji), chybi jen ty pameti.
-
Nejsou. "Radice" na desce (reseni Intel) jsou pripojeny pres DMI, coz je ekvivalent x4 PCIe Gen2 = 2GB/s. Ale nekde uvnitr je tam jeste uzke hrdlo, protoze pri cteni z vice disku to neda vic nez 1.2GB/s. Pri zapisu to bude podobne, at mate tech sata portu treba 6.
PCIe x1 gen3 radice neexistuji.
A jedna se o kameru, o rozmeru 12x12x12 cm, ne o standardni PC.
Rozdělme si to.
Ad řadič: říkejme tomu třeba HABUBABLA, ale je to připojené přes PCIexpress 1X linku.
Ad PCIexpress v3.0 řadiče: Samozřejmě jsou a prodávají se: http://www.areca.com.tw/products/1882.htm
Ad kamera: Pokud jsou data komprimovatelná, uvážil bych třeba Thunderbolt, dostal to do grafické karty a tam z těch dat ořezal všechno, co není nezbytně nutné.
-
Zkrátka a jednoduše, začít vyrábět vlastní "SSD" disk, když nemám páru o tom, jak je to v pecku zadrátované, je dle mého názoru nedoukovina. Ale prosím, rád si poslechnu, jak chce těch dvě a půl gigabajtu dostat na to rozhraní toho SSD disku, třeba mi něco uniká.
Tak zaprve, tim tvym tvrzenim ze v PC je vse na x1 jsi hodne mimo a pochybuji ze neco o fungovani PC vic.
Data na uloziste dostaneme stejnym zpusobem jako od snimace - pres PCIe. Lze to resit 2-3 zpusoby:
1) pouzit x4/x8 sata/sas radic + 8x sata disk = 25-40 W
2) pouzit pcie switch + 8x pcie x1 na sata + 8x sata disk = 20-30W
3) udelat vlastni pcie ssd disk = fpga + hromada flash pameti = 5-10W
Vlastni reseni #3 ma vyhodu v tom, ze jede vse "nativne" a nejsou tam vubec zadne nepotrebne rozhrani ktere by jen spotrebovali energii. Jedina vyhoda reseni #1 a #2 je, ze to lze ubastlit rychleji, #2 vyzaduje sw raid, #1 muze byt hw raid.
-
Rozdělme si to.
Ad řadič: říkejme tomu třeba HABUBABLA, ale je to připojené přes PCIexpress 1X linku.
Zdroj informace? Radeji si precti jak se to doopravdy dela: http://en.wikipedia.org/wiki/Direct_Media_Interface
Ad PCIexpress v3.0 řadiče: Samozřejmě jsou a prodávají se: http://www.areca.com.tw/products/1882.htm
Jedna se o x8 kartu, ne x1. Precti si muj a tvuj prispevek vyse.
Ad kamera: Pokud jsou data komprimovatelná, uvážil bych třeba Thunderbolt, dostal to do grafické karty a tam z těch dat ořezal všechno, co není nezbytně nutné.
Data nejsou bezztratove komprimovatelna. Thunderbolt je opruz po strance licencni a poskytuje jen polovicni pasmo nez mame ted, tak proc do toho jit? Hlavne nejde o to dostat data z kamery do PC, ale ZAZNAMENAT je necim, co moc nezere a vejde se do maleho objemu (vlastni custom SSD).
-
AD SATA - mluvím o přenosové kapacitě ~1 resp. ~2 GB/s (tj. ekvivalentu PCIexpress 3.0 x1) u desktopových procesorů, tj. maximum co dostaneš až k Sata diskům. Fyzické zadrátování je vedlejší. Nerad bych, aby to bylo špatně pochopeno, byť jsem to nešikovně napsal, že k disku dostaneš maximálně 250mega, opravdu jsem mluvil o ekvivatelntu PCIexpress 3.0 x1 sběrnice.
A také nemluvím o serverových procesorech, které mohou mít a zpravidla mají jiné vlastnosti.
Protože s Xeonem E5450 jsem k diskům víc dostal.
http://ark.intel.com/products/33083/Intel-Xeon-Processor-E5450-12M-Cache-3_00-GHz-1333-MHz-FSB
-
Abych jen nehanil, můžu zkusit propustnost s čipsetem Z97 a Haswell Refressh i7 čipem (bohužel jen 1150), jestli se polepšili.
Naposledy jsem to testoval s i7 960.
Každopádně výsledek s X99/Intel Core i7-58x0K by byl zajímavější.
Intel má totiž v oblibě škrtit laciné procesorové řady.
Ale ani tak nebude vyhráno, na té sběrnici toho je pověšeného dost na to, aby přerušení vyvolané nějakým čertem způsobovalo výpadky.
-
kompresi nenutim, ja bych to bez ni nedelal. komprimovat se da vsechno, zalezi na I/O pozadavcich.
algoritmy na nejnovejsi video standardy existuji,ale tezko/draho dostupne.
CUDA to zvladne hrave,ale ne pod 400+ W a ne v 12 x 12 x 12 cm.
drzim pesti vasemu nadseni, ale moje zkusenost s beznyma ssd nic moc.
Z mene nez 10 uz 3 umrely uplne,ctvrty zacal nejak pomalu zlobit,data jeste pustil.
ale jen jeden byl po zaruce, zakosovi to nevadi, takze je vas : apacer a7 pro 64 GB,
kdyz tak xdrz@centrum.cz
preju Vam at Cameron vyhodi svoje red-1 kamery a koupi ty Vase, at mame druheho avatara v 4k@240fps ;)
PF 2015 !
-
Diky, napsal jsem email.
Ohledne komprimace, zde maji kalkulacku: http://comprimato.com/ - nejvykonnejsi grafiky jen tak tak daji realtime 4k. Je to sice relativne nenarocne na vyvoj, ale efektivita na watt je mizerna (RED ma rozhodne uspornejsi asicy, ale to si do desktopu nedate). Efektivneji vychazi hardbloky na h264 enc/dec v grafice/cpu, ale to neni pouzitelne na raw, ani profesionalni vystup (omezeno na 8bit)... takze se to hodi jen na proxy soubory nebo streamovani nahledu.
-
Mozete prezradit, ake flash cipy chcete pouzit? Bezne cipy maju tak 25MB/s. To k pozadovanym 2GB/s ma hodne daleko. Ak aj zozeniete nieco lepsie, tak sa dostanete k 40MB/s a viac ako 50ks aktivnych cipov. Momentalne si z hlavy nepametam spotrebu, ale pri cca 0.5W/cip sa imho do 10W nedostanete.
-
Řekněme, že chceme zaznamenat ve vysoké kvalitě něco neopakovatelného, na čem nám opravdu hodně záleží. A máme na to finanční prostředky. Proč bych to zaznamenával na nějaké SSD, ze kterého se možná nějaká data dají snadněji dostat, pokud odejde specifickým způsobem (typicky překročení počtu zápisů, nikoli totální úmrtí z jiného důvodu), a nezaznamenával bych to na klasické SSD disky ve více kopiích (nebo se samoopravujícími kódy), kde mám pravděpodobnost, že ta data z toho dostanu, mnohem větší? Navíc obnova by se musela dělat v nějaké laboratoři a nikoli uživatelsky přívětivým způsobem.
-
Proč bych to zaznamenával na nějaké SSD, ze kterého se možná nějaká data dají snadněji dostat (...) a nezaznamenával bych to na klasické SSD disky ve více kopiích (nebo se samoopravujícími kódy), kde mám pravděpodobnost, že ta data z toho dostanu, mnohem větší?
Na to tazatel už odpověděl: u toho vlastního SSD si uloží kopie přesně dle potřeby (rendundance/rozložení dat, aby šlo vždy obnovit celý záběr např. v poloviční fps nebo rozlišení atd). Prostě má volnou ruku, na tom není nic těžkého pochopit!
-
Celé mi to přijde jako hovadina a bla je popisu řešení asi nejblíž, ale ani on se nezeptal, co to je!
Kolik vteřin nebo minut chcete uložit?
Je to jednoúčelové zařízení, nějaká družice nebo to chcete dát do mičudy na příští mistrovství světa?
Pro určení nejvhodnějšího postupu tato informace chybí.
Takže hošani, co to kutíte?
Co to přibližně má dělat?
Pokud chcete natáčet bourající auto, štípání polen, louskání ořechů, dostaňte to nejdřív do počítače, tam by ten navrhovaný Thunderbolt mohl udělat svou práci, nehledě na to, že Intel pořádně neví, co s tím a dost možná by vás i nějak podpořili.
Ostatně mohlo by to mohlo jít třeba do X různých pecek, každý snímek jinam, takže ani ztráta jedné řady snímků by nepředstavovala zásadní problém. Rozdělení problému na dílčí úseky je dobré řešení.
-
Omlouvám se za gramatiku, jsem už kapku nalitej ;D
-
V PC to jiz mame - ale to je dobre jen tak na vyvoj, prakticky to je nepouzitelny - neda se to vzit sebou a jste zavisly na zasuvce. Ne ze by to neslo resit, ale je to pitomost pouzivat tak jak to je.
ad spotreba: XP941 ma neco pod 6W pro 950MB/s zapis, takze to rozhodne lze realizovat soucasnou (resp. budouci technologii) kdyz se z toho vypusti ty nepotrebne rozhrani. Toto reseni pokryva rychlost a je za prijatelnou cenu - az na tu moznost obnovy dat.
Cileni - nejjednodusej receno se jedna se o konkurenci na RED s tim ze feature-set se da uzivatelsky volit pouzitim vhodnych modulu (snimac, konektivita, uloziste, zpracovani dat), umoznime nekomprimovany zaznam (tj. vyssi kvalita, viz arri/arri65) a modularita zaruci nizsi "startovni" cenu zakladniho setu.
Puvodni myslenka byla to sestavit z consumer komponent (nejnizsi cena), ale jak prichazi profesionalnejsi nasazeni a pozadavky, migruje se to na vlastni reseni. Jako vyvojovy/referencni/testovaci design se porad pouziva consumer a nehledal bych jine reseni, kdyby fungoval jak chceme.
-
V některých firmách, obvykle úspěšných, to funguje tak, že je ZAKÁZÁNO vyvíjet cokoliv, co by odsálo vývojové zdroje.
Chcete dělat 4K kameru na natáčení porna nebo superrychlé úložiště?
Nevím, jak velký kapitál za vámi je, ale mám pocit, že obojí nedáte.
A pořád se mi líbí ten Thunderbolt, existují super notebooky s Thunderboltem.
Třeba Apple MacBook Pro 15.4" Retina - Core i7-4870HQ, 16GB RAM, 512GB SSD s Retinou!
Těch 16GB ram je na nějakých osm vteřin nekomprimovaného záznamu, delší takovou scénu nemá smysl vytvářet.
Poděkoval bych Bla za jeho nápad, udělal nějaké demo vašeho udělátka a napsal do Intelu, aby vám pomohli.
Základní verze může být jen kamera připojená přes Thunderbolt a lepší verze třeba vaše udělátko ve spolupráci s Intelem procesované skrz Larrabee. Skoro si myslím, že ta firma má úplně všechno, co potřebujete. Navíc má Intel přímo nějaký program pro podporu Startupů.
-
16GB Ram je na 8 vteřin nekomprimovaného záznamu při ~200 snímcích za vteřinu, což se puštěné normální rychlostí protáhne na minutu záznamu. Bullet time nebo ve vašem případě možná Squirt time ;D ;D se tak protáhne na poměrně dlouhou až nudnou pasáž.
Rozšířením o dalších 16GB ram z toho máte 16 vteřin nebo taky dvě minuty záznamu.
-
Poděkoval bych Bla za jeho nápad, udělal nějaké demo vašeho udělátka a napsal do Intelu, aby vám pomohli.
Základní verze může být jen kamera připojená přes Thunderbolt a lepší verze třeba vaše udělátko ve spolupráci s Intelem procesované skrz Larrabee. Skoro si myslím, že ta firma má úplně všechno, co potřebujete. Navíc má Intel přímo nějaký program pro podporu Startupů.
Dekovat? Vzdyt reseni SATA pole pres PCH jiz ted mame (na 24fps/4k/16bit) a jak jsem psal, je tam omezena sirka pasma at si vezmete jakoukoliv desku. Pouziti raid karet jen prodluzuje slepou vetev vyuzivani standardniho PC desktopu, to nikdy k mobilite nepomuze. Ted procesujeme skrze iGPU na i5. Hodil by se model s eDRAM (ten ma 2x vetsi graficky vykon), ale typicky Intelovsky - se ten nachazi jen v ultraboocich, kde neni zadne tlustejsi PCIe k dispozici (max x1 v express-card slotu). V embedded ani socketovem provedeni neni.
TB je jen zabaleny a osekany PCIe (realne 8Gbps resp 16Gbps x 80% a minus displeje pokud tam jsou, TB1 resp. TB2). Vy mate velice zkreslene predstavy o Intelu - mit veci muzou, ale kdyz nemaji zajem to propagovat, resp. ani nemuzou protoze vsechno kolem TB ridi a tahne Apple samotny (Intel jen vyrabi par obvodu).
16GB Ram je na 8 vteřin nekomprimovaného záznamu při ~200 snímcích za vteřinu, což se puštěné normální rychlostí protáhne na minutu záznamu.
Pro 4K bude brzo standardni frame rate 120fps (viz EBU). Takze vasich 16GB umozni nahrat uzasnych 13 vterin. A co pak? 5 minut pauza nez to ulozite? Cilem je udelat zarizeni ktere nema tyto umele limity, jen proto ze se nam nechtelo na tom pracovat.
Architekturu uz mame navrzenou a posledni dva roky vyvoje a testovani potvrzuji ze smer a technologie ktere jsme zvolili jsou ty spravne. Tyto zkusenosti Vy ani Bla evidentne nemate...
-
Tyto zkusenosti Vy ani Bla evidentne nemate...
No, nemají (a kromě zkušeností nemají ani dostatečné teoretické znalosti) - ale kecat budou, to si nemůžou nechat ujít...
-
A nechcete to natočit na film a a pak to oskenovat? film má prý velké rozlišení
-
Navic pri pristupu ke kazdemu cipu muzeme ridit co kam pujde - rozkladat radky nebo snimky tak, aby pri ztrate treba pulky pole slo obnovit obraz alespon s polovicnim rozlisenim, nebo polovicnim fps pri HFR snimani.
Pak nechápu, proč potřebuješ reverzovat existující disk -- normální desktopové SSD určitě neumí rozkládat obraz na řádky :). Prostě nakup flash čipy, vraz před ně rychlé FPGAčko a naprogramuj si tam to rozložení na řádky. To je podle mě nejdostupnější, energeticky výhodné, relativně jednoduché a jediné prakticky proveditelné řešení.
Koukni, jestli už není nějaký hotový FPGA devkit na PCIe x8 nebo x16 (x1 ti asi nestačí). Dokonce říkáš, že v kameře ti to po PCIe x8 leze - takže to stačí „jenom“ prodrátovat, ne?
-
Tak ucelem meho postu bylo sehnat ekvivalentni hromadu pouzitych flash cipu (cca 320 ks) na sestaveni prorotypu noveho SSD - nez nakoupime ty drahe obvody ktere maji osm cipu v sobe. Nase zdroje nejsou neomezene a rad bych pak uloziste / FTL uvolnil jako opensource.
-
Tybrďo fascinuje mě, kolik mudrlantů ani nedokáže pochopit, že kamera, pravděpodobně postavená na FPGA, s propojením modulů pomocí PCI Express rozhraní nad obecnými GTX/GTP/GTH/whatever SERDES transceivery má úplně jiné možnosti postavení SSD úložiště, než to co nabízí PC. Je jasné, že to co je na trhu, bohužel naprosto nepostihuje jejich potřeby. Oni se snaží našlapat RYCHLÉ úložiště přímo do kamery - a mají tam k tomu rozhraní. Plky o tom, kolik propustí DMI/QPI/SATA/SAS/whatever jsou naprosto liché. Pravděpodobně hodí další modul s FPGA na PCIe x8 2.0 linku, a ten bude mít na sobě přilepené FLASH paměti. Problém ale je potom naprogramovat takový kontrolér uvnitř FPGA, který se postará nejen o rychlost, ale i o korektnost těch uložených dat. Pro onu udávanou rychlost na 240fps to bude poměrně výzva, a to zejména z hlediska počtu čipů a relativně pomalého zápisu. Při taktu vnitřní logiky FPGA 125 MHz, což je takt AXI4 PCI Express bloku při 128 bitové šířce dat (což ale třeba Xilinx při Gen2 nepodporuje, a já fakt nevím jaké máte řešení), bych data rozhodil na ještě širší paralelní sběrnici, nad kterou už by se dala realizovat detekce/oprava chyb i s tím bitratem, co leze ze snímače. Bude to takový malý závod počet taktů/ECC vs. počet bitů sběrnice vs. počet čipů na požadovanou kapacitu. Taky asi bude poněkud vyšší počet takových úložných desek, aby to mělo alespoň nějakou kapacitu.
Nabízí se samořejmě použít PCIe SSD disky hotové, ale to by cenou šlo někam úplně jinam. PCIe budete mít budičema vyvedené do kabelu ven z kamery, tak by to pak bylo o té bedýnce s SSD. Chápu že cílem je něco jako PCIe disk, který bude garantovat integritu dat - ale nevím jestli vám pomůže rešerše stávajících disků - ty jsou dělané na trochu jiné účely (random zápis, wear-leveling, atd.). To co vy potřebujete, je před nahráváním hodit erase na všechny stránky, a pak co nejrychleji pouze zapisovat. Není potřeba řešit zároveň čtení, nebo opotřebení buňek. Dalo by se to řešit vůbec nejlíp tak, že by se data proložila napříč velkým blokem, a návazný ECC by se zapsal spolu s daty, a případná detekce/oprava by se řešila až při čtení dat z kamery do návazných zařízení. Tak by to snížilo složitost řadiče, který by pouze musel být schopen data s ECC zapsat - to bývá výpočetně mnohem jednodušší úloha než dekódování. Vlastní relativně složité dekódování a detekci/opravu bych nechal na serveru, který by data z kamery bral a strkal na nějaké enterprise úložiště. Tam už by to eventuelně ani nemuselo splňovat plnou rychlost potřebnou pro zápis.
Nějaké vadné SSD by byly, ale bohužel se každé důkladně před vyřazením provrtává....
Co by také bylo určitým řešením, které by mohlo daný SSD boxík zlevnit, je použít normálně dostupně levné SSD disky s velkou kapacitou, a udělat pouze zakázkový PCIe / SATA3 nebo SAS2 řadič. Obávám se ale, že na rychlost ASIC řešení např. od LSI byste se s tímhle nedostali.
-
Tak mě napadá, RDa, zkoušeli jste konktaktovat nějaké prodejce/servisy? Kdybyste jim hezky pověděli váš příběh, možná by byli ochotní vám nějaké ty vyreklamované vadné SSD dát.
Kontakt na jednoho menšího prodejce a servis hw bych měl, budu s nima mluvit někdy v průběhu ledna, února, tak se můžu zeptat. Ale je to menší prodejce, tak nevím, jakej u nich obrat tohodle zboží je...
-
Konečně někdo kdo tomu rozumí - nepoužíváme dodávaný AXI bridge, který je právě omezený na x4 gen2 jak píšete, ale máme vlastní PCIe jádro (128b x 250MHz) a DMA řadič.
Co jsem z těch dosavadních flash obvodů zjistil je, že pravděpodobnost souvislých chyb v rámci stránky je extrémně nízká, resp. chyby nejsou na stejných místech když si proložíme mapy chyb více obvodů (zde pak samozřejmě větším počtem obvodů pravděpodobnost zhody narůstá).
Za předpokladu, že tomu tak bude nadále, což se dá zjistit experimentálně, analýzou dostatečného počtu hodně použitých pamětí, lze nasadit algoritmus, který bude vracet správná data (např. tj minoritu z výpočtů s vyloučením obvodu*, lze to provozovat paralelně a proudově v dlouhé pipeline, bez nutnosti práce nad bloky).
*) představte si RAID5, kde jeden z disků záměrně obsahuje chybu - jedině při vyloučení chybného disku dostaneme správná data (1x) a v ostatních N případech (pro N+1 disků v poli) jsou data stejná, ale nesprávná.
@LKG: a nemohl by jsi zjistit, zda to nejdě smluvně ošetřit, nebo vrtat jen řadič? O jaký sektor se jedná?
@Mirek: zkusím servisy, ale řekl bych že to musí postoupit dodavateli, zjistím
-
@Mirek: zkusím servisy, ale řekl bych že to musí postoupit dodavateli, zjistím
Kdyžtak pak dej vědět (nejlíp asi sem), co jsi zjistil. Vzpomněl jsem si ještě na jednoho prodejce hw, kterýho bych se taky mohl zeptat, ale ten je hodně malý, tam asi nic nebude.
Potom bych ještě doporučil zkusit kontaktovat http://www.device.cz/, pana Sotoláře - je s ním docela rozumná domluva. Ta firma dělá likvidace podnikového hw ve velkém a co je použitelné, prodává. Nevím, kolik ssd se u nich objeví, ale za pokus by to stálo. Každopádně by to ale imho chtělo udělat nějakou hezkou, jednoduchou propagační stránku, kde byste polopaticky řekli, k čemu to chcete a proč to chcete zadarmo. Něco jako "jsme malý český startup s jedinečným výrobkem ... prosíme, podpořte mladé České podnikatele" ;) k tomu pár fotek, aby bylo jasný, že už něco máte a víte, co děláte.
Třeba by se tady našlo zepár lidí, kteří by byli ochotní se domluvit na akci, že by si link na tu stránku vytiskli a při návštěvě nějakýho místního hw shopu by jim to s prosbou o podporu předali :)
-
@RDa: Bohužel, company policy. Disky se rozebírají, a provrtává každý flash čip. Obejít to nejde. Valná většina jsou Intel SSD enterprise-class disky různých řad a dat výroby. Rád bych pomohl, ale tohle neobejdu. Jak už někdo radil - mohlo by pomoci obrátit se e-mailem na servisy PC techniky nebo na větší dodavatele (IBM, HP atd.) oficiální žádostí.
Každopádně vám ale fandím, protože když jsem četl o českém projektu profesionální kamery 4k poprvé, a viděl provedení a domyslel si technologii, tak mě vyloženě zahřálo u srdce, že jde někdo do takového technologicky zajímavého projektu.
S těma FLASH, ono se o tom hodně mluví jak je to bůhvíjak nespolehlivé, a že to nic nevydrží. Bullshit. Praxe ukazuje, že FLASH si toho nechá líbit spoustu, a to obecné povědomí je způsobené hlavně různými USB klíčenkami a entry-level SSD s odpadem při výrobě místo pamětí. Pro vaše použití jako úložiště nepotřebující náhodný přístup bych opravdu nevymýšlel bůhvíjaké zabezpečení. Můžete bezpečně kontrolovat, kolik toho která stránka té které paměti zapsala. Pokud si to nebudete komplikovat souborovým systémem, ale bude zapisovat lineárně, tak stačí zajistit, aby bylo možné zjistit a opravit chybu. Při přiblížení ke garantovanému počtu zápisů FLASH pak můžete začít vypisovat doporučení k výměně úložiště. Jakýkoliv RAID nezajistí integritu - musí zde být mechanismus, který dovede určit že ty čtená data jsou vadná, a eventuelně dokázat chybu opravit (než RAID, vždycky bude lepší i nejobyčejnější Hammingův kód). Minorita podle mě není vhodná, protože je stále potřeba určit, jestli ta minorita je ta "správná". Tady to je místo opravdu pro samoopravné kódy, a vzhledem k pravděpodobnosti výskytu chyby budou stačit i ty jednodušší. A jak jsem načrtnul už v minulém příspěvku, kódování samotné je velmi rychlé, a stačí k němu minimum logiky. Lze tedy realizovat velmi rychlý zápis, což je to, co potřebujete. Kdybych použil nějaký kód, který bude mít např. 1024k data + 128b ECC (v praxi blbost), tak kdybych chtěl rychlý preview, co že to mám na kameře zaznamenané, tak můžu číst jenom ty data, a číst jenom tu datovou část. Když to budu chtít bezchybně přenést a zkontrolovat a opravit pro další střih, tak už to budu číst i s tou ECC částí a ty chybná data kdyžtak opravím.
Nemyslím si ale, že se příliš s chybami potkáte. Jak bylo napsáno v příspěvku, pravděpodobnost souvislých chyb je minimální. Stejně tak v situaci, kdy má flash zapsaná data a stránka se poškodí, tato jde číst, ale nejde již smazat a zapsat. Výhodou pořád je, že jde o sekvenční zápis. A je možné zajistit před započetím nahrávání, že všechny sektory šly vymazat. Pokud budete brát za bernou minci analýzu vyjetých SSD, tak tam není vůbec garance toho, že byly správně používány. Ještě stále spousta filesystémů ignoruje TRIM, nebo je nesprávně použit (misalignment stránek s partitionami). Stejně tak wear-levelling algoritmy se liší a nedělám si iluze že to bude bůhvíjak promyšlené a efektivní. Pokud byste chtěli analýzu, co udělá s FLASH vaše kamerová srandička, tak vezmětě nějakou velkou NAND flash, připravtě nějaký soubor s náhodnými daty, a vždy tu pamě't celou korektně vymažte, lineárně zapište připravený obsah, načtěte ho zpátky a verifikujte. Opakujte do zblbnutí. To se přiblíží praxi mnohem blíž než analýza vyjetého SSD, u kterého ani nevíte, jak se zapisovalo, protože neznáte algoritmus. Můj odhad ale je, že ta flashka bude dobrá, a pak se najednou odporoučí celá.
Jestli se můžu zeptat - co přesně používáte za FPGA v různých částech kamery ? Jestli to teda není součástí trade secret :)
-
@LKG: V současné hlavě kde jsou 3G SDI výstupy je S6, pro nové návrhy pak volím A7 resp. K7 podle potřeby x4/x8 PCIe. Kromě toho experimentujeme s použitými deskami, kde jsou V5/V6.
Nápad na preview bez ECC je zajímavý. A podobně by se dalo ušetřit redukcí na 8bit (na náhled opravdu nepotřebujete 12-16 bitů) resp. nižší rozlišení (line skipping) - když se budou data patričně distribuovat mezi obvody, je možné nechat většinu flashek spát.
Ohledně opravy chyb - ve video aplikaci by se navíc chybějící data dali interpolovat (podobně jak se dělá oprava dead/hot pixel) - s tím že vada ve flash se objeví jen v jednom snímku, takže lze jako referenci použít i okolní snímky (temporal noise reduction).
Ale raději bych byl za spolehlivé úložiště (už z podstaty že tam budou i metadata a časem třeba zvuk).
-
Nojo, to s interpolací jsem původně v minulým příspěvku měl - ale protože jsem nikdy nedělal s videem, tak nevím, nakolik by se lišila výpočtová náročnost interpolace při chybě a korekce chyby přímo v pamětech.
Úložiště určitě udělejte spolehlivé - alespoň pro finální vyčtení záznamu.
Jinak jsem opravdu zvědav jak budete pokračovat, s radostí si o tom někde přečtu.
-
Vzhledem k tomu, ze shanite SSD disky, tak patrne chcete pouzit NAND pameti. Ty mi ale k takovemu ucelu prijdou krajne nevhodne. Predne se nejedna o klasickou linearni pamet jako bylo u klasickych NOR pameti nebo HDD bez bad blocku, pak maji extremne nizky pocet mazani bloku, bad bloky jsou v pametech oznacene uz od vyrobce (otazka je jestli jsou doopravdy vadne).
Z toho plyne pomerne hodne negativ, ktera musite resit a bez souboroveho systemu vam to da celem dost prace. Souborovy system se zase blbe dela bez operacniho systemu. Hlavni je wear leveling, vypocet ECC a predmazavani prazdnych bloku.
Nase zkusenosti ukazuji, ze RAW NAND flash pripojena k procesoru pres FPGA, mela celkem mizerny vykon (horsi nez low cost CF karta v PIO modu na ATA rozhrani) (file system i ECC delal linux pomoci JFFS a UBIFS, ecc pocital procesor)
Jasne muzete rikat, ze se bez wear lelevingu a ECC obejdete, ale myslim, ze casem dojdete k tomu, ze tam nebyly vymysleny jen tak pro nic za nic.
Treba jednoducha otazka, bude na ulozisti vzdy jen jeden ,,film'' nebo umoznite nahravat a nahodne mazat ruzne sekvence? Pokud je odpoved ,,nahodne mazat'', tak se bez OS opravdu hodne nadrete.
Hodne zajimave je cteni ONFI specifikaci (jsou volne stazitelne).
Kdybyste se ptali na muj nazor, tak ja osobne bych doporucoval uz v kamere delit snimky na 1/N a kazdy ukladat na jiny z N standardnich disku uvnitr zarizeni. (i kdyby tam kvuli tomu melo byt N standardnich procesoru). Takhle od stolu bych odhadnul, ze se N bude pohybovat v rozsahu 4 az 8. Jedina nevyhoda je, ze clovek nevidi do FW disku a ten by se mohl v krajne nevhodne situaci zamyslet.
-
@greatlama: samozrejme ze NAND pameti - jedna se o "mass storage". Prave pres ONFi jsem ziskal tu mapu chyb (ciz clanek na DIIT) a radic bude implementovan pres FPGA. Extremne nizky pocet zapisu nevadi - i kdyby se jednalo o 1000 cyklu, znamena to 1000 x pouzit kameru (tolik vam nevydrzi ani baterie) a pak - kdyz vytvorite v prumeru 1h / 1TB materialu denne, znamena to ze jste pres tri roky vytvoril 1PB dat. Kdyz si tim nevydelate na cenu media (dle dnesnich cen cca 10-15k kc) tak ta technologie neni pro vas.
Wear leveling pro velke souvisle bloky neni problem - zakladni blok je rekneme 10-12 MB frame (mene neni treba ukladat), to vuci disku s 512B sektory je 25000x jednodussi ukol. Erase block v 64Gb flash je 256 stranek = 2MB, tj nikdy nemusite resit neuplne naprogramovane stranky. Prave tim, ze primarni cil zatim neni obecne uloziste muzeme delat ruzne zjednodusovani na zacatku.
Dalsi technicky problem pouziti standardnich disku, je AHCI.. vy ty data tam nemuzete aktivne tlacit, musite je ulozit do pameti a pak rict radici at je zapise. On si pak ty data postupne cte a posila disku. Cele to vnasi spoustu mrtveho casu a taky potrebu mit data v pameti a tu pamet obsluhovat. Ne ze by to byl problem, soucasna generace bude prave takto fungovat, ale jde to i lepe - zapisovat do sveho pole pameti primo. Alternativa je preskocit AHCI ($5) a pridat vlastni SATA radic, ktery bude pakety tlacit rovnou na disk jak prijdou ($200 + $x0.000 sata jadro + prace).
-
Mne se to reseni s primo pripojenym polem NAND pameti libi... Ale myslim, ze mnozstvi prace tam bude astronomicke...
Chapu, ze pokud budete info o ,,file systemu'' drzet v jine pameti nez v NAND a pracovat vzdy s celym blokem, tak se cela uloha celkem zjednodusuje a 1000 cyklu nemusi byt nutne problem. Ale ty proklate bad bloky a ECC tam bude porad.
Navic pokud umoznite uzivateli mazat a bude mit 90% pameti obsazene a do zbyvajicich 10% smazit videa, tak vam nepomuze ani kruhovy buffer. Navic budete muset resit fragmentaci, ale to asi vite... :)
Preju hodne stesti, NANDek mam par v supliku, ale ty by vam asi radost neudelaly: jedna vrstva, 1Gb.
-
Ale myslim, ze mnozstvi prace tam bude astronomicke...
Přesně.
A jak už tu bylo řečeno, pokud chtějí dělat kameru, možná by se víc mohli věnovat vytváření software té kamery.
Kdo si myslí, že udělat dobrou optiku je snadné, je prostě blázen.
Vím, že mě tu máte za debila a je mi to popravdě fuk ;)
I kdybyste tam narvali paměti ram vypořádali se s refreshem, uděláte lépe. Tahle paměť jde koupit levně a nemá problém s opotřebením. Klidně natvrdo udělat omezení na určité paměťové moduly o specifické kapacitě a mohlo by to být i ploché úložiště bez souborového systému. Těch 250FPS nebude nikdo ukládat v řádech hodin, to už tu také bylo řečeno.
Buď to bude chtít zpracovat online, pak ty data chce hned nohit procesorem, nebo ho zajímají nanejvýš minuty.
Nižší datový tok pro změnu zvládne uložit na nějaké úložiště v PC.
A co, Váš problém.
-
Dobry den,
so zaujmom som si precital diskusiu, aj ked popravde moc netusim o com je :) ale dovolim si postnut zopar linkov ako namet, ze nieco podobne uz existuje. a neni to ani take drahe
http://www.sony.co.uk/pro/product/broadcast-products-camcorders-camera-adaptors/axs-r5/features/#features
http://www.sony.co.uk/pro/product/broadcast-products-professional-media-axs/axs-a1ts24/features/#features
-
Tak ucelem meho postu bylo sehnat ekvivalentni hromadu pouzitych flash cipu (cca 320 ks) na sestaveni prorotypu noveho SSD - nez nakoupime ty drahe obvody ktere maji osm cipu v sobe. Nase zdroje nejsou neomezene a rad bych pak uloziste / FTL uvolnil jako opensource.
kolik penez potrebujete na nakup tech drahych obvodu? Treba vam k tomu opensource pomuzu..
-
Dekuji za prvni 60GB kousek potvrzeny od uzivatele @jenda!
@OMG - 512Gbit obvody stoji cca $100, pro dosazeni rozumne rychlosti jsou jich potreba desitky. Vic nez castecne finance pomuze realny hardware nebo realne nasazeni vysledku naseho snazeni - ale kdyz uz jste to nastinil, mame zorganizovat sbirku na openssd? :)
-
RDa: na nejake (Vasi?) fotce SSD jsem videl neco co vypada silne jako SPI flash (predpokladam na firmware). Mohl byste z ni vytahnout obsah a nekam jej postnout s nejakou kvalitni fotografii plosnaku ? Diky.
-
@mhi_ ozvete se v PM, nebo nechte na sebe email... nebo si ho na me najdete a poslete odkaz na foto. Rad pomuzu ale ted nevim presne o co se jedna...
-
omlouvam se,nestih jsem jeste na postu,ale mam prvni cisla z testu grafiky,kdybyste o tom zpracovani pak uvazovali.
jsou to demace nvidie na mem zeleze, nikoliv tabulky comprimato.
Host to Device Bandwidth, 1 Device(s)
PINNED Memory Transfers
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 12203.9
Device to Host Bandwidth, 1 Device(s)
PINNED Memory Transfers
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 12293.0
Device to Device Bandwidth, 1 Device(s)
PINNED Memory Transfers
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 132231.4
mpeg2 : Average Rate of Decoding (fps) = 1000.19
CUDA sample DCT/IDCT implementation
Running CUDA 2 (GPU) version... 18448.895079 MPix/s //0.014209 ms
jeste testnu z linuxu
-
Jenze komprese neni jenom DCT. Ty dema ukazuji vykon jen pro DCT/iDCT, protoze to je paralelizovatelna cast a GPU se zde vyuzije, ale pak musite ty data po kvantizaci zabalit bezeztratove - a to neni zrovna v cem by grafika vynikala.
Vykon v dekodovani mpeg2 je pak ulet - kdyz opomeneme ze je to zcela spatny smer (dekodovani je vyrazne mene narocne) neuvadite vubec rozliseni, bitovou hloubku ani bitrate.
-
njn - jsou to dema ke stazeni zdarma, neni tam holt reseni bezztratove komprese 4k videa v realtime.
nerekl bych, ze bezztratova komprese se neda dobre paralelizovat, ale taky to neni muj boj.
proste jsem postnul neco, co aspon trochu bylo o kompresi obrazu.
mozna bude lepsi jine tema...
...tohle je taky slusne :)
./nbody -benchmark -numbodies=13312
= 2238.758 single-precision GFLOP/s at 20 flops per interaction
./particles -benchmark
particles, Throughput = 19154.5835 KParticles/s, Time = 0.00086 s, Size = 16384 particles, NumDevsUsed = 1, Workgroup = 0
-
zaujalo me to 4k/240 fps - sice mi to prijde zbytecne moc, ale asi to bude nejakej bezva tunel projekt z dotaci, tam se na nejakou korunu nehledi, tak proc se trochu nerozmachnout ;)
Nebudes verit, ale delame to z vlastni iniciativy a vlastnich zdroju.
pro orientaci v terenu - iphone 6 plus nahrava 720p @ 240 fps, takze vlastne staci 6 ajfounu + nejaka optika, a je to hotovy i se snimanim a ukladanim :)
Mel jsem cest s 4K zaznamem z Galaxy S5... cca na urovni youtube v 1080p. Lidi maji dneska hodne zkreslene predstavy o rozliseni - hlavne ztratova komprese ti ihned odstrani vsechny jemne detaily.
A pak je tu dalsi nesvar typu rolling shutter - podstatne to omezuje tvurci moznosti a kdyz si kameraman neda pozor, je z toho na bliti. My mame volitelne rolling / global shutter (v GS to sumi vice ale obraz se nedeformuje pri pohybech kameru nebo sceny).
Pekne! Mas nekde detaily ohledne te kamery? Docela by mne to zajimalo...
Global shutter 4K kameru na 60fps bych taky moc rad :) Na kolik Vas to prislo (soucastky, bez optiky)? Ze bych si ji taky postavil. A jaky senzor pouzivate? Hadam neco od Sony. Jaky to ma interface?
Jinak ocenuju ukladani pred debayeringem - offline se da udelat mnohem mnohem lepe.
Jen poznamka k te bezztratove kompresi - myslim, ze existuji pristupy, ktere jdou naimplementovat do maleho CPLD a datovy tok bez problemu zvladnou
- uz treba pouziti "delta" komprese, tedy ukladani rozdilu mezi pixely, muze prinest v pripade obrazovych dat velkou usporu
- idealne spojena s jednoduchou dictionary-type kompresi, aby se male rozdily ukladaly jako napr. 2-4 bity s tim, ze jeden bit oznacuje konec slova.
- take se da spojit s RLE kodovanim, ale prinos bude zavisly na variabilite dat
Implementace jednoducha a usetrite misto.
Ale samozrejme, pro dimenzovani prenosove rychlosti/bitratu musis brat worst-case, tedy originalni velikost + maly overhead komprese. Pokud tedy velikost mista neni problem, tak bych se na kompresi taky vykaslal :)
-
Tybrďo fascinuje mě, kolik mudrlantů ani nedokáže pochopit, že kamera, pravděpodobně postavená na FPGA, s propojením modulů pomocí PCI Express rozhraní nad obecnými GTX/GTP/GTH/whatever SERDES transceivery má úplně jiné možnosti postavení SSD úložiště, než to co nabízí PC. Je jasné, že to co je na trhu, bohužel naprosto nepostihuje jejich potřeby. Oni se snaží našlapat RYCHLÉ úložiště přímo do kamery - a mají tam k tomu rozhraní. Plky o tom, kolik propustí DMI/QPI/SATA/SAS/whatever jsou naprosto liché. Pravděpodobně hodí další modul s FPGA na PCIe x8 2.0 linku, a ten bude mít na sobě přilepené FLASH paměti. Problém ale je potom naprogramovat takový kontrolér uvnitř FPGA, který se postará nejen o rychlost, ale i o korektnost těch uložených dat. Pro onu udávanou rychlost na 240fps to bude poměrně výzva, a to zejména z hlediska počtu čipů a relativně pomalého zápisu. Při taktu vnitřní logiky FPGA 125 MHz, což je takt AXI4 PCI Express bloku při 128 bitové šířce dat (což ale třeba Xilinx při Gen2 nepodporuje, a já fakt nevím jaké máte řešení), bych data rozhodil na ještě širší paralelní sběrnici, nad kterou už by se dala realizovat detekce/oprava chyb i s tím bitratem, co leze ze snímače. Bude to takový malý závod počet taktů/ECC vs. počet bitů sběrnice vs. počet čipů na požadovanou kapacitu. Taky asi bude poněkud vyšší počet takových úložných desek, aby to mělo alespoň nějakou kapacitu.
Nabízí se samořejmě použít PCIe SSD disky hotové, ale to by cenou šlo někam úplně jinam. PCIe budete mít budičema vyvedené do kabelu ven z kamery, tak by to pak bylo o té bedýnce s SSD. Chápu že cílem je něco jako PCIe disk, který bude garantovat integritu dat - ale nevím jestli vám pomůže rešerše stávajících disků - ty jsou dělané na trochu jiné účely (random zápis, wear-leveling, atd.). To co vy potřebujete, je před nahráváním hodit erase na všechny stránky, a pak co nejrychleji pouze zapisovat. Není potřeba řešit zároveň čtení, nebo opotřebení buňek. Dalo by se to řešit vůbec nejlíp tak, že by se data proložila napříč velkým blokem, a návazný ECC by se zapsal spolu s daty, a případná detekce/oprava by se řešila až při čtení dat z kamery do návazných zařízení. Tak by to snížilo složitost řadiče, který by pouze musel být schopen data s ECC zapsat - to bývá výpočetně mnohem jednodušší úloha než dekódování. Vlastní relativně složité dekódování a detekci/opravu bych nechal na serveru, který by data z kamery bral a strkal na nějaké enterprise úložiště. Tam už by to eventuelně ani nemuselo splňovat plnou rychlost potřebnou pro zápis.
Nějaké vadné SSD by byly, ale bohužel se každé důkladně před vyřazením provrtává....
Co by také bylo určitým řešením, které by mohlo daný SSD boxík zlevnit, je použít normálně dostupně levné SSD disky s velkou kapacitou, a udělat pouze zakázkový PCIe / SATA3 nebo SAS2 řadič. Obávám se ale, že na rychlost ASIC řešení např. od LSI byste se s tímhle nedostali.
+1
-
zaujalo me to 4k/240 fps - sice mi to prijde zbytecne moc, ale asi to bude nejakej bezva tunel projekt z dotaci, tam se na nejakou korunu nehledi, tak proc se trochu nerozmachnout ;)
Nebudes verit, ale delame to z vlastni iniciativy a vlastnich zdroju.
pro orientaci v terenu - iphone 6 plus nahrava 720p @ 240 fps, takze vlastne staci 6 ajfounu + nejaka optika, a je to hotovy i se snimanim a ukladanim :)
Mel jsem cest s 4K zaznamem z Galaxy S5... cca na urovni youtube v 1080p. Lidi maji dneska hodne zkreslene predstavy o rozliseni - hlavne ztratova komprese ti ihned odstrani vsechny jemne detaily.
A pak je tu dalsi nesvar typu rolling shutter - podstatne to omezuje tvurci moznosti a kdyz si kameraman neda pozor, je z toho na bliti. My mame volitelne rolling / global shutter (v GS to sumi vice ale obraz se nedeformuje pri pohybech kameru nebo sceny).
Pekne! Mas nekde detaily ohledne te kamery? Docela by mne to zajimalo...
Global shutter 4K kameru na 60fps bych taky moc rad :) Na kolik Vas to prislo (soucastky, bez optiky)? Ze bych si ji taky postavil. A jaky senzor pouzivate? Hadam neco od Sony. Jaky to ma interface?
Jinak ocenuju ukladani pred debayeringem - offline se da udelat mnohem mnohem lepe.
Jen poznamka k te bezztratove kompresi - myslim, ze existuji pristupy, ktere jdou naimplementovat do maleho CPLD a datovy tok bez problemu zvladnou
- uz treba pouziti "delta" komprese, tedy ukladani rozdilu mezi pixely, muze prinest v pripade obrazovych dat velkou usporu
- idealne spojena s jednoduchou dictionary-type kompresi, aby se male rozdily ukladaly jako napr. 2-4 bity s tim, ze jeden bit oznacuje konec slova.
- take se da spojit s RLE kodovanim, ale prinos bude zavisly na variabilite dat
Implementace jednoducha a usetrite misto.
Ale samozrejme, pro dimenzovani prenosove rychlosti/bitratu musis brat worst-case, tedy originalni velikost + maly overhead komprese. Pokud tedy velikost mista neni problem, tak bych se na kompresi taky vykaslal :)
Tak jsem to docetl do konce :) Mate hruby cenovy odhad finalniho produktu? Takovou kamerku bych (dle ceny) i koupil, pokud tedy bude firmware spolehlivy a bude umet rozumnym zpusobem ridit delku zaverky behem snimani, idealne kdyby to umelo jeste ovladat automaticke ostreni (staci dle kontrastu, idealne detekci faze). Pokud to bude mit vystup na externi datove uloziste (staci pri 60fps), byla by to uplne krasa :) Jinak baterku bych neresil, nechal bych to napajet z volitelneho externiho zdroje.
-
@Randolf: Mas moznost se prijit na to podivat v Praze?
-
@Randolf: Mas moznost se prijit na to podivat v Praze?
Jsem v Brne, ale az budu mit do Prahy cestu, tak bych se stavil moc rad
-
jeste jsem se s tou mrtvolou na postu nedostal,a vyvoj mezitim nespi ;)
http://www.abclinuxu.cz/clanky/hw-novinky-ces-2015-2-nejen-ssd-m.2-s-adapterem-pci-express
-
"OCZ předvedla SSD M.2 PCI Express 3.0 s rychlostí 4 GB/s" ... zajimave ze to neni potvrzeno screenshotem. Tato hodnota je 'kosoctvercovina', protoze PCIe Gen3 je 8Gbps s 66/68 kodovanim, tj temer 8Gbps/lane. x4 rozhrani nam dava 32Gps = 4GB/s je jen rychlost rozhrani. Vzhledem k paketizaci prenosu na PCIe, je mozne dosahnout 90% realne ucinnosti, takze ten disk neda vice nez 3600 MB/s. Prakticky pochybuji ze da vic nez SM951 s 1.5GB/s write (efektivita 75% z 2GB/s - Gen2 x4).
To v cem teoreticky muze mit NVMe naskok je paralelizace zapisu a cteni, coz u AHCI neslo. Takze jestli 2GB/s write + 2GB/s read je pro vas 4GB/s rychlost... tak prosim. At zije marketing. Nejlepsi jsou ti co si zapnou ram-cache k samsung ssd a tesi se 8GB/s... jo neco me to pripomina - PMPO revival :)
-
ma jit o 4GB/s na smer (http://news.softpedia.com/news/CES-2015-OCZ-s-New-SSD-Controller-Enabled-8-GB-s-Bandwidth-469554.shtml), takze kdyz uz tak ne 2+2, ale 4+4 = 8GB/s :)
-
RDa: jsem si myslel, že jednotky okolo rychlosti PCIe máš zvládnuté...
PCIe 3.x zvládá 8 GT/s (gigatransferů za sekundu) a ne Gb/s. Není to 66/68, ale 128/130, tj. fyzicky tím rozhraním lítá 8.125 Gb/s, reálně 8 Gb/s. Takže na linku je to 1 GB/s v každém směru, u x4 tedy 4 GB/s. Žádné 2+2.
Pravda, nic nedokáže prakticky využít to rozhraní ze 100%, ani ten disk ne, ale zas tak daleko od toho nebudou.
-
Ferda: 2+2 je muj odhad realne dosazitelne rychlosti bez marketingu - pokud se to osadi nejnovejsimi pametmi a jejich NVMe zvladne paralelizaci.
Za 66/68 se omlouvam, Gen3 je nejspravneji asi takto: 128b/130b s tim ze na drate je 8Gb/s s obsahem 8Gb*128/130 = 7.876 Gbps na lane. Takze 4GB/s ani omylem jednim smerem to neda. O vasich 8.125Gb/s jsem nikdy neslysel.
PS. XP941 zvladne cca 80% rychlosti pcie pro x1/x2 rezim, v x4 je to omezeno jinym uzkym hrdlem na 1500MB/s read, 900MB/s write (asi pameti).
-
No prase aby se v tom vyznalo... většinou se píše ona signálová rychlost 8 GT/s, což by pak fyzicky dalo 8*130/128 = 8.125 Gb/s, reálně 8 Gb/s (transfer 130bit, ale bez parity jenom 128, takže jsme tam kde jsme byli). Některé zdroje zas říkají těch tvých cca 7.877 Gb/s...těžko říct, změřeno to nemám, každopádně jde o drobné.
Ale furt si myslím, že by ten disk mohl dát rychlosti někde vysoko nad 3 GB/s a že to nebude jen zápis někam do cache. Ono dneska by jim to hned každý otloukl o hlavu, kdyby to jelo poloviční rychlostí :) Je to prakticky totéž, o co se snažíš...paralelně protlačit co nejvíce dat na co nejvíce čipů. Jen oni (bohužel) mají jiné možnosti a prostředky než my.
-
Tak puvodne jsme zvazovali XP941 a pres pcie switch jich zapojit vice paralelne. Jsou tu ale dve ale 1) AHCI vyzaduje pamet na strane zdroje/cile dat, takze to neni uloziste kam by jsme tlacili - streamovali data primo... 2) pokud to selze, nikdo data nezachrani...
To o co se snazim, je v podstate PCIe ctecka NAND flash pameti bez wear-levelling logiky, kde bude omezenim PCIe, ne to ze je tam malo pameti (jako u vsech SSD ktere nedaji "wire speed").
I s novou generaci Samsung SM951 (1600R/1350W) a Plextor P7e (1411R/1028W) je to jen narust o par procent vuci XP941 ktery se da koupit. Kdyz me pamet neklame, tak ten disk byl dostupny po asi roce reklam a vybranych reviews. CES je pekna show, ale mimo realitu.
-
disk jsem sice pozde, ale prece poslal,
ale koukam, ze tady roste dotovana konkurence ...
http://cordis.europa.eu/news/rcn/122364_en.html (http://cordis.europa.eu/news/rcn/122364_en.html)
-
rok se s rokem sesel ...
https://www.mironet.cz/samsung-sm951-nvme-512gb-ssd-m2-2280-nvme-cteni-az-2150-mbps-zapis-az-1550-mbps-interni-oem-baleni+dp250449/ (https://www.mironet.cz/samsung-sm951-nvme-512gb-ssd-m2-2280-nvme-cteni-az-2150-mbps-zapis-az-1550-mbps-interni-oem-baleni+dp250449/)