SSD - wie am sinnvollsten integrieren?

[UranusEXP]

Hi,

ich plane demnächst endlich auch auf den "SSD-Zug" aufzuspringen. Nun stellt sich mir aufgrund des immer noch sehr ungünstigen Verhältnisses zwischen Preis und Speicherkapazität die Frage, wie sich eine - sagen wir 120 GB - SSD am sinnvollsten und effektivsten integrieren lässt. Es geht also darum: Wie am besten mit dem begrenzten Platz haushalten?

Ich habe folgende Anforderungen bzw. Anwendungsszenarien:

1.) 2 OS, d.h. 2x Win7 64-Bit, einmal für reine Audio-Anwendung, einmal Internet, Office, und sämtlichen Rest an Kram und Spielzeug. Derzeit läuft das Office-OS als virtuelle Maschine auf dem Audio-OS.

2.) Was Audio angeht, geht es mir v.a. um maximale Performance von Kontakt, Play & Co., Audio-Aufnahme und -Playback ist vernachlässigbar, für das Bisschen reichen die vorhandenen HDDs lockerst. Die SSD soll hier die Performance dahingehend optimieren, das ich noch mehr Samples vorladen kann und/oder mehr Stimmen abspielen kann. Da muss sich ein Kompromiss finden. Wichtig in diesem Zusammenhang: Ich möchte unbedingt den Sleep-Modus mit aktivem RAM verwenden. Ich habe 12 GB RAM (vielleicht bald 24 GB) ständig voll mit Samples, da macht Neuladen keinen Spaß, solange nicht ALLE Samples von sehr schnellen SSDs geladen werden, was mit der sehr eingeschränkten Größe noch nicht machbar ist und zweitens, selbst wenn, immer noch die unkomfortablere Option darstellt.

Es kommt nun zu folgenden Fragen:

zu 1.) Kernproblem: Möglichst wenig Platz für OS verschwenden.

Es gibt folgende Möglichkeiten: Das Audio-OS auf HDD lassen. Klingt vielleicht komisch, aber hier ist Geschwindigkeit nicht so wichtig. Bootgeschwindigkeit sowieso nicht. Wenn ich arbeite, ist Cubase und Vienna Ensemble Pro offen und sonst nichts. Die und die VST-Plugins kann ich ja trotzdem auf der SSD installieren, was ja deren Ladezeiten zumindest etwas beschleunigen dürfte, oder? (Nervig sind lediglich etwa Sachen wie die Dauer der Ladezeit des GUI von Kontakt, sind oft 10-20 Sekunden.) Wie groß wäre eigentlich der zu erwartende Unterschied, wenn das OS auch noch auf der SSD wäre? Hätte das, was die Ladezeiten von und in Cubase angeht überhaupt Vorteile? Oder würde es letztlich nur das Booten vom OS und dessen "interne" Anwendungen beschleunigen? Schnelles Booten ist hier nämlich nicht wichtig, da wie gesagt, wenn das OS erst mal oben ist, bleibt es "oben", es soll - siehe auch unten - der Sleep-Modus verwendet werden. (Wobei es da bei SSDs erhebliche Probleme geben soll. Weiß jemand Genaueres?)

Bleibt die Frage, was tun mit dem Office-OS? Physisch bootbar auf SSD oder virtuell via VM-Ware mit dem Audio-OS als Host (so habe ich das derzeit und es funktioniert gut), wobei VM-Player und die virtuellen Festplatten auf der SSD liegen würden? Bei dem OS ist mir Geschwindigkeit wichtiger, da es eh zugemüllt ist ohne Ende, ich da 1000 Sachen gleichzeitig mache und es mich wahnsinnig macht, wenn es mal 30 Sekunden dauert, bis irgendein Office-Dokument aufgeht oder nach dem Rechtsklick endlich das Kontextmenü kommt. Letztlich gleiche Frage wie oben: Hat das gegenüber einem physisch auf SSD installiertem OS großartig Einbußen? Eine virtuelle Maschine hat hier im Handling jede Menge praktische Vorteile.

Zu 2.) Kernproblem: Ich habe über ein 1,5 TB an Samples.

Natürlich wäre der erste Ansatz, die wichtigsten auf die SSD zu knallen. Allerdings sind 120 GB dafür schon recht knapp und zweitens gibt es keine so klaren Prioritäten, dass ich eindeutig sagen könnte, diese oder jene 120 GB brauche ich immer. Klar, es ließe sich ein Kompromiss finden, aber vielleicht gibt es ja eine besser Möglichkeit. Im Eastwest-Forum verwendet ein User z.B. ein Software, die die SSD als Cache nutzt (erklärt aber nicht genau, wie er sie nun verwendet):

http://www.romexsoftware.com/en-us/fancy-cache/

Wenn ich es mit meinen sehr beschränkten Kenntnissen recht verstehe, ergäbe das eine Funktionalität ähnliche einer Hybridfestplatte. Die Software würde grob gesprochen dafür sorgen, dass letztlich immer die zum aktuellen Cubase-Projekt passenden (sprich die aktuell am häufigsten verwendeten) Samples auf der SSD landen, d.h. ich kann die Samples auf den HDDs lassen. Nachteil wäre natürlich, dass die Ladezeiten der Samples gleich lang bleiben würden, wie sie jetzt schon sind und die SSD viele Schreibzugriffe erdulden müsste (wobei ich nicht weiß inwiefern das bei modernen SSDs wirklich ein Problem ist).

Ich denke viele von Euch steigen da besser durch und können mir sagen, ob ein solcher Ansatz erfolgversprechend wäre?

Auch würde mich natürlich grundsätzlich interessieren, wie ihr SSDs handhabt und welche Erfahrungen ihr damit gemacht habt.

Vielen Dank!

 

[livebox]

Uff... das Szenario ist nicht ohne

Stell dir einen Rechner als Ding vor, das aus mehreren übereinander liegenden Schichten besteht. Ganz unten ist die Hardware, ganz oben die Anwender-Software. Das OS liegt unter der Anwender-Software. Es würde also keinen Sinn machen, das OS auf eine HDD zu installieren und da großartige Geschwindigkeitsvorteile bei der Anwender-Software zu erwarten.

SSDs vs. Sleep Modus sagt mir gar nichts; SSD als "langsameren RAM" einbinden auch nicht.

Aus dem Bauch heraus würde ich sagen:
- Audio-OS auf die SSD installieren; Anwender-Software mit dort drauf
- Alltags-OS auf eine HDD neu installieren. Was für eine Virtualisierungs-Software benutzt du? Die Daten aus der VM heraus zu bekommen ist zumindest unter VirtualBox kein Problem.*
- So viele Samples wie möglich auf die SSD packen, den Rest auf eine extra Partition auf der HDD (und die immer mal wieder defragmentieren)

