SATA SSD an altes IDE System adaptieren, aber wie?

FireandIce

Vice Admiral Special
Mitglied seit
24.01.2006
Beiträge
521
Renomée
12
Ich möchte gerne einem alten Athlon XP 2400+ System mit nur IDE und PCI Anschlüssen neues Leben einhauchen. Basis des Systems ist ein MSI KT4 Ultra in der Grundausstattung ohne SATA Anschlüsse. Den RAM habe ich auf den Maximalausbau von 3 GB aufgerüstet. Gerne würde ich die langsame 80 GB IDE Festplatte gegen eine SSD austauschen. Auf welchem Weg sollte ich eine SATA SSD adaptieren? Es gibt PCI-> SATA Adapter und IDE-> SATA Adapter. Essentiell wäre das von der SSD gebootet werden kann.
 
Es gibt auch PATA SSDs.
 
Du brauchst eine PCI SATA-Karte mit eigenem BIOS. Dann suchst Du Dir für die SATA-Karte einen PCI-Slot (siehe INT Request Table), der möglichst nicht mit einem anderen Gerät shared, weil das bei den VIA-Chipsätze immer besonders heikel war, und stöpselst da die SSD dran. Dank eigenem BIOS sollte die Platte bootbar sein.

Da diese alten SATA-Controller jedoch proprietäre Treiber brauchen, die kein Trim druchreichen selbst wenn das OS es unterstützen würde (ab Windows 7), brauchst Du eine SSD, der Trim weitestgehend egal ist. Da kommen eigentlich nur die SSDs mit Sandforce-Controller in Frage, da das (meines Wissens) der einzige Controller ist, der Foreground-Garbage-Collection macht, also sowieso erst beim Schreibzugriff aufräumt, während alle anderen Controller Background-Garbage-Collection betreiben und dabei auf Trim angewiesen sind.
 
also sowieso erst beim Schreibzugriff aufräumt, während alle anderen Controller Background-Garbage-Collection betreiben und dabei auf Trim angewiesen sind.
So ein Unsinn, das eine hätte mit dem anderen auch nichts zu tun. Keine SSD ist auf TRIM angewiesen, die wissen alle auch beim Überschreiben eines LBAs das die Daten die vorher unter diesem LBA abgelegt waren nun ungültig geworden sind. Genau das kann man ihnen mit TRIM auch ohne das Überschreiben der Daten mitteilen, eben wenn die Datei gelöscht wird zu der die Daten gehören. Mehr macht TRIM nicht und es ist nur dafür da hinterher mehr Daten schneller Schreiben zu können. Das spielt z.B. bei Enterprise SSD oft gar keine Rolle weil bei viele Enterpriseanwendungen wie Datenbanken oder auch den Images von VMs die Dateien nie gelöscht werden, sondern immer nur darin etwas überschrieben wird, wobei gar keine TRIM Befehle zum Einsatz kommen, sie wären auch unnötig, da das Überschreiben der SSD die gleiche Information liefert.

Aber bei der Nutzung über iDE oder einen PCI Adapter ist das egal, da wird er nur so 100MB/s schaffen und die schreiben auch SSD wenn sie lange nicht getrimmt wurden. Bei solchen mit einem Pseudo-SLC Schreibcache ist TRIM auch nicht so wichtig, denn die leeren den Cache ja immer wieder im Idle und könn ihn daher immer wieder schnell beschreiben und um eine bessere Schreibgeschwindigkeit geht es bei TRIM vor allem.
 
