[Kaufberatung] Setup um Messdaten mit ~ 250 MB/s zu speichern

OwenBurnett

Enthusiast
Thread Starter
Mitglied seit
26.10.2007
Beiträge
883
Ort
Wien
Hi,

Ich stelle ein System zusammen mit dem ich Messdaten mit 250MB/s auf ein RAID Array speichern kann.

Ich habe mir überlegt das 2 SAS HDD's im RAID 0 dafür ausreichend sein sollten, mit einem echtem Raid Controller PCIe x8, oder was meint ihr?
Wären 4 HDD's doch besser?
Oder doch 2 SSDs? Die neuen SLC von intel schaffen 170 MB/s das stück.

Die Messdaten kommen von einer 64bit PCIx 66 MHz karte.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
das kommt erstmal darauf an wieviel platz du brauchst.

ich würde mir einen ordentlichen pcie-raid-controller mit 4x mtron mobi 3500 deiner wahl besorgen und sie in einem RAID-0 betreiben.
und wenn du garantierte performance brauchst sind SLC SSDs unbedingt zu empfehlen.
 
Ay Caramba! Wie lange am Stueck muss das denn durchhalten? Wenns nicht zu lang ist, waers evtl sinnvoll das zuerst auf ne grosse RAMdisk zu speichern und dann von dort abzulegen...
 
Voraussichtlich werden es 10 Sekunden an Messdaten also 2,5 GB, es wäre aber auch sinnvoll sich die Option längerer Messungen offen zu halten, 60 Sekunden 15 GB.

Für die Karte sind leider nur 32 bit Treiber verfügbar da wird also nichts mit einem 64 bit OS und ein 32bit Server OS mit PAE kostet leider auch nicht gerade wenig.

Eine RamDisk habe ich auch in betracht gezogen, jedoch müsste da eben ein Server OS herhalten, und bei manchen Ramdisks habe ich auch die Erfahrung gemacht das sie recht viel CPU last verursachen bzw nicht wirklich die Performance erreichen (schlampig programmiert halt)

Vielleicht wäre ein iRAM oder wie das heißt ne Option.

Die Daten kannman später dann auf eine langsame festplatte 2 TB Seagate oder so verschieben.

Zum Kontroller habe ich an einen Adaptek gedacht: http://geizhals.at/a338634.html denke nicht das mehr Cache da Hilft bei RAID 0, und der IOP wird wohl auch nicht all zu viel zutun haben.
SSDs wie wäre es mit 2 von den hier: http://geizhals.at/a365723.html
 
darfst du hier schreiben, um was für eine Karte es sich handelt? Ich habe auch des öfteren mit verschiedenen Datenerfassungskarten zu tun. 250 MB/s ist echt ne dicke Nummer, welche karte schafft das?
 
@Tyler Durden
Es ist eine 8-bit Digitizer karte von Acqiris mit 2 Giga Samples für einen cPCI Tray wo dann eine 2te Adapter karte drin steckt die die Daten an einen PC mit PCIx weiterleitet, leider hatten die keine native PCIx Variante im Angebot, die Standard Variante wäre mit einem MiniPC in karten form, der hat aber nur 1 GB Ram und eine kleine Notebook IDE platte.

@Schlingel_INV
Hmm.... jo so ein mit bis zu 4 GB extra Cache sehe ich da grade, das wäre uU. sehr interessant.
 
Zuletzt bearbeitet:
Die frage ist halt auch wie groß dein Budget ist und ob es ein sequentieller Datenstrom ist ? So ist der Vorschlag wie sirphoenox ihn hat ja ne gute Lösung. Beispiel 3 oder 4 16GB Mobi 3500 mit je 100MB/s write. Stück 99€. Dazu ein guter Controller. Wobei auch aktuelle Onboard Lösungen real 300MB/s write schaffen sollten.
 
Zuletzt bearbeitet:
Budget, naja was immer nötig ist, im vergleich zu der Karte wird der PC wohl e'h nicht so teuer ;)
 
Und die Frage ob die Daten in einem sequentiellen Strom anfallen als eine Datei, es also nicht so sehr auf Iops beim schreiben ankommt (Mtron Mobi) oder viele kleine Dateien anfallen wäre noch zu beachten. Wann wären die Intel X25-E besser aber auch teurer.
 
Die Daten kommen sequentiell von der karte und so werden sie auch gespeichert, eine Nachbearbeitung wird erst später vorgenommen wo man den mehr oder weniger beliebig viel zeit hat, es werden einpaar Messungen gemacht in moderaten Zeit Abständen und dann pause bis zum nächstem Experiment.

Voraussichtlich wird es nötig sein ein eigenes Programm für das speichern zu schreiben, da kannman dan noch mit einem eigenem Cache herum optimieren, halt immer ganze Stirpes schreiben und so.
 