*Win7 ist relativ "reaktionsfreudig" im Gegensatz zu den Vorgängern. Dass die GUI so langsam reagiert, muss man echt mal erst hin bekommen. Da tippe ich auf die VM als Grund, denn so enorm kenne ich das sonst nicht von Win7. Und meine Erfahrung war bisher immer, dass ein System direkt auf der Platte deutlich performanter läuft als in einer VM. Bei allen Vorteilen einer VM - das wärs mir nicht wert.
Was den Datenumzug angeht: Ich habe in den letzten paar Jahren so viele Systeme umgezogen, dass ich schon längst aufgehört habe zu zählen. Als ich das beruflich gemacht habe haben wir dem Mitarbeiter den neuen Rechner aufgesetzt und teilw. schon eingerichtet (Office mit seinem Account bestückt und auf den Exchange-Server gemapped etc). Dann hat der Mitarbeiter die neue Maschine bekommen und die alte stand noch für 3 oder 4 Wochen (offiziell, meist war es länger) an seinem Arbeitsplatz und er konnte bei Bedarf umstecken. Danach kam die alte Maschine zu uns in die EDV, wo wir sie noch ~3 Monate vorgehalten haben. Und nicht selten musste so eine Maschine noch mal gestartet werden.

Will sagen... es macht Sinn, die alte Maschine noch lange vorzuhalten - bei einer VM ist das ja kein Problem, das irgendwo auf einer Backup-Platte zu tun wo sie nicht im Weg 'rum liegt. Die "offensichtlichen" Daten wie Office-Dokumente, Multimedia-Dateien usw sind in der Regel nicht das Problem - die findet man beim genaueren Hinschauen alle und zieht sie rüber. Oft sind es Daten, die von Programmen intern verwaltet werden - Mail-Programme, Anwendungen mit eigener kleinen Datenbank und so weiter. Grade bei Mail-Programmen wird oft vergessen, archivierte Mails mitzunehmen...
Bei so einem Umzug ist es oft sehr hilfreich wenn man sich in den Tiefen von "Dokumente und Einstellungen" (oder wie das Zeugs heut auch heißen mag) zurechtfindet und weiß, wie man das auf einem neu aufgesetzten OS einpflegen kann. (Sprich, die Anwendersoftware entsprechend hinbiegen, dass sie die alten Daten wieder frisst.) Oder man nutzt die Export/Import-Funktion von Programmen. Falls du dazu weitere Fragen hast, kannst du mich auch gern mal hinten rum kontaktieren.

MfG, livebox

P.S. Es schadet auch nicht, das Konzept eines Bootloaders verstanden zu haben - v.a. wenn man den Umzug eines OS via copy&paste einer Partition auf eine neue Festplatte machen will. Leider ist Windows da strikt proprietär, aber wenn der Rechner nach dem BIOS-Durchlauf schwarz bleibt ist noch nicht alles verloren.

 

[Banjo]

Nur ein Hinweis am Rande: unter VMWare merkt Windows nicht, dass es auf einer SSD läuft und man sollte die Defragmentierung von Hand abschalten. Zumindest ist das unter VMWare Fusion auf dem Mac so und wenn Du dich entschließt, die VM von der SSD laufen zu lassen, solltest Du das mal prüfen.

Aber das nur am Rande...

Banjo

 

[UranusEXP]

Vielen Dank für Eure Antworten!

Uff... das Szenario ist nicht ohne

Ja, aber ich glaube, ich habe die Prioritäten nicht ganz deutlich gemacht: Der Fokus liegt natürlich auf der Optimierung der Sampler-Performance.

Stell dir einen Rechner als Ding vor, das aus mehreren übereinander liegenden Schichten besteht. Ganz unten ist die Hardware, ganz oben die Anwender-Software. Das OS liegt unter der Anwender-Software. Es würde also keinen Sinn machen, das OS auf eine HDD zu installieren und da großartige Geschwindigkeitsvorteile bei der Anwender-Software zu erwarten.

Kann man das so wirklich einfach sagen? Das Extrembeispiel wäre ja hier die DAW. Die Sampler-Plugins streamen ihren Content von der Platte. Ist diese eine SSD habe ich natürlich die vollen Vorteile, auch wenn OS und DAW auf einer anderen HDD liegen. Ich kann mir ehrlich gesagt nicht vorstellen, dass es z.B. keinen Unterschied in der Performance meiner VM machen sollte, wenn ich die virtuelle Systemplatte auf eine SSD auslagere.

SSDs vs. Sleep Modus sagt mir gar nichts; SSD als "langsameren RAM" einbinden auch nicht.

Hm. Schade, das sind zwei sehr zentrale Punkte. Weiß jemand mehr dazu?

Aus dem Bauch heraus würde ich sagen:
- Audio-OS auf die SSD installieren; Anwender-Software mit dort drauf

Ich weiß eben nicht, ob es nicht reine Verschwendung ist das Audio-OS auf SSD zu packen. Bootgeschwindigkeit ist mir da egal und es laufen genau zwei Programme: Cubase und VSL Ensemble Pro. Welche Verbesserungen wären denn da zu erwarten? Schnellere Programmstarts bringen mir etwa nichts. Auch sonst läuft das derzeit- bis auf wenige Ausnahmen wie das Kontakt-GUI - so flüssig und "responsive", dass da keine Verbesserung notwendig ist und ich mir nur marginale überhaupt vorstellen kann, bzw. es nicht gerechtfertigt ist, dafür 20-30 GB für das OS zu verwenden. Zentraler Flaschenhals in meinem Anwendungsfall, wo hauptsächlich große Sample-Libraries zum Einsatz kommen ist eindeutig die Performance, sowohl was Datendurchsatz als auch Zugriffszeiten anbelangt, der Festplatten auf denen die Samples liegen.

- Alltags-OS auf eine HDD neu installieren. Was für eine Virtualisierungs-Software benutzt du? Die Daten aus der VM heraus zu bekommen ist zumindest unter VirtualBox kein Problem.*

Was das Alltags-OS angeht bin ich eben ein Albtraum-User. Tausend Schnick-Schnack gleichzeitig offen und extrem ungeduldig und undiszipliniert. Die Nutzung ist da halt wesentlich dynamischer. Das auf, das zu, click, click, click. 50 Firefox-Tabs, 3 Office-Dokumente, 1000 Seiten PDF verteilt auf 5 Files, nebenher läuft ein Video und irgendeine Software, die ich teste und dann wahrscheinlich wieder lösche...

