Versnellen van RAID opstelling

[flipkipse]

Allen,

Ik zit momenteel met een probleem in mijn opname computer. Deze computer loopt "rechtstreeks" de RAW beelden van een camera op een RAID 0 op te slaan.

De RAID 0 bestaat uit 4 HDD's van 4TB stuk (NTFS geformateerd). De HDD's zijn SATA ipv SAS in verband met kosten.

Nu zit ik met het feit dat de snelheid nog niet hoog genoeg is voor het wegschrijven. Alleen mijn vraag is, hoe kan ik dit "kosten gunstig" toch sneller maken. (Dus geen SAS er in van 15000rpm, want dat kost voor 16TB een vermogen).

Eerst dacht ik aan een SSD cache. Alleen dan heb ik een cache van bijna 2TB nodig.

Zou een externe RAID controller, anders dan mijn mobo RAID controller sneller zijn?

Zijn er andere oplossingen? Optane had ik over gelezen, alleen dit kan niet met een RAID volgens mij?

[Nielson]

Welke snelheid ben je minimaal nodig voor je camera, en is dit een continu stream of neem je in blokken op, en hie groot zijn deze opnames dan?

[Bigs]

Met 4 HDD's in RAID0 zou je in theorie makkelijk 200MB/s sequentieel weg moeten kunnen schrijven (als er geen fragmentatie is). Wat haal je nu?

[MAX3400]

Voor write-akties is cache niet handig want zoals je zelf zegt: al zou je 16TB cache opvoeren, dan heb je geen "cache" maar meer een soort NVRAM. Ongeacht of het 100 of 90000 Euro kost; de keren dat het volledig vol is, zal 0 zijn.

Ten eerste mis ik de voorvoer van de camera. Met alle respect, je kan hoog of laag springen maar bijvoorbeeld een EOS 5D3 genereert maximaal 160MB/s op 4098x2160p video. Dat houdt in dat jouw 4 drives elke 40MB/s continu moeten kunnen schrijven (ik gok random writes). Of je beschrijft je issue niet goed; wij moeten nu raden wat voor data je aanlevert aan jouw array.

Ook moeten we raden wat voor moederbord je hebt, wat voor controller erop zit, welke stripe size je hebt gekozen, welk OS er draait, etc. etc. etc.

Dat gezegd hebbende en even rondgekeken; bij 4K random read/writes, stort een WDC Red disk in naar nog geen 0,2 MB/s schrijven.


Het is dus ontzettend dubbel: je zou verwachten dat jouw array tientallen MB/s kan wegschrijven maar door het mogelijk archaische karakter van random read/write, zie je in de grafiek dat geen enkele disk dit normaal aan kan.

Meten is weten! Geef ons alle data van jouw opstelling en mogelijk kunnen we iets nuttigs zeggen over de hardware, de software, de kabels of desnoods ergens een vinkje in drivers ofzo.

[jan99999]

Welke snelheid heb je nu? Met je raid 0.
Doe eens verschillende testen.

Waar zijn je hd's op aangesloten, dus welke poort/controller.

Zoek een test/review van je camera, hoe snel is deze?

[MewBie]

En waarom wil je vanuit een camera rechtstreeks RAW video opslaan op een computer? Misschien is de verbinding tussen de camera en de computer de bottleneck.

[TommyboyNL]

@flipkipse Welke hardware gebruik je exact, en hoe heb je dat aangesloten?

[flipkipse]

Excuus voor het geven van te weinig informatie. ik ging er van uit dat bovenstaande voldoende was, maar realiseer mij ook, dat deze informatie zeer beperkt was.

Wat er momenteel gebruikt wordt:
HP Z240 met windows 10 (TR-HPz240)
CPU: I7-6700-CPU
RAID via Bios

(indien er meer componenten gespecificeerd moet worden, hoor ik het graag)

De prestaties die ik haal:
Crystaldiskmark:

[ Voor 46% gewijzigd door flipkipse op 08-08-2017 12:15 ]

[MAX3400]

flipkipse schreef op dinsdag 8 augustus 2017 @ 12:13:
Excuus voor het geven van te weinig informatie. ik ging er van uit dat bovenstaande voldoende was, maar realiseer mij ook, dat deze informatie zeer beperkt was.

Wat er momenteel gebruikt wordt:
HP Z240 met windows 10 (TR-HPz240)
CPU: I7-6700-CPU
RAID via Bios

(indien er meer componenten gespecificeerd moet worden, hoor ik het graag)

De prestaties die ik haal:
Crystaldiskmark:
[afbeelding]

Man man, wat een antwoord... Maar problem solved dus; je write-speed zit ergens tussen de 200 en 4MB/s. Dat kan dus te weinig zijn voor wat je probeert te doen. Aangezien je niet de moeite neemt om inhoudelijk (en voldoende) een aantal zaken uit MAX3400 in "Versnellen van RAID opstelling" te benoemen, is het simpele antwoord dat je werkstation gewoon niet toereikend is.

