Hallo! Passend zum PentiumD-Thread, hier noch eine andere Computer-Frage: Ich möchte mir ein neues System bauen und würde gerne ein möglichst schnelles und möglichst sicheres RAID-System für S-ATA(II)-Festplatten einrichten. Nun dachte ich die ganze Zeit, daß eine RAID5-Konfiguration am elegantesten sein würde. Meine kürzlichen Recherchen haben allerdings ergeben, daß ein RAID5-System wohl etwas langsam im Schreibe-Modus ist. Nun wäre also ein RAID01 oder ein RAID10-System der naheliegende Kompromiss. Hat jemand von Euch eine RAID-Konfiguration dieser Art in Betrieb und kann etwas zur Stabilität und zum Geschwindigkeitszuwachs sagen? Die native DAW mit Cubase SX als Software sollte - rein vom HD-Recording her - mindestens so viel Performance haben wie ein älteres Pro Tools Mix-System mit seinen 64 Audio-Spuren. Prozessor, Arbeitsspeicher, Datendurchsatz und Software sollten eigentlich dazu in der Lage sein, nur bei den Festplatten bin ich mir nicht so sicher. Daher denke ich, daß ein RAID-System meine Rettung sein könnte. Vielen Dank im Voraus & viele Grüße! Michael
PS: Das System im Detail wird ungefähr so aussehen: Pentium D Prozessor 2-4 GB RAM Asus P5WD2 (Premium) Mainboard 4 Samsung S-ATA(II) Festplatten für Audio-Raid Systemplatte extra Audio-Hardware: RME Digiface Audio-Software: Cubase SX
also mein EDV Techniker meint immer, er habe noch kein SATA oder ATA Raid gesehen, dass wirklich schneller war als eine Einzelfestplatte, genausowenig bei SCSI-Systemen der letzten Generation. Seiner Meinung nach stammt der vielzitierte Geschwindigkeitsgewinn noch aus Zeiten wo die Plattengeschwindigkeit und der Festplatten-bis-Controller-Bus die Flaschenhälse darstellten - inzwischen ist es ihm zu folge aber so, dass die Platten und auch der anschließende Bus so viel Leistung bringen, das andere limitierende Faktoren wie PCI Bandbreite eher zu tragen kommen als die Geschwindigkeit der Platte und des Interfaces. Georg
P.S: Wenn schon RAID, dann unbedingt mit einem hochwertigen Controller mit eingebautem Prozessor zur RAID Steuerung. Die derzeit erhältlichen "günstigen" Controller lagern die Koordination des Raids oft an die CPU aus, was dazu führt dass das RAID deutlich langsamer ist als eine "normale" Festplatte.
Hallo, Von wegen passive RAIDs sind schlecht! dann schau er sich mal an was ein "etwas älterer" Celsius M (noch Serie mit Intel 925er Chipsatz) von Siemens so schafft: [DRIVE D:\] DriveType = Harddisk BusType = ATA VendorId = Intel ProductId = Raid 0 Volume Revision = 0.1. FreeBytes = 115 GB TotalBytes = 465 GB FileSystem = NTFS MaxPathLen = 255 VolumeName = Volume VolumeSerial = F076 - C666 TestFileSize = 786.432 KByte ReadSpeed = 103.138 KByte/s WriteSpeed = 104.634 KByte/s PrepareSpeed = 98.107 KByte/s RandomSearch = 20,422 ms LockDrive = Success und das ganze auf dem selben System als Einzelplatte: [DRIVE E:\] DriveType = Harddisk BusType = ATA VendorId = WDC WD25 ProductId = 00JD-55HBB0 Revision = 08.0 FreeBytes = 127 GB TotalBytes = 232 GB FileSystem = NTFS MaxPathLen = 255 VolumeName = Volume VolumeSerial = 441B - ADDC TestFileSize = 476.160 KByte ReadSpeed = 52.906 KByte/s WriteSpeed = 53.561 KByte/s PrepareSpeed = 51.046 KByte/s RandomSearch = 20,639 ms LockDrive = Success Das sind so typische Werte.... RAID0 ist schlicht und ergreifend doppelt so "schnell" (Der Durchsatz ist höher) als eine baugleiche Einzelplatte. Es ist total wurscht, ob es ein aktiver RAID controller ist, oder mit XP gemacht wird, zumindest bei RAID 0 oder 1 und ICHR oder Nforce Chipsatz (Intel/NVidia) Wenn es was Aktives sein soll, dann auf keinen Fall eine PCI Lösung, denn ein normaler PCI Bus steckt das gar nicht weg. Die OnChip Lösung ist über ICH7R angebunden, ohne den PCI Bus auszubremsen. Ähnliches gibt es auf jedem Nforce4 Board mit Athlon64. Für 64 Spuren reicht übrigens eine Einzelplatte. Ab ca. 110 Spuren würde ich ein RAID empfehlen. Gerne auch ein Fibrechannel SAN, aber nur wenn die Firbrechannel Karte über PCI-E oder PCI-X angebunden ist.
Hallo Tonzauberer! Vielen Dank für die Einschätzung! Tja, ein Bekannter von mir fährt seine Pro Tools Sessions komplett von externen Firewire(400)-Platten. Wobei Tonmaus ja eine ganz andere Meinung hat als der von Dir zitierte Techniker. Hmmm ... ich werde mal auf weitere Antworten warten. Vielen Dank nochmal & viele Grüße! Michael
ich würde ja wenn schon denn schon PCIe raid controller bevorzugen wegen durchsatz und so. noch was: ist cubase sx dual core optimiert? samplitude ist es (noch) nicht unbedingt... das mit den dual cores ist auch in den benchmarks äußerst interessant: http://www.de.tomshardware.com/cpu/charts/index.html?model1=203&model2=200&chart=57 ich hoffe ich tratsche kein all zu altes eisen... grüsse leif
Hallo, Habe vor längerer Zeit in einem "Multifunktionsrechner" (keine reine DAW) Splitting laufen gehabt, mit 2xWD800JB an 2 IDE-Strängen, es war bei mir in keinster Weise "spürbar" schneller (gemessen hab ich nicht). Und Raid5 (mit 4 Drives) ist theoretisch durchaus langsamer als eine einzelne Platte (der Controller muss mindestens warten, bis 3 der 4 Platten die Daten geliefert haben, und beim Schreiben auf alle 4). PCI wird u.A. auch ein Bottleneck gewesen sein... Aber mit einem vernünftigen System, so wie es die Vor-Poster erwähnt haben, gibt sicher kein Problem mit den Datenflüssen im Rechner. Ein bei mir entscheidende Faktor (Grössenordnung 2) war aber Block/Buffer-Grösse beim Aufnehmen und die Block-Grösse des Filesystems (und auch welches Filesystem, bei mir war FAT32 am schnellsten, man glaubt es kaum!). Da kann man wohl tagelang herumprobieren, leider, bis man die optimalen Grössen für ein bestimmtes Setup gefunden hat. Jedoch in __allererster Linie__ der Effekt, unbedingt die Datein so zerstückelt auf der Platte liegen zu lassen wie sie beim Tracken anfallen (wenn man denn gleich Dutzende Spuren auf einmal aufnimmt). Der worst-case trat dann auf, wenn man die Spuren als Dateien quasi einzeln hintereinander auf die Platte legt; das passiert wenn man sie von einem anderen Medium (Netzwerk, DVD, andere Platte/Backup, etc) rüberkopiert oder ein Defrag macht, und das Problem wächst mit der Grösse/Länge der Spuren (z.B. ein komplettes Band am Stück von der BaMa). In dem Fall seekt sich die Platte(n) schnell zu Tode, da hilft auch kaum ein Cache oder schlaue Optimierungalgorithmen im OS oder Controller etc, wegen der grossen Datenmengen, die ausserdem ziemlich linear anfallen (ganz anders als beim Server-Betrieb). Bis man die lineare Übertragungsrate einer Platte ausreizt, dauert es schon eine Weile... bei z.B. 50Mb/s reicht das theoretisch für z.B. 130 Spuren in 32bit/96kHz, und sagen wir dass etwa die Hälfte davon nach Abzug des Overheads noch übrigbleibt. Von daher teile ich die Einschätzung, dass 64 Spuren mit einer Platte locker zu packen sind, wenn die Daten nicht zu zerstückelt abgeholt werden müssen. Mit massivem Splitting (z.B. 4x) kann man das Seek-Aufkommen deutlich verbessern und die Dauertransferrate ebenso. Grüsse, Klaus
"ich würde ja wenn schon denn schon PCIe raid controller bevorzugen wegen durchsatz und so." Schneller als IHCR oder Nforce ist PCI-E nie und nimmer. Bei Nforce ist die CPU Last übrigens besonders niedrig. Wenn man echte RAID-Intelligenz wünscht, braucht man aber einen aktiven Controller, denn die Berechnung von Checksummen muss ja irgendwo passieren. RAID 10 habe ich noch nicht probiert. Ist ja auch ein "dummes" RAID. RAID 5 schon, (Stripe+Mirror+Parity) und es ist bei vielen Platten durchaus einigemaßen schnell, schnell genug zumindest. (Wir stehen ja hier nicht gemächtstarrend an der Pinkelrinne, sondern wollen Aufnahmen machen, oder?). Am meisten haben mich bisher die Systeme von Netapp beeindruckt, vor allem deren Double Parity Technologie. Aber so was kostet auch. Was solls: Wem die erhältlichen Platten zu klein und zu langsam sind, der nehme RAID0, wenn er mit dem mit der E-Funktion wachsenden Risiko des Palttenausfalls leben kann, wer Sicherheit braucht, nehme ein RAID5 NAS über LAN oder Fibrechannel, weil das noch bezahlbar ist, so weit mein Rat. RAID 1 ist einfach nur uneffektiv. 2mal Aufnehmen kann jeder. Das Festplattenausfallrisiko ist ja nicht das schwächste Glied in der Kette. Warum sollte man so was dann tun? Grüße, Tonmaus
"Der worst-case trat dann auf, wenn man die Spuren als Dateien quasi einzeln hintereinander auf die Platte legt; das passiert wenn man sie von einem anderen Medium (Netzwerk, DVD, andere Platte/Backup, etc) rüberkopiert oder ein Defrag macht, und das Problem wächst mit der Grösse/Länge der Spuren (z.B. ein komplettes Band am Stück von der BaMa). In dem Fall seekt sich die Platte(n) schnell zu Tode, da hilft auch kaum ein Cache oder schlaue Optimierungalgorithmen im OS oder Controller etc, wegen der grossen Datenmengen, die ausserdem ziemlich linear anfallen (ganz anders als beim Server-Betrieb)." Genau dieses Worst-Case Szenario belibt allerdings auf intelleigenten RAIDs aus, zum Teil da der Begriff "Fragementierung" auf ein RAID nicht übertragbar ist (wie soll das Sinn machen bei Parityplatten?) zum Teil, weil üblicherweise Chaches bis in den Gigbytebereich möglich sind, die so was abfangen. Schon bei einem low-cost Raid5 NAS konnte man in meinen Tests keine Unterhschiede mehr feststellen, ob am Anfang oder am Ende der Platten geschrieben wurde. Die Durchsätze waren quasi Strich, was recht vorteilhaft ist. (Aber eben mit 30MB/s über LAN auch nicht wahnsinnig hoch....) Grüße, Tonmaus
"noch was: ist cubase sx dual core optimiert? " Ja! Zumindest sagt das Steinberg: "Additional Processor Optimization: support for DualCore and Multi-Processor PC systems (systems with more than two processors)" Im Forum steht auch was, von wegen Audio-Engines der VSTis auf beide Prozessoren verteilen usw. Genauere Details habe ich leider noch nicht finden können. Viele Grüße! Michael
Hallo Tonmaus, Hhm, ich dachte RAID5 ist eben gerade nicht "Stripe+Mirror+Parity" mit einzelner Parity-Platte (oder habe ich da missverstanden?), sondern gestripte Daten + Parity ständig umverteilt auf alle Platten? Das sagen auch die Grafiken auf http://www.acnc.com/04_01_05.html und Umgebung. Zur Seek-Geschichte: Bin bei aktuellen Profi-Controllern nicht up-to-date, es kann also schon sein dass neuere die Daten so umverteilen (auf die Gesamtkapazität), dass die mittlere Seekzeit und Datenrate zwar langsamer als die bestmögliche wird, dafür aber stabil bleibt. Ich habe seinerzeit mal für MS-DOS einen Plattentreiber-Rucksack geschreiben, der genau sowas machte (für eine Echtzeit-Industrie-Anwendung), damit man sich darauf verlassen konnte dass die Daten mit konstanten X Mb/s resultierend ankommen, völlig egal wie stark die Daten auch über Jahre fragmentiert werden oder wo sie auf der Platte (satte 40MB gross ;-) zu liegen kommen. Dazu hatte ich die Datenblöcke in 4kB-Happen wahlfrei (per Hashtable aus einem Pseudozufallsgenerator) auf die Platte verteilt, und es hat super funkioniert, die Datenrate war zwar nur etwa 1/8 der maximalen, aber konstant, über mehrere Jahre hinweg). Wenn die Controller die Daten aber sukzessive auf die Platten schreiben, bzw. an die Orte, die das Low-Level-Filesystem vorgibt, müsste es aber schon eine Rolle beim Seeken spielen, ob z.B. 16 Spuren a 500MB hintereinenander aufgespielt wurden oder in 64kB-Blöcken verschachtelt. Wenn die DAW-Software einen 64kB-Block der nächsten Spur anfordert, muss im zweiten Fall gar nicht geseekt werden, im ersten Fall aber jedesmal 125Mb weit (jetzt mal reines 4x-Striping angenommen). Wenn die Zugriffe vom OS/Controller sortiert und gebündelt werden, dann nicht jedesmal aber immer noch oft genug. Für das Beispiel bräuchte man dann auch 8GB Cache, damit nach einem Durchlauf noch alles im Cache ist. Naja, egal.... Interessant wäre natürlich, wenn jemand genaue Messungen dazu (mit RAID5) hat oder welche machen will, denn ich theoretisiere hier bloss (man verzeihe). Grüsse, Klaus S
"hm, ich dachte RAID5 ist eben gerade nicht "Stripe+Mirror+Parity" mit einzelner Parity-Platte (oder habe ich da missverstanden?), sondern gestripte Daten + Parity ständig umverteilt auf alle Platten?" Mirror ist Blödsinn, stimmt. Da habe ich mch quasi vertippt und man kann hier nicht editieren... Für die Parity gibt es aber unterschiedliche Ansätze, entweder dynamisch verteilt, oder auf eine feste Parity-Platte. Letzteres dürfte aber auf 3 Platten beschränkt sein und die simple-dödel Lösung, eher "RAID4,5". Die dynamische Lösung ist viel interessanter, und daher sind auch 5er Raids sehr wesentlich abhängig von der Plattenzahl, so lange die CPU noch mit dem Berechnen der Parity hinterherkommt.
"Wenn die Controller die Daten aber sukzessive auf die Platten schreiben, bzw. an die Orte, die das Low-Level-Filesystem vorgibt, müsste es aber schon eine Rolle beim Seeken spielen, ob z.B. 16 Spuren a 500MB hintereinenander aufgespielt wurden oder in 64kB-Blöcken verschachtelt. Wenn die DAW-Software einen 64kB-Block der nächsten Spur anfordert, muss im zweiten Fall gar nicht geseekt werden, im ersten Fall aber jedesmal 125Mb weit (jetzt mal reines 4x-Striping angenommen). Wenn die Zugriffe vom OS/Controller sortiert und gebündelt werden, dann nicht jedesmal aber immer noch oft genug. Für das Beispiel bräuchte man dann auch 8GB Cache, damit nach einem Durchlauf noch alles im Cache ist." ... und einen Zugriff, der genau auf den konstruierten Fall passt :-). So ist es wohl kaum. Es spielen mehrere Faktoren eine Rolle. Ein recht entscheidender dürfte sein, dass ich über LAN gemessen habe, und es mir nicht gelungen ist aus einem Windows Share mehr als 30MB Strich zu ziehen, egal was dahinter hing. Da scheint was am Windows TCP/IP Stack einen Flaschenhals zu bilden. Ich habe auch etliche Benchmarks anderer Systeme die von namhaften Systemhäusern eingerichtet wurden. Keines brachte über TCP/IP mehr. Ob ich da überhaupt noch an die anderen Flaschenhälse gekommen wäre.... ? Ab 5000.- konnte man vo einem Jahr so was mit 2-3TByte bekommen. (Irgend ein Barebone als Subsystem, Linuxderivat, Netzwerkkarte, Controllerkarte, Platten). Das finde ich preislich und leistungsmäßig ok. Über was schnelleres (Fibrechannel) habe ich bisher nur mal ein Netapp Shelf gesehen, und das konnte ich gar nicht auslasten mit einem Client. Das war aber nicht Raid5 sondern RaidDP. Ansonsten müssen wir auch noch auf den Hersteller warten, der uns ein gutes Caching für den Audio-Fall (viele recht große Dateien gleizeitig) strickt. Die Standard Shelfs von HP sind für Audio völlig ungeeignet, da dort offenbar bei jedem Zugriff versucht wird die ganze Datei in den Cache zu bekommen. Das mag bei Datenbanken noch gehen, nicht aber bei 48*2GB*10Clients. Da ist nämlich 99,999999% des Caches ständig ungültig. Wert macht das mal? Ich wüsste etliche die so was bräuchten.... Grüße, Tonmaus