Mit der X25-E wäre ich bei so einer kritischen Anwendung wegen dem 80%-Bug eher vorsichtig, oder betrifft der nur random writes?
 
ioDrive von Fusio-IO ;)
Dürfte für deine Aufgabe ideal sein ... kostet aber auch und die Verfügbarkeit kann ich auch nicht garantieren.

Ansonsten: vernünftiger Raidcontroller + 4 MTrons

Wobei es von Transcend auch ne 64 GB SLC SSD gibt die mit fast 150 MB/s schreibt, davon wären vllt. zwei schon ausreichend. Für so nen 10 Sekunden Datenstrom kann vllt. auch nen guter Controller mit ausreichend Cache passabel zwischenspeichern, welchen er dann in ruhe auf eine HDD schreiben kann.
 
Macht ihn doch nicht verrückt und lest mal seine Anforderungen. Transcend SLC fällt aus da dort auch der JMF602 verbaut sein sollte und da er ja maximal mit 15GB anfallenden Volumen zu tun hat, warum dann 2x64GB ? Und bei 2 Intel X25-E und Gesamt 64GB sind auch mehr als genug Platz, somit auch kein 80% Thema. ioDrive, hier fast nicht zu bekommen und für das anliegende zu overpowered. Warum extreme IOPS Leistung wenn nur sequentiell gefragt ?

Bleibt eigentlich die Mtron Sache übrig. Zumindest im SSD Sektor.
 
Zuletzt bearbeitet:
@DaReal
ioDrive von Fusio-IO ist so ziemlich die geilste Lösung das muss ich zugeben, für unsere zwecke fast Overkill und die SSD Raid Lösung kostet wohl nur 1/3 des ioDrive und erfüllt unsere zwecke, alles über 300 mb/s ist purer Luxus, da die Interface karte zwischen dem Tray und dem PCIx Slot am PC nur max 250 MB/s schaft laut Acqiris.

@DSL Cowboy
Was ist der Intel 80% bug?

@TheSane
Die Systeme von Acqiris masieren auf einem "Kard PC" der in den Tray geschoben wird der hat aber nur 1 (oder 2 ?) GB fest aufgelöteten RAM und eine Notebook HDD, die können diese Datenmengen nicht abspeichern, die könnten im RAM mitteln oder irgendwas anderes einfaches mit machen aber auch nicht zuviel ist nur ne Pentium M CPU drin.
Wir möchten da ein eigenes uU. etwas anspruchsvolleres MatLab Programm drüber laufen lassen und uU. das noch mit Daten von anderen quellen verknüpfen.
 
Die Intel SSDs haben keinen Bug aber eine Eigenart. Wenn der Speicherplatzverbrauch unter 20% sink, sinkt die Leistung. Wäre bei 2x32GB (real 59.xGB) also wenn voller als 47.x GB. Solltest du darunter bleiben ist das kein Thema.
Da aber nur sequentielles Schreiben anliegt wären auch die Intel im Prinzip overpowered und die Mtron Mobi 3500 Serie ausreichend.
 
Zuletzt bearbeitet:
Voraussichtlich wird es nötig sein ein eigenes Programm für das speichern zu schreiben, da kannman dan noch mit einem eigenem Cache herum optimieren, halt immer ganze Stirpes schreiben und so.
Vlt eher mal über Kompression Gedanken machen? Oder ob die reinkommenden Werte tatsächlich echte 64 bit Auflösung haben oder ob der datenlieferende Sensor vlt gar nicht so genau ist? Oder werden die Messwerte bereits vorkomprimiert geliefert?
 
@DaReal
ioDrive von Fusio-IO ist so ziemlich die geilste Lösung das muss ich zugeben, für unsere zwecke fast Overkill und die SSD Raid Lösung kostet wohl nur 1/3 des ioDrive und erfüllt unsere zwecke, alles über 300 mb/s ist purer Luxus, da die Interface karte zwischen dem Tray und dem PCIx Slot am PC nur max 250 MB/s schaft laut Acqiris.

Iodrive hat auch das/die 80% bug/eigenart

Die Daten kommen sequentiell von der karte und so werden sie auch gespeichert, eine Nachbearbeitung wird erst später vorgenommen wo man den mehr oder weniger beliebig viel zeit hat, es werden einpaar Messungen gemacht in moderaten Zeit Abständen und dann pause bis zum nächstem Experiment.

Voraussichtlich wird es nötig sein ein eigenes Programm für das speichern zu schreiben, da kannman dan noch mit einem eigenem Cache herum optimieren, halt immer ganze Stirpes schreiben und so.

@OwenBurnett