Aber ich nehme inzwischen doch immer mehr von der Idee Abstand, da eine physische Maschine zu machen. Zu oft brauche ich das parallel zum Audio-OS. Irgendein Midi-File oder Hörproben suchen, Internetrecherche, etc.. Ich sehe schon wenn ich das Office-OS da extra booten müsste und das Audio-OS verlassen, würde ich doch anfangen, das Audio-OS zu "mißbrauchen" und zuzumüllen. Oft hört man ja, dass das eigentlich keine Performance-Probleme mehr bringen soll, aber ich traue dem Frieden nicht.

Wie gesagt, es funktioniert ja derzeit ganz gut. Wenn ich sage XY dauert 30 Sekunden, sind das mehr gefühlte 30 Sekunden und nur in eher seltenen Extremfällen wirklich so lange.

Aber diese Thema ist nicht das Hautproblem und ich kann es ja auch leicht ausprobieren, was es bringt VMware Player und die virtuelle Systemplatte der VM auf die SSD zu hauen.

So viele Samples wie möglich auf die SSD packen, den Rest auf eine extra Partition auf der HDD (und die immer mal wieder defragmentieren)

Kern des Problems ist eben, dass eine Priorisierung schwierig ist. Deshalb wäre es fantastisch, wenn die SSD als intelligenter Cache funktionieren würde. Schon alleine deshalb, weil ich ja händisch nie auch nur annähernd Effizient priorisieren kann. Wenn ich eine 20 GB Library verwende, ist es ja gut möglich bzw. normal, dass ich da letztlich nur 1 GB an Samples davon konkret in einem Projekt verwende. Man verwendet ja nie alle Samples: Mal überspitzt: Sagen wir ich verwende vielleicht von den zweiten Geigen nur Töne in C-Dur, dabei nur deren unterste Oktave und die beiden lautesten Layer. Dann liegen vielleicht 80% der Library "faul" auf der SSD 'rum, belegen nur Platz, werden aber nie aktiv, während aber gleichzeitig die Samples einer anderen Library von einer der langsamen HDDs gestreamt werden müssen.

Ich denke also es könnte um ein Vielfaches effektiver sein, wenn Konzepte wie "Fancy Cache" oder auch - im Zuge der Recherche zum Thema entdeckt - Hardware-Lösungen wie HDDBoost eingesetzt werden, wenn sie denn leisten können, was sie sollen. Bei HDDBoost habe ich noch nicht verstanden, ob das nur für die HDD des OS funktioniert...

*Win7 ist relativ "reaktionsfreudig" im Gegensatz zu den Vorgängern. Dass die GUI so langsam reagiert, muss man echt mal erst hin bekommen. Da tippe ich auf die VM als Grund, denn so enorm kenne ich das sonst nicht von Win7. Und meine Erfahrung war bisher immer, dass ein System direkt auf der Platte deutlich performanter läuft als in einer VM. Bei allen Vorteilen einer VM - das wärs mir nicht wert.

Wie gesagt, es ist meist nicht so wild, wie es sich vielleicht angehört haben mag und die Vorteile überwiegen deutlich. Die Überlegung war dahingehend, vielleicht die 20-30 GB für die Systemplatte der VM zu opfern, v.a. wenn die Idee "SSD als Cache" funktioniert.

Was den Datenumzug angeht

Da sehe ich momentan kein Problem, v.a. hoffe ich ja auch, dass überhaupt keiner notwendig sein wird.

Nur ein Hinweis am Rande: unter VMWare merkt Windows nicht, dass es auf einer SSD läuft und man sollte die Defragmentierung von Hand abschalten. Zumindest ist das unter VMWare Fusion auf dem Mac so und wenn Du dich entschließt, die VM von der SSD laufen zu lassen, solltest Du das mal prüfen.

Aber das nur am Rande...

Banjo

Lol. DAS hätte ich z.B. garantiert nicht gecheckt. Danke für den Hinweis.

Insgesamt ist für fast alle Punkt eine zentrale Frage von Bedeutung:

Was hat es nun wirklich mit dem Einfluss von Schreibzugriffen auf die Lebenszyklen von SSDs auf sich? Da scheinen sich ja gerade Mythen zu bilden, die wir in 20 Jahren noch hören werden.

Die Stories gehen auch heute noch von "Überhaupt kein Thema mehr." bis "Läuft unter gewissen harten, aber nicht unrealistischen Anwendungsszenarien nur ein paar Monate."

Eine Unempfindlichkeit gegen Schreibzugriffe wäre natürlich unbedingt von Nöten, wenn man Ideen wie "Fancy Cache" aufgreifen will. Wenn das ein Problem ist, bleibt eh' nur: Libraries fest 'draufkopieren, dann gibt's nur Lesezugriffe.

 

[cx01]

Ich bin skeptisch, ob eine SSD dir viel bringen würde. Denn nachdem ein Projekt vollständig geöffnet wurde, liegen ja alle relevanten Samples bereits im RAM, oder?
Die SSD würde also lediglich den initialen Ladevorgang beschleunigen. Und eine 120GB SSD bei 1500GB an Samples hätte vermutlich auch keine so hohe Trefferquote, dass es die Ladezeiten signifikant verkürzen würde.
Eventuell wäre es besser, sich ein RAID 0 aus traditionellen Festplatten aufzubauen. 4 Platten im Verband dürften ähnlich hohe sequentielle Leseraten liefern wie eine SSD.

 

[livebox]

Kann man das so wirklich einfach sagen?

Japp, denn so werden die Rechner aktuell entwickelt: Hardware, digital logic level, microarchitecture level, instruction set level, OS machine level, assembly language level, problem-oriented language level.
(Andrew S. Tannenbaum: Structured Computer Organization)

Was das Alltags-OS angeht bin ich eben ein Albtraum-User. Tausend Schnick-Schnack gleichzeitig offen und extrem ungeduldig und undiszipliniert. Die Nutzung ist da halt wesentlich dynamischer. Das auf, das zu, click, click, click. 50 Firefox-Tabs, 3 Office-Dokumente, 1000 Seiten PDF verteilt auf 5 Files, nebenher läuft ein Video und irgendeine Software, die ich teste und dann wahrscheinlich wieder lösche...

Naja, dann musst du halt mit den Konsequenzen leben

Wenn ich eine 20 GB Library verwende, ist es ja gut möglich bzw. normal, dass ich da letztlich nur 1 GB an Samples davon konkret in einem Projekt verwende. Man verwendet ja nie alle Samples: Mal überspitzt: Sagen wir ich verwende vielleicht von den zweiten Geigen nur Töne in C-Dur, dabei nur deren unterste Oktave und die beiden lautesten Layer. Dann liegen vielleicht 80% der Library "faul" auf der SSD 'rum, belegen nur Platz, werden aber nie aktiv, während aber gleichzeitig die Samples einer anderen Library von einer der langsamen HDDs gestreamt werden müssen.

Du überschätzt die "Intelligenz" des Festplatten-Zugriffes. Was du dir vorstellst kann alleine das Sampler-Programm annähernd bringen. Alles was danach resp. darunter kommt ist schon viel zu abstrakt und hat zu wenige Informationen, um da was sinnvolles zu tun. Abgesehen davon sind die darunterliegenden Ebenen gar nicht dafür ausgelegt, so was zu tun - selbst wenn man sie mit irgendwelchen Infos beschiesen würde. Um das zu realisieren, müsste man auf einer sehr niedrigen Ebene anfangen und die Entwicklung entsprechend darauf auslegen; am besten schon beim Prozessor. Es gibt solche Rechner, die aufs Musik machen spezialisiert sind und so was sehr gut können. Nennt sich z.B. Korg Oasys oder wie sie alle heißen.

Zurück zum Thema: Die Entwicklung bei den Samplern geht ja schon lange in diese Richtung und die Dinger werden immer besser, aber zaubern können die auch nicht. (Ja, ich weiß schon dass dein Beispiel so nicht ernst gemeint war ) Das einzige was da Sinn machen würde wäre diese "Fancy Cache" Geschichte - wenn das denn wirklich so tut. Ich befürchte da schon Probleme in der Ansteuerung - aber wenn da einer erzählt hat dass es gut funktioniert, warum nicht.

Was hat es nun wirklich mit dem Einfluss von Schreibzugriffen auf die Lebenszyklen von SSDs auf sich? Da scheinen sich ja gerade Mythen zu bilden, die wir in 20 Jahren noch hören werden.

Die Stories gehen auch heute noch von "Überhaupt kein Thema mehr." bis "Läuft unter gewissen harten, aber nicht unrealistischen Anwendungsszenarien nur ein paar Monate."

Eine Unempfindlichkeit gegen Schreibzugriffe wäre natürlich unbedingt von Nöten, wenn man Ideen wie "Fancy Cache" aufgreifen will. Wenn das ein Problem ist, bleibt eh' nur: Libraries fest 'draufkopieren, dann gibt's nur Lesezugriffe.

Das mit dem Cache ist natürlich ein Problem, weil man da extrem viele Schreibzugriffe hat. Ansonsten ist der aktuelle Stand (soweit ich weiß), dass SSDs eine höhere Lebenserwartung als herkömmliche HDDs haben. Leute die irgendwelche Horror-Szenarien entwerfen, gibt es immer. Aber ich wage stark zu bezweifeln, dass eine herkömmliche HDD unter gleichen Voraussetzungen und ähnlich negativ angenommenen Umständen da besser abschneiden würde. SSD scheint im Speicherbereich (für den Heimgebrauch*) im Moment DIE zukünftige Lösung zu sein. Aber es soll ja auch noch Leute geben die mit NT 4.0 unterwegs sind...

*Oft ist es ja so, dass etwas in der Industrie eingeführt wird und wenn es erprobt und günstiger ist in den Consumer-Bereich kommt. Bei den SSDs muss man aber bedenken, dass auf den Riesen-Servern ganz andere Anforderungen an die Speicher gestellt werden als anderswo, und sei es im Profi-Recording- oder Film-Bereich. Stell dir eine SAP- oder Oracle-Datenbank vor, auf die ständig Leute aus aller Welt zugreifen. Und damit meine ich nicht ein 250-Mann-Unternehmen, das noch ein paar kleine Büros um den Globus verteilt hat: hp zum Beispiel ist aktuell das größte IT-Unternehmen der Welt; die haben weltweit auf 3 riesen Server-Farmen gekürzt. Also keine falsche Angst an der Stelle, dass die Consumer als Kaninchen missbraucht werden. Zumindest nicht stärker als sonst.
Noch ne kleine Info zu dem Thema hier.


Ich denke der Vorschlag von cx01 ist ganz gut: Bau dir aus herkömmlichen HDDs ein Raid-Array. Eventuell kannst du dafür auch Server-Festplatten verwenden, die 10k oder 15k RPM machen. Sobald ich jetzt aus dem Board raus bin gehe ich wieder ans lernen für meine Datenbanken-Prüfung am Freitag - als nächstes steht an, die Zugriffszeiten von Server- und Consumer-HDDs zu vergleichen. Wenn du magst kann ich nachher mal die Prozent-Zahlen posten... Ich hab die Übung während dem Semester schon mal gemacht und hab noch in Erinnerung, dass die Unterschiede gewaltig waren.
Allerdings muss ich dazu sagen, diese Server-HDDs sind auch entsprechend laut.

MfG, livebox

 

[UranusEXP]

Ich bin skeptisch, ob eine SSD dir viel bringen würde. Denn nachdem ein Projekt vollständig geöffnet wurde, liegen ja alle relevanten Samples bereits im RAM, oder?
Die SSD würde also lediglich den initialen Ladevorgang beschleunigen. Und eine 120GB SSD bei 1500GB an Samples hätte vermutlich auch keine so hohe Trefferquote, dass es die Ladezeiten signifikant verkürzen würde.
Eventuell wäre es besser, sich ein RAID 0 aus traditionellen Festplatten aufzubauen. 4 Platten im Verband dürften ähnlich hohe sequentielle Leseraten liefern wie eine SSD.

Eben nicht. Seit über 10 Jahren streamen Sampler den Content von der Platte. Es wird nur ein mehr oder weniger großes Anfangsstück des Samples als "Puffer" im RAM vorgehalten. Es werden also dann ständig, viele kleine Dateien, die notwendigerweise wild auf der Platte verteilt sind auf unvorhersehbare Weise "angefordert". Deshalb sind ja SSD für Sampler-Anwendungen der Hit schlechthin. Ein RAID 0 mit HDDs bringt da wenig bis nichts, weil es die Zugriffszeiten nicht verbessert und es eben nicht um sequentielle Zugriffe geht. Das mag helfen, wenn man möglichst viele durchgehende Audiospuren aufnehmen oder abspielen will, aber eben nicht wenn es um "Audio-Fetzen" von ein paar Sekunden geht, die möglichst schnell aus allen möglichen "Ecken und Enden" der Platte zusammengesucht werden müssen.

Du überschätzt die "Intelligenz" des Festplatten-Zugriffes.

Mal zurück auf null. Es muss doch nur Folgendes passieren: Die SSD klemmt "vor" der Sample-HDD. Sie ist zunächst leer. Jetzt lade ich einen Kontakt-Patch von der HDD. Die "Intelligenz" kopiert diese Daten dann parallel auf die SSD und sorgt dafür, dass diese Daten dann von dort abgefragt werden. Ich lade weitere Kontakt-Patches und die "Intelligenz" fährt so fort, bis die SSD voll ist. Lade ich dann den nächsten, wirft sie, je nach Strategie, die ältesten oder am wenigsten genutzten Daten wieder herunter. Das sind dann z.B. eben die Samples von Noten, Artikulationen, Dynamiklayern etc., die ich nie benutzt habe. Das ist doch kein Hexenwerk? Rufe ich zwischendurch ein Sample ab, das nicht (mehr) auf der SSD ist, gut - ist das halt ein normaler HDD-Zugriff. Das ist ja kein Problem, weil diese ganze Strategie die HDD-Zugriffe generell extrem reduziert und die HDD solche Zugriffe locker verarbeiten kann.

Zurück zum Thema: Die Entwicklung bei den Samplern geht ja schon lange in diese Richtung und die Dinger werden immer besser, aber zaubern können die auch nicht. (Ja, ich weiß schon dass dein Beispiel so nicht ernst gemeint war ) Das einzige was da Sinn machen würde wäre diese "Fancy Cache" Geschichte - wenn das denn wirklich so tut. Ich befürchte da schon Probleme in der Ansteuerung - aber wenn da einer erzählt hat dass es gut funktioniert, warum nicht.

Ich weiß jetzt nicht genau was Du meinst, aber das Beispiel mit nicht verwendeten Noten, Artikulationen, war durchaus konkret und genauso gemeint, das habe ich ja eben nochmal deutlicher erklärt. Wie gesagt letztlich wäre das nichts anderes, als eine Hybridfestplatte mit einer 120 GB SSD und einer oder mehreren HDDs.

Das mit dem Cache ist natürlich ein Problem, weil man da extrem viele Schreibzugriffe hat. Ansonsten ist der aktuelle Stand (soweit ich weiß), dass SSDs eine höhere Lebenserwartung als herkömmliche HDDs haben. Leute die irgendwelche Horror-Szenarien entwerfen, gibt es immer. Aber ich wage stark zu bezweifeln, dass eine herkömmliche HDD unter gleichen Voraussetzungen und ähnlich negativ angenommenen Umständen da besser abschneiden würde. SSD scheint im Speicherbereich (für den Heimgebrauch*) im Moment DIE zukünftige Lösung zu sein. Aber es soll ja auch noch Leute geben die mit NT 4.0 unterwegs sind...

Eben hier haben wir das Problem. Die Schreibzugriffe wären extrem. Wenn die SSD das nur ein halbes Jahr mitmacht, wäre das natürlich fragwürdig. Andererseits müsste das dann eigentlich doch durch Händlergewährleistung oder Herstellergarantie abgedeckt sein, oder? Letztlich läge ja auch ein Vorteil darin, das die SSD zwar "hart 'rangenommen" wird, aber selbst nur temporäre Daten beinhaltet, also kein Datenverlust zu befürchten wäre, wenn das Teil ausfällt. Das würde sich dann irgendwann einfach in einem herben Performance-Verlust bemerkbar machen. Die Projekte würden nicht mehr vernünftig spielen.

Ich denke der Vorschlag von cx01 ist ganz gut: Bau dir aus herkömmlichen HDDs ein Raid-Array.

Wie gesagt, das bringt nur bedingt etwas, u.U. kann es sogar die Performance verschlechtern! Sagen wir ich nehme 4 Platten im Raid 0 und mach da eine Orchester-Library drauf. Jetzt mache ich irgend ein Tutti, mit Blech, Holz, Streicher und Percussion. Jetzt müssen alle Samples auf der "einen" Platte gesucht werden, das dauert dann 4 mal so lange, als würden schlicht alle 4 Orchester-Sektionen auf je einer Platte liegen. Wie gesagt, reine Durchsatzraten sind nur ein Teil der Geschichte.

Eventuell kannst du dafür auch Server-Festplatten verwenden, die 10k oder 15k RPM machen. Sobald ich jetzt aus dem Board raus bin gehe ich wieder ans lernen für meine Datenbanken-Prüfung am Freitag - als nächstes steht an, die Zugriffszeiten von Server- und Consumer-HDDs zu vergleichen. Wenn du magst kann ich nachher mal die Prozent-Zahlen posten... Ich hab die Übung während dem Semester schon mal gemacht und hab noch in Erinnerung, dass die Unterschiede gewaltig waren.
Allerdings muss ich dazu sagen, diese Server-HDDs sind auch entsprechend laut.

Das wäre aber in der Tat evtl. eine Alternative, wenn es sich preislich lohnt. Infos dazu würde ich sehr begrüßen. Die Lautstärke der HDDs ist mir völlig egal, da mein Rechner eh' räumlich ausgelagert ist.

 

[livebox]

Das wäre aber in der Tat evtl. eine Alternative, wenn es sich preislich lohnt. Infos dazu würde ich sehr begrüßen. Die Lautstärke der HDDs ist mir völlig egal, da mein Rechner eh' räumlich ausgelagert ist.

Nur kurz dazu - (zum Rest ein andermal mehr, so ich es nicht vergesse): Verglichen wurden eine Hitachi Ultrastar 15K 450GB (15000 RPM, avg. seek time 3,6ms, avg. transfer rate 150 MB/s) und ein WD Special Edition Caviar 200GB (7200 RPM, avg. seek time 8,9ms, avg. transfer rate 100 MB/s). Berechnet wurde jeweils das sequentielle und das zufällige Lesen von 10.000 8kB großen Blöcken von der Platte. Beim sequentiellen Lesen braucht die Serverplatte nur 66% der Zeit der Consumer-Platte; beim zufälligen Lesen sind es sogar nur 43%.

Nebenbei erwähnt - die Unterschiede zwischen seq. und rand. lesen sind noch viiieel enormer: Bei der Server-Platte braucht das seq. Lesen nur 0,95% der Zeit die fürs zufällige Lesen gebraucht wird; bei der Consumer-Platte sind es sogar nur 0,62%. Aber darauf hat man in deinem Anwendungsfall i.d.R. wenig Einfluss, wie die Daten auf der Platte angeordnet werden.

MfG, livebox

P.S. Billig sind die Server-Platten aber definitiv nicht.

 

[Toaster]

Ich klinke mich mal mit ein

Also für dein Problem wird es in der Tat schwierig eine SSD optimal einzusetzen.
Alle Samples auf SSDs wird zu teuer, HD RAID wird ohne (ebenfalls teuren) RAID Controller eher negative folgen haben, da Software RAIDs miese Latenzen haben, Server HDs wäre eine Überlegung wert, aber für 1,5TB auch nicht ganz billig - wenn man z.B. anstatt Server HDs WD Raptopr Platten nimmt kommt man schon auf 440€+ und eben auch nicht os schnell wie SSDs...
Zum Cachen auf der SSD. Das ginge theoretisch schon, allerdings sehe ich da ein "Interessen"-Problem. Die meisten Cache-Lösungen wollen das allgemeine System beschleunigen, daher laden sie die meist genutzen Programme in den zusätzlichen Cache. Das bedeutet erstens, dass oft genutzte Daten gecached werden (da dürften z.B. viele OS Daten rein gehen und Programme die du immer brauchst...) zweitens ist das Problem, dass viele Daten erst im Nachhinein gecached werden.(wenn du sie bereits oft benutzt hast) Das heisst wenn du z.B. lange am selben Projekt arbeitest dürften die dort genutzen Samples in den Cache wandern und du kannst sozusagen jeden Tag flotter arbeiten... wenn du aber häufiger Porjekte nach einander bearbeitest, die keine gemeinsamen Samples nutzen hast du schon ein Problem
Soweit zumindest die Überlegung, die genauen Algorithmen geben die Hersteller leider nicht Preis...

Ich denke für dich wäre am lohnendsten alle Samples und nur die Samples auf eine normale 7200U/min HD zu packen und dann via der Silverstone-Lösung eine SSD als Cache anhängen. Dann werden NUR Samples gecached allerdings immer die, die du am häufigsten benötigst. Je nach Projekt und SSD-Grösse sollte das aber bereits nach relativ wenigen Benutzungen die jeweils aktuellen Samples in den Cache geladen haben - aber auch hier alles theoretische Überlegungen wenn der algorithmus nicht genau bekannt ist

Um die Haltbarkeit der SSD musst du dir keine Sorgen machen, sofern du die richtige nimmst neue mit gutem Controller (Stichwort Wear-Leveling) und den richtigen Speicher-Chips sollten da gut dabei sein z.B. Crucials Real SSD C300.

Wo liegt überhaupt deine Budgetgrenze?

Grüsse

 

[UranusEXP]

IZum Cachen auf der SSD. Das ginge theoretisch schon, allerdings sehe ich da ein "Interessen"-Problem. Die meisten Cache-Lösungen wollen das allgemeine System beschleunigen, daher laden sie die meist genutzen Programme in den zusätzlichen Cache. Das bedeutet erstens, dass oft genutzte Daten gecached werden (da dürften z.B. viele OS Daten rein gehen und Programme die du immer brauchst...) zweitens ist das Problem, dass viele Daten erst im Nachhinein gecached werden.(wenn du sie bereits oft benutzt hast) Das heisst wenn du z.B. lange am selben Projekt arbeitest dürften die dort genutzen Samples in den Cache wandern und du kannst sozusagen jeden Tag flotter arbeiten...

Hi Toaster und Danke für Deine Antwort!

Was etwa "Fancy Cache" angeht, da kann man bestimmen, welche Platten überhaupt gecached werden sollen. In meinem Fall würde ich natürlich nur die Platten(n) mit den Samples nehmen, dann wird auch nichts anderes gecached als Samples.

In der Tat ist es eine zentrale Frage, WANN bzw. unter welchen Bedingungen nun die Daten gecached werden. So wie ich es bei FC verstehe, wird einfach alles gecached, was aufgerufen wird, bis eben der Cache voll ist, dann werden wahlweise, die am wenigsten oder am längsten-unbenutzten Daten verworfen. Das dürfte dafür sorgen, dass sich die Geschichte recht schnell an das jeweilige Projekt anpasst. Das Prinzip käme ja einer "musikalischen" Arbeitsweise sehr entgegen: Man legt Ideen fest (und damit die Samples) und baut immer mehr aus. Je mehr man ausbaut, desto wichtiger wird die Performance des Systems.

Klar, wenn, man dann von einem großen Projekt zu einem anderen wechselt, wird es ein paar Durchläufe benötigen bis alles wieder rund läuft. Aber auch hier wirkt z.B. Kontakt schon entgegen: Der merkt sich nämlich auch, welche Samples er zuletzt in dem jeweiligen Projekt benutzt hat und lädt diese zuerst. Wenn ich also ein großes Projekt mit einem jungfräulichen oder "fremden" L2-Cache lade, laden dann von daher schon die wichtigsten Samples zuerst dort.

Allerdings bedeutet all das eben wie gesagt auch u.U. massive Schreibzugriffe (je nachdem ob die jeweiligen Audio-Files von Anfang an komplett im Cache laden, oder - hoffentlich - nur die "Anfangsfetzen" die Kontakt & Co. normalerweise als Puffer in den RAM laden). Hinzukommt, dass der L2-Cache FC beim Reboot verloren geht. Das wäre insofern kein Problem, wenn sowohl SSD generell, als auch der L2-Cache beim Sleep-Modus mitspielen (Ich reboote nur sehr selten). Wenn NICHT, dann ist davon auszugehen, das die SSD durchschnittlich täglich einmal komplett neu beschrieben wird und ob das dann nicht DOCH zum Problem wird?!

Ob HDDBOOST wirklich eine Alternative ist, weiss ich noch nicht, es ist wohl nur für Systemplatten gedacht und auch hier weiß kein Mensch welche Daten auf der SSD landen und bleiben bzw. nachgeladen werden.

Grundsätzlich ist aber das Prinzip "SSDs als Cache" wohl derzeit ein vielfach verfolgter Ansatz in verschiedenen IT-Bereichen. Es gibt z.B. auch von Adaptec eine HDDBoost prinzipiell wohl ähnliche Lösung, die kostet allerdings 1000 EUR. Das wiederum lässt mich daran zweifeln, dass es eine 50 EUR-Lösung wie HDDBoost wirklich bringt.

Achja, vom Budget her möchte ich erstmal unter 200 EUR bleiben. PCIe-Lösungen scheiden daher aus. SATA III gibt mein Mainboard übrigens nicht her, ich habe keine Ahnung, was brauchbare Controller kosten und ob die nicht wieder eine potentielle Problemquelle sind.

 

[livebox]

Hi,

nur so zur Info, lief mir gerade über den Weg: Hier bei Chapter 2 auf Folie Nr. 22 (PDF-Seite 11) ist eine kleine, aber interessante Info zum Thema SSDs. Unter diesen Gesichtspunkten würde ich von einer SSD als "Zwischen-RAM" weiter Abstand nehmen - wegen der großen Zugriffszeiten bei nicht-sequentiellem Schreiben.

MfG, livebox

 

[MatthiasT]

Ich würde da von so einem Gebastel auch Abstand nehmen.