/edit: Fujitsu heeft gewoon een performance-chart van de C236 chipset en daar zie je dat deze enorm achterblijft qua random writes, soms wel een factor 20 (!!) ten opzichte van een instap PERC-controller of andere dedicated RAID-controllers. Ik ga je niet op kosten jagen, want dat moet je zelf weten, maar een LSI-controller op PCIe zal waarschijnlijk een veel betere performance halen dan je C236.

Ik blijf erbij; we weten nog steeds niets over de hele setup (hardware/software) dus ook een andere controller kan hierdoor beinvloed worden en haal je ook maar 4MB/s write.

[ Voor 23% gewijzigd door MAX3400 op 08-08-2017 12:24 ]

[TommyboyNL]

flipkipse schreef op dinsdag 8 augustus 2017 @ 12:13:
(indien er meer componenten gespecificeerd moet worden, hoor ik het graag)

Wat voor disks? Wat voor camera? Hoe zit je camera aangesloten op je PC? Hoe lang wil je aaneengesloten filmen en bij welke bitrate?

[ZaPPZion]

Als je gewoon 200MB/s haalt, lijkt me dat het meer zit in de aansluiting van camera naar PC? USB 2.0 is 480MBit/s = 60MB/s. Ik ken zo uit mijn hoofd geen camera's die RAW opslaan en meer dan een USB2.0 verbinding hebben? (correct me if I'm wrong)

[MAX3400]

ZaPPZion schreef op dinsdag 8 augustus 2017 @ 19:11:
Als je gewoon 200MB/s haalt, lijkt me dat het meer zit in de aansluiting van camera naar PC? USB 2.0 is 480MBit/s = 60MB/s. Ik ken zo uit mijn hoofd geen camera's die RAW opslaan en meer dan een USB2.0 verbinding hebben? (correct me if I'm wrong)

You're wrong. Waar lees jij 200MB/s ? Hoe weet jij de layout van elke sector van elke disk? Hoe bereken jij, achter jouw PC, hoeveel IOPS de current array aan kan?

Sterker nog; die benchmark is de optimale snelheid op dat moment. Dat kan zomaar 10% lager zijn als er morgen 6 grote bestanden zijn weggehaald of bijgeschreven op de array.

[ZaPPZion]

MAX3400 schreef op dinsdag 8 augustus 2017 @ 19:16:
[...]
Waar lees jij 200MB/s?

In de benchmark is de sequential rond de 270MB/s. Ik ga even uit van sequential, aangezien RAW bestanden vaak 10+MB zijn, dus niet echt in de buurt van 4K files. Bij 4K files worden er al 1000+ IOPS gehaald volgens de benchmarks (4000+KB/s / 4KB files = 1000), dus dat lijkt me niet het probleem. Stel dat we uit gaan van 10MB RAW bestanden (meestal zijn ze een stuk groter, maar goed, even worst-case voor IOPS), kun je op een USB2.0 verbinding er maar 6 per seconde door drukken. Dat is toch een veel grotere bottle-neck dan de 1000 IOPS (benchmark 4K) of de doorvoersnelheid seq (270MB/s)?
Volgens de IOPS zou je er vele malen meer moeten kunnen halen.
Volgens de Seq test zou je toch ook wel 10 fotos per seconde moeten kunnen halen (als een foto 27MB is, geen idee welke camera je gebruikt).
Al met al is de conclusie dat USB2.0 een bottleneck zou zijn nog niet zo gek lijkt me? Het enige wat een foute aanname van mij zou kunnen zijn, is dat de camera USB2.0 is aangesloten, dat weet ik namelijk niet.

[MAX3400]

ZaPPZion schreef op dinsdag 8 augustus 2017 @ 19:35:
[...]

In de benchmark is de sequential rond de 270MB/s. Ik ga even uit van sequential

Tja, we kunnen praten als Brugman (beiden) maar zolang topicstart niet reageert, weten we niks.

Sowieso is een RAID0 absoluut niet sequential, niet in de laatste plaats dat elk 4e block van een file per disk wordt weggeschreven; nog even afgezien op welke platter. Voor disks met 6 platters, heb je dus (24 ² * (number of sectors)) mogelijkheden waar de eerste 8 blocks zijn opgeslagen. No way dat dit ooit nog een sequential read of write in het vervolg oplevert.

[ZaPPZion]

In de vraagstelling gaat het volgens mij om het sequentieel wegschrijven van de foto's
Bovendien, ik snap dat RAID0 niet sequential is, maar deze benchmarks vragen toch aan de controller om data uit te lezen? Als het dan verspreid zou staan, geeft de benchmark toch ook wel een lagere score? Of zie ik dat verkeerd omdat de data eerst 'netjes' wordt neergezet om het vervolgens uit te lezen?

[MAX3400]