Acard 9010/Hyperdrive 5 .. den Rest würde ich nicht einsetzen .. alles zu lahm beim Schreiben

Diese Pattern sagen alles in deinem spezifischen Fall : http://techreport.com/articles.x/16255/9
 
Zuletzt bearbeitet:
Vlt eher mal über Kompression Gedanken machen? Oder ob die reinkommenden Werte tatsächlich echte 64 bit Auflösung haben oder ob der datenlieferende Sensor vlt gar nicht so genau ist? Oder werden die Messwerte bereits vorkomprimiert geliefert?

Die 64 Bit des Busses haben nichts mit den Daten zu tun.
Wobei bei 8 Bit und 2 GS/s ... wofür braucht man sowas? Damit kannst ja schon Signale bis 200 MHz astrein samplen, effektiv vllt. sogar bis 500 MHz.

Theoretisch wäre es sogar ein Datenstrom von bis zu 2 GB/s.
8 Bit -> 1 Byte
2 GS/s -> 2 GB/s

Iodrive hat auch das 80% bug/eigenart

Ja, habe ich gestern auch gesehn ... beim ioDrive scheint das wohl sogar nicht nur durch die 80% zu sein sondern allgemein durch Datentransfer, und das ioDrive bricht dann weitaus mehr ein als eine Intel-SSD. Schon sehr traurig, vor allem bei dem was die Dinger kosten.

Beiträge zusammengeführt, da Antwort auf eigenen Beitrag innerhalb von 4 Stunden:

Diese Pattern sagen alles in deinem spezifischen Fall : http://techreport.com/articles.x/16255/9

Die sagen gar nichts in seinem Fall aus ... die Daten kommen in einem gleichmäßigen Strom, nicht über 1000 parallele.

Wobei ne Acard auch eine gute Lösung wäre, iRAM kommt ja wegen der Beschränkung auf SATA-I leider nicht in frage, maximal zwei im RAID.
 
Nachbearbeitung und Abspeichern bedeuten nicht das gleiche für mich
 
Da steht "nachher", das heißt für mich, nachdem die Messwerte aufgenommen wurden bzw. es sagt nicht eindeutig aus, ob an dem System dann auch die Auswertung stattfindet. Wobei, wenn er schreibt, dass mehrere Messungen mit kleinen Abständen gemacht werden, dann wird die Auswertung sicher auf einem anderen System geschehen.
 
@picoflop
Ich denke nicht das Kompression bei diesen Datenraten eine Option ist, außer ich würde vielleicht die CPU mit flüssig He kühlen und auf 12 GHz oder sowas übertakten, nur da hätte ich gewisse bedenken wägen der Zuverlässigkeit von sowas ;)

@DaReal
Es ist es eine Messreihe von einpaar tausend Messungen ganz knapp nach einander.
Wir erhalten einen Trigger puls alle par ms nach dem wir immer eine Million Samples Aufnehmen und danach auf den nächsten warten, die Karte brauch natürlich entsprächen onboard Cache (1 Mega Sample) damit sich das mit der 250 MB/s Datenrate ausgeht.

@AristoChat
Wen die Nachbearbeitung etwas zeit dauert ist es kein Problem, zudem wird da wohl der CPU Lastige teil zum Flaschenhals, die Ergebnisse kann man dann auf ein anderes Laufwerk schreiben da fallen viel viel weniger Daten an.

Ob wir das jetzt auf dem selben Rechner oder auf einem anderen auswerten werden wir dann später sehen abhängig davon wie lange die Berechnungen dauern werden.
Das ganze ist dann aber nicht mehr zeitkritisch oder so wir können uns aussuchen in welchen zeit Abständen wir die Messreihen machen.
 
Zuletzt bearbeitet:
Naja, aber sowas sollte man schon im voraus wissen. Denn so entscheidet sich ja ob der rest auch "overkill" sein muss oder ob ein Office-PC genügt ;)
 
Ich denke nicht das Kompression bei diesen Datenraten eine Option ist
Ich red ja nicht von GZip, RAR etc, sondern von irgendwas einfachem und insbesondere etwas das genau zu den Werten passt.
Wenn du viele gleiche Werte hintereinander bekommst, würde ein einfaches RLE ausreichen und das frisst kein Brot. Wenn du stattdessen Werte bekommst, die sich immer nur um wenig vom Vorgänger-Wert unterscheiden, speicherst du halt ab und zu einen Basis-Wert und dann nur noch das Delta.
"Normale" Kompressionsverfahren sind gut, wenn es letztlich nicht bekannt ist, wie die Daten statistisch verteilt sind. Da du aber darüber ja Informationen hast (oder vermutlich beschaffen kannst), würde sich ein angepasstes Kompressionsverfahren anbieten.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh