[Test] SSD vs. HDD @SampleLoading

[SteveD]

Hi,

Eigentlich wollte ich euch hier aufzeigen wie viel toller SSDs im Vergleich zu HDDs sind, da dieses Thema ja immer mehr in die Diskussion gerät, wie ihr sehen werdet hat sich dabei aber einiges herausgestellt.
Deshalb habe ich einiges Tests gemacht um die Ladezeiten zu vergleichen.

Das Setup:

-AMD X6 T1090
-12GB RAM @DDR3 1333
-Intel X-25 G2 Postville
vs.
-Samsung Spinpoint F3 1TB
-Win 7

Testdatei:

-Reaper als DAW
-6 Spuren mit jeweils einer Kontakt 4.1 Instanz, welche ich mit diversen Samples voll geladen habe, macht dann insgesamt ca. 9 - 10 GB (laut Taskmanager).

Als Testverfahren habe ich jeweils 3 Runs gemacht. Library jeweils einmal auf der HDD und SSD.

Ergebnisse:

SSD: 5 Min
HDD: 5 Min

Das Ergebnis wunderte mich doch. So hatte ich einen deutlichen Vorsprung der SSD erwartet. Der Flaschenhals musste also wo anders liegen.

In Reaper kann man auswählen, wie Reaper jedes PlugIn behandeln soll, ob in einem separten Prozess pro Plugin oder eben alle in einem Prozess. Das letzte erwähnte war die Einstellung mit den ich die ersten Tests gemacht habe.
Diese änderte ich nun zu der erst genannten. Und siehe da:

SSD: 1,40 Min
HDD: 1,40 Min

Der eine große Prozess muss im Vergleich zu den vielen kleineren wohl doch schwieriger zu verwalten gewesen sein.
Auf Grund dieser Ergebnisse würde ich jedoch jedem empfehlen die "VST bridging/firewalling" Option auf "In dedicated process per-plugin" zu stellen. Mehr Performance und mehr Sicherheit, falls mal ein Plugin abstürzt.

Was jedoch weiterhin besteht ist der Fakt, dass der Flaschenhals wohl nicht bei des Festplatte liegt. Deshalb habe ich nun einmal den Prozessor von 3,2 GHz auf 2 GHz heruntergetaktet (Diesmal nur auf der SSD). Jetzt wurde das Problem deutlich:

@3,2 GHz: 1,40 Min
@2,0 GHz: 2,40 Min

Der Prozessor ist also hier doch der Flaschenhals. Was jedoch erwähnt werden muss ist, dass beim Laden der Samples jeweils nur 1 Kern benutzt wurde - nichts also mit Multiprozessorsuppport - ob das an Reaper, Kontakt oder einer Einstellung liegt kann ich leider nicht belegen, da ich in beiden eigentlich eingestellt habe, dass sie alle Kerne benutzen dürfen.

Um den RAM als weiteren Flaschenhals auszuschließen habe ich auch noch den Vergleich zwischen Taktungen bei 1333MHz und im Vergleich dazu heruntergetaktet auf 800 MHz gemacht.

@1333 MHz: 1,40
@800 MHz: 1,40

Hier sind also ebenfalls keine großen Unterschiede auszumachen.

Fazit:

Unterm Strich liegt der Flaschenhals im Bereich des Library-Ladens - wohl auf Grund des fehlenden Multiprocessing - immer noch beim Prozessor.
Somit ist man in diesem Gebiet mit einer schnellen HDD wie der Samsung Spinpoint F3 wohl immer noch Top beraten. Wie repräsentativ diese Ergenisse auf Grund der Backgroundloading Funktion von Kontakt 4.1 sind, ist eine andere Frage.

Ich würde jedoch jedem weiterhin eine SSD empfehlen, da damit einfach alles am PC viel mehr Spaß macht.

Steve

 

[livebox]

Unterm Strich liegt der Flaschenhals im Bereich des Library-Ladens - wohl auf Grund des fehlenden Multiprocessing - immer noch beim Prozessor.

Zumindest bei Reaper und/oder Kontakt. Wäre mal interessant, den Test noch mit anderer Software zu machen.


Aber sehr schön, dass du dich mal darum bemüht hast - herzlichen Dank, finde ich sehr gut!

 

[Reflex]

Interessanter Vergleich, vielen Dank.

Blöde Frage, aber wieso wird der Prozessor beim Laden von Samples so stark beansprucht?
Ich dachte, da werden einfach die Samples von der Platte ins RAM kopiert.

1,40 m für 9-10 GB Samples ist aber auf alle Fälle ein Wert, der mMn nicht mehr unbedingt weiter optimiert werden muß... das ist doch klasse.

 

[luzil]

schöner Test! Interessant wäre evtl. noch wenn du die Samples nur in Kontakt als Standalone Anwendung lädst ohne DAW. Gibt ja ne Kontakt.exe. Auch könntest du mal den Freeware Sampler shortcircuit in Reaper statt Kontakt verwenden. Was lädst du da genau, multi gesampledte Instrumente oder wahllos auch grössere .wav?

SSD macht für mich v.a. bei Laptop Sinn, da wird der Ladezeitunterschied wegen des 2,5'' Faktors dann schon messbar

 

[SteveD]

Blöde Frage, aber wieso wird der Prozessor beim Laden von Samples so stark beansprucht?
Ich dachte, da werden einfach die Samples von der Platte ins RAM kopiert.

Das hat meiner Meinung nach bei der Kontakt 4 Free Player Version, die ich benutze, damit zu tun, dass alle Samples der Library in einer großen Datei liegen. Das heißt, dass Kontakt beim Laden wahrscheinlich erstmal die Files temporär entpacken muss; und dadurch wird natürlich die CPU beansprucht. Wenn ich die Vollversion von Kontakt 4 habe, dann werde ich mal weiter schauen.

schöner Test! Interessant wäre evtl. noch wenn du die Samples nur in Kontakt als Standalone Anwendung lädst ohne DAW. Gibt ja ne Kontakt.exe. Auch könntest du mal den Freeware Sampler shortcircuit in Reaper statt Kontakt verwenden. Was lädst du da genau, multi gesampledte Instrumente oder wahllos auch grössere .wav?

Habe das jetzt mal kurz mit der Standalone Version versucht, das bringt aber keine Unterschiede.
Ich lade da einfach multi gesampledte (komisches Wort) Instrumente aus der Factory Library von Kontakt, ist wie bereits erwähnt die Free Version.
Werde es in Zukunft vielleicht auch noch einmal mit einem anderen Sampler versuchen.

 

[Reflex]

Das hat meiner Meinung nach bei der Kontakt 4 Free Player Version, die ich benutze, damit zu tun, dass alle Samples der Library in einer großen Datei liegen. Das heißt, dass Kontakt beim Laden wahrscheinlich erstmal die Files temporär entpacken muss; und dadurch wird natürlich die CPU beansprucht. Wenn ich die Vollversion von Kontakt 4 habe, dann werde ich mal weiter schauen.

Genau, das wird es sein! Daran habe ich gar nicht gedacht.
Das ist aber bei der Vollversion nicht anders, auch da liegen die Samples in großen, komprimierten Dateien gepackt vor.

Hast du vielleicht Sample Libraries, wo die Samples einfach als Wav-Dateien in einem Ordner gesammelt vorliegen?
Ich denke, da wäre der Vergleich dann aussagekräftiger, da die CPU dann sicher eine viel kleinere Rolle spielt.

 

[pico]

was erwartet ihr denn eigentlich - die Festplatte und die SSD hängen doch am IDE/SATA ?! und das ist der Flaschenhals ...

 

[SteveD]

Könntest du das bitte genauer erklären. Wieso sollte der SATA Port beim Sample laden auf einmal der Flaschenhals sein?

 

[Nobieesd]

sicherlich anders würde dass bei ner PCI express SSD aussehen, die sind auch "relativ" günstig
http://www.alternate.de/html/produc...tplatten&l2=Solid+State+Drives&l3=PCI+Express
nur anscheinend gibts dort große probleme wenn man auch das Betriebsystem drauf installiert,
nicht nur das booten scheint nicht zu funktionieren, sondern auch die verschiedenen sektoren
sollen nach ca. 2 jahren regelmäßigem gebrauch aufgrund der arbeitsspeicherauslagerung
so kaputt sein dass man die festplatte nichtmehr hernehmen kann

dass ganze steckt ja im vergleich zu normalen HD's noch in den kinderschuhen,
also ich werde mir erst nächstes jahr eine holen

 

[pico]

weil bei großen Dateien und modernen Festplatten, hoher Drehzahl mit Cache und den heute üblichen Clustergrößen, die mechanischen Zugriffszeiten nicht mehr so stark ins Gewicht fallen.

Erst wenn die große Date total fragmentiert ist, dann wird die SSD wieder punkten oder bei vielen kleinen verteilten Dateien.

In diesem Beispiel wird aber eine große Datei geladen und da ist dann die Transferrate vom SATA der 'Flaschenhals', denn nicht jeder Chipsatz erreicht in der Praxis auch nur annähernd die theoretische Transferrate von 150MB/s

 

[SteveD]

dass ganze steckt ja im vergleich zu normalen HD's noch in den kinderschuhen,
also ich werde mir erst nächstes jahr eine holen

Die Kinderschuhe haben die SSDs schon lange überwunden. Schlag zu, wirste nicht bereuen!

weil bei großen Dateien und modernen Festplatten, hoher Drehzahl mit Cache und den heute üblichen Clustergrößen, die mechanischen Zugriffszeiten nicht mehr so stark ins Gewicht fallen.

Erst wenn die große Date total fragmentiert ist, dann wird die SSD wieder punkten oder bei vielen kleinen verteilten Dateien.

In diesem Beispiel wird aber eine große Datei geladen und da ist dann die Transferrate vom SATA der 'Flaschenhals', denn nicht jeder Chipsatz erreicht in der Praxis auch nur annähernd die theoretische Transferrate von 150MB/s

Das ist schon klar, aber die Tests zeigen, dass SSDs selbst bei großen Dateien den HDDs überlegen sind. Und woran es an meinem Setup liegt haben wir ja schließlich herausgefunden.

EDIT: Hat SATA2 nicht eigentlich eine theoretische Transferrate von 300 MB/s?

EDIT 2: Hier ein gutes Review, in welchem man den - mehr oder weniger - geringen Unterschied zwischen SATA 2 und 3 sehen kann.

 

[livebox]

FYI: Ich saß gerade beim Mittagessen mit zwei Kollegen zusammen, die die letzten Tage bei einem gewissen großen Anbieter für ERP-Lösungen aus dem süddeutschen Raum Geschwindigkeits-Tests mit SSD-Platten gemacht haben.
Fazit: Die Geschwindigkeit schwankt (bei der gleichen Platte) enorm - so um die 20%. Verantwortlich dafür ist der Controller in der Platte. Hat damit zu tun, auf welchen Blöcken des Flash-Speichers geschrieben wird.
Es ist ja bekannt und auch nur logisch, dass formatierte SSDs da deutlich bessere Werte liefern als welche, die in Benutzung sind. Aber auch eben bei diesen Platten in Benutzung schwankt die durchschnittliche I/O-Leistung anscheinend ziemlich.

Trotzdem deren Fazit: SSDs sind den herkömmlichen Platten weitaus überlegen.

MfG, livebox

 

[Nobieesd]

Danke für die Information...
ich glaube dass mit der formatierten und benutzten ssd liegt an fehlender TRIM - funktionen...
(falls ihr nicht wisst was das ist: wiki, google)

aber diese ist ja bald aus der welt geschafft, nur leider gerade nicht bei der PCI-Express ssd die ich mir holen wollt