SSD UltraDrive Supertalent / OCZ Vertex SSD / Indilinx Barefoot Controller [Part 3|2]
- Ersteller SSDfix
- Erstellt am
- Status
Svebu
Neuling
würde mich auch intressieren!
Naja, es kann ja sein, dass da irgendwas Wahres dran ist, das dann falsch verstanden, durch 3 Kanäle und wasweißich gegangen ist und 4x hin und her übersetzt wurde - dann wird aus einer zurückgegangenen Charge Chips schon mal ein Komplettausstieg.
« Entre
Ce que je pense,
Ce que je veux dire,
Ce que je crois dire,
Ce que je dis,
Ce que vous avez envie d‘entendre,
Ce que vous croyez entendre,
Ce que vous entendez,
Ce que vous avez envie de comprendre,
Ce que vous comprenez,
Il y a dix possibilités qu‘on ait des difficultés à communiquer.
Mais essayons quand même… »
Hatten wir grad in der Vorlesung
Wie wirkt sich das eigentlich schlussendlich aus? Welche Einschränkungen habe ich durch diese Veränderung? Geht es nur um den Zugriff oder auch um Änderungen? Kann dann z.B. mein Syncprogramm nichtmehr auslesen ob eine Datei geändert wurde oder nicht?
Zuletzt bearbeitet:
Dampfkanes
Legende
@FB07
die erste Partition hat doch 1024 KB.
Der Beginn der zweiten richtet sich nach der Größe der ersten und dem Alignment der ersten (1024 KB=1 MB + 100 MB Partitionsgröße=101 MB) offset für die zweite Partition.
zu dem Vergleichsscreen der Alignments:
2048, 256 und 128 sollten ja auch alleine deswegen keinen Unterschied liefern, da sie alle ganzzahlige vielfache von 128 sind. 128 ist doch das Optimum für die Vertex, oder?
allenfalls hätte ich dann einen Unterschied zwischen 64 und 128 erwartet.
Wenn man in der Richtung schon schaut, dann sollte man ein Alignment nehmen, was kein ganzzahliges Vielfaches des optimalen Alignments ist (sprich entweder krumm oder kleiner).
ciao Tom
die erste Partition hat doch 1024 KB.
Der Beginn der zweiten richtet sich nach der Größe der ersten und dem Alignment der ersten (1024 KB=1 MB + 100 MB Partitionsgröße=101 MB) offset für die zweite Partition.
zu dem Vergleichsscreen der Alignments:
2048, 256 und 128 sollten ja auch alleine deswegen keinen Unterschied liefern, da sie alle ganzzahlige vielfache von 128 sind. 128 ist doch das Optimum für die Vertex, oder?
allenfalls hätte ich dann einen Unterschied zwischen 64 und 128 erwartet.
Wenn man in der Richtung schon schaut, dann sollte man ein Alignment nehmen, was kein ganzzahliges Vielfaches des optimalen Alignments ist (sprich entweder krumm oder kleiner).
ciao Tom
Zuletzt bearbeitet:
Nein, da du einfach 8*128KB alignt hast, statt 1*128... ob in den 7 Sektoren jetzt Daten stehen oder nicht ist ja egal - wichtig ist, dass die Datenblöcke auf Flashblöcke passen. Ob das überhaupt bei SSDs eine Rolle spielt die einfach irgendwohin schreiben und nicht wie früher die Mtrons oder JMicrons Daten + Flashblock eng koppeln ist ne andere Frage...
Habe gerade meine ST UD MLC 128GB bekommen, ausgepackt und ich hab scheinbar eine neue Charge erwischt. Die Seriennummer ist ....-HCIX-... Firmware Version und Benches liefere ich sofort wenn ich in der Stadt war und nen Sata-Kabel gekauft habe 
edit: wie versprochen, Bench, Firmware ist wie SSDFix sagte 1370.
edit: wie versprochen, Bench, Firmware ist wie SSDFix sagte 1370.
Anhänge
Zuletzt bearbeitet:
Thread Starter
- Mitglied seit
- 21.07.2008
- Beiträge
- 1.703
Habe gerade meine ST UD MLC 128GB bekommen, ausgepackt und ich hab scheinbar eine neue Charge erwischt. Die Seriennummer ist ....-HCIX-... Firmware Version und Benches liefere ich sofort wenn ich in der Stadt war und nen Sata-Kabel gekauft habe
die CIX haben die 1370 drauf
@*******: Ich habe mein XP und mein Win7 einmal defragmentiert. Leider ist das Dateisystem ja nicht das allerbeste, daher die hohe Fragmentierung. XP lief schon länger, das hat sogar richtig was gebracht das zu defragmentieren. Ich denke solange man das nicht alle paar Wochen macht kann es nicht Schaden das mal durchzuführen. Die Flashzellen halten schon lange genug 
nsa666
Semiprofi
- Mitglied seit
- 07.08.2008
- Beiträge
- 2.266
Was mich dann wundert, ist dass sie die neue Firmware nicht auf ihre Seite hochgeladen haben.
Master Luke
Enthusiast
DerRob
Enthusiast
- Mitglied seit
- 01.10.2006
- Beiträge
- 619
Bei einer SSD hast du aber auch noch einzelne Datenblöcke, und wenn die Datei komplett aus einem einzelnen z.B. 32kb großen Datenblock gelesen werden kann, geht das auch noch etwas schneller, als wenn die Datei in (übertrieben) 4kb großen Häppchen aus 8 verschiedenen Datenblöcken zusammen gesucht werden muss.
Der Arbeitsspeicher ist ja nochmal eine ganze Ecke schneller, trotzdem ist die Burst-Rate aus einem zusammenhängenden Stück Speicher auch eine ganze ecke schneller, als wenn jedes Byte einzeln aus verschiedenen Ecken vom Speicher gelesen werden muss.
Zuletzt bearbeitet:
Ein Defrag kann auf einer SSD garnicht funktionieren, da das OS keine physischen Adressen sieht, die neu zugewiesen werden können. Einzig der Controller der SSD weiß wirklich, was er wo lesen muss. Abgesehen davon wird der Controller beim defragmentieren die Dateien nicht in einzelne Blöcke schreiben, sondern eben die Zellen nutzen, die noch am Wenigsten abgenutzt sind. Daher verkürzt es auch die Lebensdauer der SSD.
Wie soll Defrag das bestimmen? Der Controller emuliert die Adressen, die eine normale HDD hat nur, und letztendlich ist er es, der aufgrund seiner internen Abnutzungsdatenbank entscheidet, in welche Zellen er schreibt. Kann natürlich sein, daß nach dem Defrag den Anschein hat, als wären die Daten nicht fragmentiert.
Also ich kann nur bei XP sagen das sich die Bootzeit um ca. 5 sek. verkürzt hat.
Defrag sorgt meines Erachtens dafür, das Dateien immer einen vollen Block belegen und nicht verteilt sind auf versch. Blöcke. Aber es spielt natürlich keine Rolle wo der Block nun ist, Hauptsache ist doch aber das ein Block nur eine Datei beinhaltet. Und wenn die Blockgröße groß ist, dann macht das schon was aus.
Wie groß ist die Blockgröße nochma bei den indilinx Controllern?
Defrag sorgt meines Erachtens dafür, das Dateien immer einen vollen Block belegen und nicht verteilt sind auf versch. Blöcke. Aber es spielt natürlich keine Rolle wo der Block nun ist, Hauptsache ist doch aber das ein Block nur eine Datei beinhaltet. Und wenn die Blockgröße groß ist, dann macht das schon was aus.
Wie groß ist die Blockgröße nochma bei den indilinx Controllern?
nsa666
Semiprofi
- Mitglied seit
- 07.08.2008
- Beiträge
- 2.266
@pajaa du vergisst dass die hier besprochenen SSDs ein internes RAID haben und deswegen die Datenrate von sequentiellen Lesen wesentlich höher ist als das von zufälligem Lesen(siehe Crystalmark-Ergebnisse). Und außerdem entsprechen dateisystem-Sektorgrößen nicht den SSD-Sektorgrößen. Deswegen kann defragmentieren bei bestimmten Zugriffsmustern sinnvoll sein.
Zuletzt bearbeitet:
Demnach macht Defrag einen Sinn, wenn man eine MLC-SSD hat, einfach um die Zellen mit Daten zu füllen, die auch wirklich gebraucht werden, wenn sie etwas aus der Zelle angefordert wird.
"Internes RAID"
Nein, das habe ich nicht vergessen, hat doch jeder moderne Controller mehrere Kanäle, allerdings ist er immernoch bestrebt, alle Zellen gleichmäßig zu nutzen.
"Internes RAID"
Nein, das habe ich nicht vergessen, hat doch jeder moderne Controller mehrere Kanäle, allerdings ist er immernoch bestrebt, alle Zellen gleichmäßig zu nutzen.
Zuletzt bearbeitet:
nsa666
Semiprofi
- Mitglied seit
- 07.08.2008
- Beiträge
- 2.266
Probleme fangen da an, wenn die Datei nur an einem Kanal liegt(und somit nur 1/8 des Blockes belegt), muss der Controller ganzen Block lesen und 7/8 der Daten aus dem Block verwerfen.
Das ist nur die Default-Einstellung.
- Status