Mein Rat wäre entweder alles Relevante auf die SSD zu packen, sprich die Samples und das OS oder es komplett zu lassen. Alles andere ist Käse und ich bezweifel dass es ordentlich funktioniert. Eine SSD ist kein RAM, wenn man das will sollte man sich lieber mehr RAM in den Rechner hauen.
Ich meine, klar wäre das in deinem Fall sehr teuer, aber 200 Euro in den Wind zu schießen und außer einer Menge Arbeit nichts von zu haben wird dir auch nciht weiterhelfen.

 

[Toaster]

Apropo RAM, was ich mir noch am überlegen war, ob es ggf. eine vernünftige Lösung gibt eine RAM-Disk zu erstellen und diese zu Cachen. Da würden keine Daten gespeichert, also wird der Cache bei jedem Neustart neu befüllt (keine alten Daten im Weg), dazu kommt es wäre nochmals deutlich schneller als eine SSD und man hat auf jeden Fall keine Haltbarkeitsprobleme... braucht aber eine ganz ordentliche Menge an RAM...

 

[UranusEXP]

Danke für Eure Antworten!

Hi,

nur so zur Info, lief mir gerade über den Weg: Hier bei Chapter 2 auf Folie Nr. 22 (PDF-Seite 11) ist eine kleine, aber interessante Info zum Thema SSDs. Unter diesen Gesichtspunkten würde ich von einer SSD als "Zwischen-RAM" weiter Abstand nehmen - wegen der großen Zugriffszeiten bei nicht-sequentiellem Schreiben.

MfG, livebox

Ich versteh jetzt echt nur Bahnhof. In dem PDF steht an besagter Stelle:

Random Reads mit sehr geringer Latenz ( < 0.01 ms)

Schnelle Zugriffszeiten sind doch gerade DIE Stärken von SSDs.

Ich würde da von so einem Gebastel auch Abstand nehmen.


Mein Rat wäre entweder alles Relevante auf die SSD zu packen, sprich die Samples und das OS oder es komplett zu lassen. Alles andere ist Käse und ich bezweifel dass es ordentlich funktioniert. Eine SSD ist kein RAM, wenn man das will sollte man sich lieber mehr RAM in den Rechner hauen.
Ich meine, klar wäre das in deinem Fall sehr teuer, aber 200 Euro in den Wind zu schießen und außer einer Menge Arbeit nichts von zu haben wird dir auch nciht weiterhelfen.

Klar, ist eine SSD kein RAM. Sie soll hier auch nicht so verwenden werden. Letztlich soll die Lösung doch nur darauf hinauslaufen, dass im Hintergrund eben immer genau die benötigten Samples (bzw. relevante Teile davon) auf die SSD kopiert werden. Nichts anderes.

Ich habe mich zwischenzeitlich mit dem Support von Fancy Cache auseinandergesetzt: Es werden alle Daten gecached, die von der Sample-Platte kommen. Zunächst würden nur die Preload-Fetzen von Kontakt & Co. kopiert, sobald ich eine Taste anspiele und das ganze Sample abrufe, dann eben das ganze Sample. Der Cache bleibt auch im Sleep-Modus erhalten.

Mehr RAM ist nicht unbedingt eine Alternative, da kann ich zwar auf jeden Fall mehr Samples bzw. Instrumente vorhalten, aber nicht unbedingt mehr Stimmen abspielen. In Kontakt kann man recht flexibel einstellen, wieviel er von den jeweiligen Samples vorladen soll, d.h. wenn ich da mehr einstelle, kann ich mehr Stimmen abspielen, ja. Aber Play ist da z.B. leider nicht sehr flexibel, da wird die Stimmenanzahl größtenteils von der Performance der Festplatte bestimmt. Um mehr Instrumente spielbereit vorhalten zu können empfiehlt sich eher RAM um mehr Stimmen spielen zu können eben bessere Platten.

Es ist halt extrem ineffizient und wenig elegant, eine komplette Library von sagen wir 20 GB stets auf der SSD vorzuhalten, von der dann in jedem Projekt jeweils nur 1 GB an Daten benötigt werden. Das sind ja in jedem Projekt andere Daten, die davon benötigt werden. Also ist bezogen auf das Projekt jeweils sicher 70-90% "Datenmüll" auf der SSD.

Ich werde es einfach auf einen Versuch ankommen lassen. Die SSD lege ich mir sowieso zu und die Software-Lösung auszuprobieren ist ja keinerlei "Arbeit". Starten, konfigurieren und dann halt ausprobieren. Ich stehe ja auch mit einem User in Kontakt, bei dem das funktioniert. So bin ich ja drauf gekommen.

Apropo RAM, was ich mir noch am überlegen war, ob es ggf. eine vernünftige Lösung gibt eine RAM-Disk zu erstellen und diese zu Cachen. Da würden keine Daten gespeichert, also wird der Cache bei jedem Neustart neu befüllt (keine alten Daten im Weg), dazu kommt es wäre nochmals deutlich schneller als eine SSD und man hat auf jeden Fall keine Haltbarkeitsprobleme... braucht aber eine ganz ordentliche Menge an RAM...

FC macht das eigentlich so und nutzt zunächst den RAM. Man kann eben zusätzlich einen L2-Cache definieren. Aber alles über 24 GB RAM ist derzeit absolut utopisch. Den möchte ich ja auch bald haben, aber den würde ich dann tendenziell doch eher direkt nutzen um eben mehr Instrumente vorhalten zu können. Ich habe ja jetzt 12 GB und die sind proppenvoll, ich habe halt Cubase-Templates, mit 200+ Midi-Spuren, auf jeder ein eigenes Instrument (hauptsächlich EWQL), die wiederum größtenteils mit vielen Spielweisen.

 

[livebox]

Ich versteh jetzt echt nur Bahnhof. In dem PDF steht an besagter Stelle:

Schnelle Zugriffszeiten sind doch gerade DIE Stärken von SSDs.

Sorry, ich hab mich missverständlich ausgedrückt, die "Zugriffszeiten" warn da fehl am Platz:

wegen der großen Zugriffszeiten bei nicht-sequentiellem Schreiben.

Ich meinte damit, die hohen Schreibzeiten beim random write sind für den Anwendungszweck schlecht - denn die potentiellen folgenden Samples sind ja auch ständig andere und müssen somit auch ständig neu reingeschrieben werden.

MfG, livebox

 

[UranusEXP]

Ich meinte damit, die hohen Schreibzeiten beim random write sind für den Anwendungszweck schlecht - denn die potentiellen folgenden Samples sind ja auch ständig andere und müssen somit auch ständig neu reingeschrieben werden.

MfG, livebox