Zuletzt bearbeitet:
Den Sandfroce Controllern ist TRIM nicht egal weil sie es nicht bräuchten, sondern weil sie sowieso wenig davon profitieren, denn die Löschen bei einer Idle-GC die freigeräumten NANDs nicht, sondern machen dies immer erst während eines Schreibzugriffs und daher wird die Schreibperformance nach dem erstmaligem Beschreiben alle Pages abfallen, egal ob mit oder ohne TRIM. Damit passiert genau das, was TRIM eigentlich verhindern soll, also sowieso. Was sollte das denn sein? Eine Idle-GC haben alle, auch der Sandforce und wenn die nicht genug NAND freimachen kann, müssen alle SSD dies während eines Schreibvorgangs machen und dann bricht die Schreibrate eben ein, dies ist aber einem bestimmten Schreibvolumen am Stück einfach nicht zu verhindern. Was die Sandforce wie gesagt anderes machen ist, dass sie nicht wie die anderen im Rahmen der Idle-GC die NAND Blöcke löschen und dann räumt die Idle GC bei denen nur so viel frei wie ab Werk als OP zur Verfügung steht. So ein Unsinn, das eine hätte mit dem anderen auch nichts zu tun. Keine SSD ist auf TRIM angewiesen, die wissen alle auch beim Überschreiben eines LBAs das die Daten die vorher unter diesem LBA abgelegt waren nun ungültig geworden sind. Genau das kann man ihnen mit TRIM auch ohne das Überschreiben der Daten mitteilen, eben wenn die Datei gelöscht wird zu der die Daten gehören. Mehr macht TRIM nicht und es ist nur dafür da hinterher mehr Daten schneller Schreiben zu können. Das spielt z.B. bei Enterprise SSD oft gar keine Rolle weil bei viele Enterpriseanwendungen wie Datenbanken oder auch den Images von VMs die Dateien nie gelöscht werden, sondern immer nur darin etwas überschrieben wird, wobei gar keine TRIM Befehle zum Einsatz kommen, sie wären auch unnötig, da das Überschreiben der SSD die gleiche Information liefert.

Aber bei der Nutzung über iDE oder einen PCI Adapter ist das egal, da wird er nur so 100MB/s schaffen und die schreiben auch SSD wenn sie lange nicht getrimmt wurden. Bei solchen mit einem Pseudo-SLC Schreibcache ist TRIM auch nicht so wichtig, denn die leeren den Cache ja immer wieder im Idle und könn ihn daher immer wieder schnell beschreiben und um eine bessere Schreibgeschwindigkeit geht es bei TRIM vor allem.

Sry wegen Fullquote aber beim lesen deines Beitrags (egal ob man diesen als fachlich richtig betrachten möchte oder nicht) gingen mir sofort die Worte Kinderstube und Düsenjäger durch den Kopf....
 
Ich denke mal der TE braucht hier mal "Praxis" Erfahrung, die er bei mir haben kann.

Habe mir für mein damaliges Abit AV8-Pro das nur einen VIA-SATA I bzw. VIA-IDE Controller hat einen Lindy SATA-II -> IDE Konverter gekauft. Auf diesem sitzt ein Marvel Brückenchip und hatte den mit 3 SSDs betrieben, einer Intel G2 mit 160GB, einer Crucial M4 mit 128GB und einer Samsung 830 mit 128GB*

Dabei erreichte ich Raten um die 100MB im lesen/schreiben von der Kompatibilität lief die 830er Samsung am besten. Die anderen liefen nicht wirklich gut daran, als Festplatten noch WD VR mit 320GB etc.

Booten ergibt sich von selbst, über das Bios des Mainboards. Brauchte es nur anwählen und es konnte davon gebootet werden.

Somit spricht nichts dagegen einen solchen Konverter mit einer kleinen SSD an einem alten Rechner zu betreiben sofern man das möchte.

Als System lief Windows 7 drauf, meine sogar das "Trim" dennoch bei dieser Kombination möglich sein kann. Habe es aber nicht getestet, bzw. nicht mehr möglich da ich das Bundle bis auf den Prozessor entsorgt habe.

Den Konverter incl. kurzem UDMA-100/133er Rundkabel habe ich noch hier falls Interesse besteht.

Mein Beitrag zum Konverter aus dem SSD-Sammelthread anno 2013
 
Zuletzt bearbeitet:
Da haben sie wieder ein neues Wort erfinden, dabei ist das was sie dort als "foreground GC" eigentlich die Situation in die man nicht kommen möchte und dies mit TRIM möglichst zu vermeiden sucht, sofern eben Dateien gelöscht wurden und damit mehr freier Platz zur Verfügung steht. Dies jetzt positiv zu vermarkten ist eigentlich eine Frechheit, aber es fallen eben immer wieder Leute darauf rein. Im Erfinden von fantasievolle Namen für selbstverständliche Dinge war Sandforce immer schon groß, aber scheinbar hat Seagate den Laden ja wohl eingestampft und damit der Welt einen Gefallen getan, denn wirklich gut waren die nur im Bescheißen bei Benchmarks. Aber wie gesagt dar man über IDE oder PCI sowieso keine wirklich gute Performance erwarten, dafür ist die Bandbreite beider Schnittstellen zu schlecht.
 
Zurück
Oben Unten