Sháním vadné SSD k vývoji lepšího

[LKG]

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.

[Reklama]

[greatlama]

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.

[RDa]

@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).

[greatlama]

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.

[Bla]

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.

[Reklama]

[ToJeJedno]

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

[OMG]

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..

[RDa]

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?

[mhi_]

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.

[RDa]

@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...

[jenda]

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

[RDa]

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.

[jenda]

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

[Randolf]

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

[Randolf]

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