ZaPPZion schreef op dinsdag 8 augustus 2017 @ 22:20:
In de vraagstelling gaat het volgens mij om het sequentieel wegschrijven van de foto's
Bovendien, ik snap dat RAID0 niet sequential is, maar deze benchmarks vragen toch aan de controller om data uit te lezen? Als het dan verspreid zou staan, geeft de benchmark toch ook wel een lagere score? Of zie ik dat verkeerd omdat de data eerst 'netjes' wordt neergezet om het vervolgens uit te lezen?

Ik denk dat je ongeveer in de richting zit maar dan precies 180 graden gedraaid. Topicstarter wil data schrijven naar een 4-disk RAID0 array. In de benchmark van Crystaldiskmark, moet je dus de WRITE waarden pakken en niet de READ waarden en dan komt de benchmark op maximaal 5MB/s. Omdat je 4 disks hebt, moet je 4 keer I/O (read OF write) voorbereiden, dan access-time meerekenen per write per disk, dan de tijd dat een head iets gaat lezen OF schrijven, dan de "acknowledge" en dan de volgende aktie.

Stom gezegd, heel basaal: als je 1MB wil wegschrijven in 256K blocks op 1 disk, moet je in totaal 4 I/O akties uitvoeren en maar 1x de access-times en 4x de heads-movement meenemen in je berekening. Wil je die ene MB op 4 disks wegschrijven, kan het toevallig zo zijn dat alle 4 de disks na elkaar elk 256KB gaan schrijven. Dus je hebt in essentie 4x access-time, 4x head-movement etc. Laten we even aannemen dat accesstime en write-time hetzelfde zijn en in dit geval wordt je totale transfer-speed (write) nog maar een kwart. Dus ipv van de benchmark van 5MB/s, kan het zo zijn dat je 1.25MB/s maar haalt.

Terug naar de vraagstelling: als de stripe-set geconfigureerd is op een lage/kleine chunksize, zoals 8KB, moet je om een file van 1GB weg te schrijven, dus 32768 write akties per disk uithalen. Heb je een chunk van 512KB (indien de controller dat ondersteunt), hou je nog maar 256 write akties per disk over. Denk dat ik niet hoeft te vertellen dat 256 writes minder tijd kosten (aanname!!!) dan 32768 writes. Als elke write even lang duurt (incl. alle randfactoren van de disks), zou je die ene GB in 1 seconde of in dik 2 minuten wegschrijven (factor 128 in handelingen), alleen al door de chunks correct te zetten.

In a nutshell: disks & controller moet je goed op elkaar afstemmen.

Daarna komt dan nog eens het OS, of daar caching etc. in de OS mogelijk is, of er andere zaken zijn uitgeschakeld zoals write-back caching, NCQ, power-states etc. etc. etc.

TL;DR? Topicstarter zal met de billen bloot moeten; elk klein minkukeling vinkje en metinkje alsmede de hele opstelling inzichtelijk moeten maken. Ik ben, vooralsnog, niet onder de indruk dat RAID0 voor het vraagstuk correct geimplementeerd is op alle vlakken.

[ Voor 7% gewijzigd door MAX3400 op 08-08-2017 22:51 ]

[MewBie]

ZaPPZion schreef op dinsdag 8 augustus 2017 @ 22:20:
In de vraagstelling gaat het volgens mij om het sequentieel wegschrijven van de foto's
Bovendien, ik snap dat RAID0 niet sequential is, maar deze benchmarks vragen toch aan de controller om data uit te lezen? Als het dan verspreid zou staan, geeft de benchmark toch ook wel een lagere score? Of zie ik dat verkeerd omdat de data eerst 'netjes' wordt neergezet om het vervolgens uit te lezen?

Als het om foto's gaat maakt de TS dus gebruik van tethering wat van zichzelf al een zooi factoren heeft die de snelheid beperken. Als bij tethering de schrijfsnelheid een probleem is doe je iets verkeerd. Tethering is niet bedoeld om op hoge snelheid een heleboel foto's achter elkaar te maken.

[johnkeates]

Een enkele SSD is al sneller dan dit...
Stel dat je veel ruimte nodig hebt, dan kan je de SSD als cache gebruiken, en dan nog steeds data naar de RAID overzetten. Zo'n RAID is natuurlijk verschrikkelijk onveilig, een disk stuk, 16TB data onbruikbaar.

De volgende stap zou misschien eerder een ZFS array zijn en dan via iSCSI op een 10GbE verbinding beschikbaar stellen, of een Infiniband setje ofzo. Of, als er geld over is maar niet genoeg voor zo'n array, een PCIe SSD.

[ Voor 3% gewijzigd door johnkeates op 09-08-2017 01:26 ]

[TommyboyNL]

johnkeates schreef op woensdag 9 augustus 2017 @ 01:26:
Zo'n RAID is natuurlijk verschrikkelijk onveilig, een disk stuk, 16TB data onbruikbaar.

Daar heeft TS natuurlijk gewoon goede backups voor ingeregeld...