Die Zugriffszeiten sind aber auch hier immer noch ein Bruchteil im Vergleich zu HDDs! Ich glaube Du missverstehst die - zugegebenermassen irreführende - Balkengrafik. Die Zeitleiste ist nicht absolut, sondern gilt nur für den Vergleich zwischen den Zugriffszeiten EINES Mediums! Nicht für den Vergleich HDD/SSD. Du meinst, weil der Read-Balken bei SSD höher ist als bei HDD, wäre sie langsamer als die HDD. Die Grafik muss wohl so sein, denn wäre die Zeitleiste absolut für beide Medien, würdest Du nämlich auf der SSD schlicht gar nix sehen, weil die Balken viel zu kurz wären um noch sinnvoll darstellbar zu sein...

Wie auch immer:

Letztlich ist die Zugriffszeit beim Schreiben für meine Anwendung sowieso recht bedeutungslos, da geht's doch nicht um Echtzeit. Das ist doch nur beim Lesen bzw. Abspielen relevant. Die ersten Zugriffe auf die Samples werden sowieso über die HDD abgewickelt. Ob das "Kopieren" eines Samples von, sagen wir, 2MB nun ein paar Millisekunden länger dauert oder nicht ist völlig egal. Zur Erinnerung: Bisher wird der gesamte Datenverkehr von zwei HDD abgewickelt.

Ich glaube das Anwendungsszenario ist noch nicht deutlich genug geworden:

Ich öffne ein Template. Kontakt & Co. laden insgesamt sagen wir 10 GB "Sample-Puffer-Portionen" in den RAM, bevor ich überhaupt anfangen kann. Schon sobald diese angefragt werden, also noch während das Projekt lädt, landen sie auf der SSD. Dann wählt man ein Instrument und probiert verschiedene Ideen damit, der erste Zugriff auf die Samples läuft über die HDD schon der zweite in 99,99% der Fälle (ausser vielleicht ich spiele ein 128tel-Tremolo bei Tempo 1000 BPM) über die SSD. Ich behalte die Idee und spiele mit dem nächsten Instrument darüber. Bis dahin sind die Samples von Instrument 1 schon eine Ewigkeit auf der SSD, die HDD also wieder völlig unbelastet, um die neuen Samples liefern zu können. Das geht dann immer so weiter. Die Anforderungen an die SSD steigen mit der Zeit, die an die HDD nicht oder kaum. Solange bis soviele Samples regelmässig und in kurzen Abständen verwendet werden, dass sie nicht mehr alle gleichzeitig auf der SSD Platz haben (bei den meisten Projekten wird es gar nicht soweit kommen). Die kommen dann eben direkt von den HDD - so wie bisher ohne SSD ALLE von dort kommen.

 

[Schlumpf]

Hallo allerseits,
ich will mal von meinen Erfahrungen mit SSDs bereichten. Also zunächst mal sind SSDs nicht in allen Belangen schneller als herkömmliche Festplatten. Sie haben besonders Nachteile, falls viele kleine Dateien nicht sequentiell geschrieben werden sollen und umso voller eine SSD ist umso langsamer kann sie nur schreiben. Meine Intel Postville von der 1. Generation hat da unter ungünstigen Umständen Schreiberaten von nur 3 MB/s und schlechter. Neuere SSD's sind da auch nicht besser --> Deshalb ist die Nutzung von einer SSD als Cache von vielen kleinen Dateien nicht sonderlich sinnvoll.

Meiner Erfahrung nach, kann es durchaus Sinn machen, nur die Anwendungen auf die SSD zu installieren. Ausnahme ist wenn viele Programmbibliotheken (z.B. dll-Dateien nicht von der SSD geladen werden).

Eine SSD beschleunigt vorallem den Betriebssystemstart und hat beim Lesen Vorteile. Als Speicher für große Datenmengen ist sie zur Zeit noch zu teuer. Deshalb empfehle ich dir noch zu warten bis 1 TB SSD's rauskommen und auch im Preis fallen.

Meiner Meinung nach macht es auch keinen Sinn auf 24 GB RAM aufzurüsten (bist du dir sicher, dass du das überhaupt brauchst? Ich komme mit umfangreichen Projekten auf max. 6 GB RAM). Spar lieber noch ein Jahr und warte bis SSDs preiswerter und größer werden, für dein genanntes Anwendungsszenario sind SSDs noch nicht weit genug entwickelt und zu teuer und auch die Idee die SSD als Cache zu nutzen ist aufgrund der niedrigen Schreibgeschwindigkeit nicht zu empfehlen.

 

[UranusEXP]

Hallo Schlumpf,

Danke für deine Antwort.

Hallo allerseits,
Meine Intel Postville von der 1. Generation hat da unter ungünstigen Umständen Schreiberaten von nur 3 MB/s und schlechter. Neuere SSD's sind da auch nicht besser --> Deshalb ist die Nutzung von einer SSD als Cache von vielen kleinen Dateien nicht sonderlich sinnvoll.

Ich weiss ja nicht: Wenn ich mir herstellerunabhängige Daten der etwa von Toaster angesprochenen Crucial-SSD anschaue: Random Write 4K - knapp 141 MB/s und ca 0,75 ms Zugriffszeit. Das würde weit, weit ausreichen.

Als Speicher für große Datenmengen ist sie zur Zeit noch zu teuer. Deshalb empfehle ich dir noch zu warten bis 1 TB SSD's rauskommen und auch im Preis fallen.

Bis ein TB mit SSD abgedeckt werden kann, ohne arm zu werden, wird sicher noch das ein oder andere Jahr vergehen.

Meiner Meinung nach macht es auch keinen Sinn auf 24 GB RAM aufzurüsten (bist du dir sicher, dass du das überhaupt brauchst? Ich komme mit umfangreichen Projekten auf max. 6 GB RAM).

Stimmt, jetzt wo Du's sagst...

Ne, kleiner Scherz: JA, ich bin mir sicher. Ich sagte doch bereits, dass schon meine 12 GB randvoll sind und ich noch jede Menge Samples übrig habe, die ich gerne noch in meinem Template spielbereit vorhalten würde. Für Monster-Libraries der nächsten Generation, wie etwa EW Hollywood Strings kann man gar nicht genug haben (weder RAM noch Festplatten-Performance).

 

[de O]

hi,

also erstmal: ist das ein geiler fred hier, danke leute! ich suche gerade ne ssd für meine audio-ws und finde diese diskussion hier.

zum punkt: was haste denn jetzt verbaut und wie installiert und vor allem wie laufen die systeme / die audio tools und wie schauts denn nu mit der stimmenanzahl

fragen über fragen

beatz,
O

 

[UranusEXP]

und was haste nu gemacht?

Noch gar nichts bis dato...