Solid State Drive (SSD) (Part 7|2)

Status
Für weitere Antworten geschlossen.
dancingdwarf schrieb:
Danke, werde ich ausprobieren!
Zum Vergrößern anklicken....

Da kann ich nur vor warnen. Meine Performance ist drastisch gesunken. Ich muss Systemwiederherstellung nutzen. Bei nem Kumpel hats allerdings 20MB/s mehr gebracht.

---------- Beitrag hinzugefügt um 22:58 ---------- Vorheriger Beitrag war um 22:58 ----------

So, andere interesante News:
Die Mikrohänger unter extremer Last bei den Intels wurden durch TrueCrypt ausgelöst...habe mal entschlüsselt..nun sind sie weg...the price of security
Die IOPS sind mit TrueCrypt gradmal halb so hoch wie ohne....

Also wieder klare Empfehlung für die M...hätt ich mir doch fast ne E gekauft und es wäre völlig umsonst gewesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
interessant, quelle? Screens?
 
schnarx schrieb:
True Crypt 6.2 released:

New Features:
"The I/O pipeline now uses read-ahead buffering, which improves read performance especially on solid-state drives, typically by 30-50%. (Windows)"
Zum Vergrößern anklicken....

Danke für die Info.
Na, dann schauen wir mal. :d

btw. Auf meinem NB wird das sicher nicht viel bringen, da CPU-limitiert.
Aber schauen wir mal...
 
Zuletzt bearbeitet:
Bei einer HDD ja, aber bei Flash Speicher? Warum soll sich Zeit sparen lassen, es muss doch kein Lese-/Schreibkopf platziert werden
 
KRambo schrieb:
Bei einer HDD ja, aber bei Flash Speicher? Warum soll sich Zeit sparen lassen, es muss doch kein Lese-/Schreibkopf platziert werden
Zum Vergrößern anklicken....

Ja, aber die Zugriffszeit ist trotzdem nicht 0. 0.1 ja, aber halt nicht 0 ;)
Und wenn eine Datei in 3 Teile gesplittet ist, hast du 3x 0.1 statt 1x 0.1
 
KRambo schrieb:
Was bringt ne Defragmentierung auf Flash-Speicher? :confused:
Zum Vergrößern anklicken....
bei den eigenen SSDs bringt es laut Mtron etwas bei der Schreibleistung.
Eventuell "räumt" der Controller beim Defragmentieren auf der SSD etwas auf.
Von daher würde ich mal sagen, es hängt von der jeweiligen SSD ab, ob es was bringt.
Die Intel räumt ja anscheinend bereits auf, wenn größere Dateien geschrieben werden, oder?
Von daher kann man da wohl auf eine Defragmentierung verzichten.

ciao Tom
 
Tag aber auch :-P

hat eigentlich jemand von euch ssd-spezialisten mal das neue exFAT Dateisystem getestet auf einer SSD?
Dies soll ja angeblich schneller und besser sein wie FAT32/NTFS und speziell für Flash-Speicher angepasst sein.

LG
 
Die minimalen Vorteile merkt man da in der Realität nicht, daher hat NTFS mit seinem Journal einfach die überzeugenderen Argumente.
 
also ich habs (exFAT) mal kurz auf einem usb stick getestet.
es war zwar schneller wie fat und fat32, aber um welten langsamer wie ntfs. :-/
 
was eigentlich gar nicht sein kann, da fat32 auf 'nem usb stick schneller als ntfs sein sollte.
 
KRambo schrieb:
Bei einer HDD ja, aber bei Flash Speicher? Warum soll sich Zeit sparen lassen, es muss doch kein Lese-/Schreibkopf platziert werden
Zum Vergrößern anklicken....

Ich kann mir nur vorstellen, dass der Verwaltungsaufwand im Controller geringer wird, der evtl. auch auf die Perf. Einfluss haben könnte.

So wäre es für den Controller einfacher sich für die Datei die 2 Zahlen von - bis (zb Sektor 40.000 - 50.000) zu merken als hunderte oder gar tausende bei stark fragmentierten Dateien.

Ist aber nur eine Vermutung ;)
 
Zuletzt bearbeitet:
ist es nicht so, dass bei den Controller mit Write Combining & mehreren Kanälen eine gewisse fragmentierung gewünscht ist um mit allen Kanälen gleichzeitig zu lesen? Da wäre eine Defragmentierung zugar schlecht, bzw müsste so eingestellt sein dass sie die Daten jeweils auf z.b. 10 Kanäle des Controllers gleichmäßig verteilt.
 
WaDenKraMpF schrieb:
ist es nicht so, dass bei den Controller mit Write Combining & mehreren Kanälen eine gewisse fragmentierung gewünscht ist um mit allen Kanälen gleichzeitig zu lesen? Da wäre eine Defragmentierung zugar schlecht, bzw müsste so eingestellt sein dass sie die Daten jeweils auf z.b. 10 Kanäle des Controllers gleichmäßig verteilt.
Zum Vergrößern anklicken....

Nein, ganz im Gegentail.
Im write combining kann der Kontroller daten viel schneller auf als komplett leer markierte Blöcke speichern, als auf teilgefüllte.
 
bis etwa einer Partitionsgrösse von 32gb... danach ist NTFS vorzuziehen.
so hatte ichs jedenfalls in Erinnerung
 
Hab bei Win7 RC 64-bit die Leistungsnote 5,9 für die Primäre Festplatte (Mobi 3525 16 GB), was habt Ihr mit den Vertex bzw. Intel X25-M/E oder Samsung PB22-J? (übrigens im AHCI-Mode installiert und genutzt)
 
Ich habe 7.0 mit UD 64GB

Aber die Leistungsindex ist verbugt, einer hat wohl mit HDD die 7.0 erreicht
 
Zuletzt bearbeitet:
schon gelesen? PRAMfür die neue SSD Generation.
Die gehen dann bestimmt ab wie ein Zäpfchen..
Bin mal auf genaueres gespannt und vorallem auf den Releasezeitraum und -preis.
 
Bei mir 7,2 mit einzelner UD ME 256GB und Firm 1370 auf Win7 RC
 
Zuletzt bearbeitet:
Grinsemann schrieb:
schon gelesen? PRAM für die neue SSD Generation.
Die gehen dann bestimmt ab wie ein Zäpfchen..
Bin mal auf genaueres gespannt und vorallem auf den Releasezeitraum und -preis.
Zum Vergrößern anklicken....

Hui, endlich kommt Bewegung rein, wurd auch langsam Zeit.
 
WaDenKraMpF schrieb:
ist es nicht so, dass bei den Controller mit Write Combining & mehreren Kanälen eine gewisse fragmentierung gewünscht ist um mit allen Kanälen gleichzeitig zu lesen? Da wäre eine Defragmentierung zugar schlecht, bzw müsste so eingestellt sein dass sie die Daten jeweils auf z.b. 10 Kanäle des Controllers gleichmäßig verteilt.
Zum Vergrößern anklicken....

Achtung - Write Combining fragmentiert nicht die Daten auf der Platte (Dateifragmentierung gibt es bei SSDs nicht), sondern die LBA-Tabelle! Ich hab jetzt 10 Minuten rumgesucht um diesen Artikel irgendeines Französischen Magazins zu finden wo das aufgeschlüsselt war, aber leider ohne Erfolg...

Ich versuch's mal zusammenzufassen:

1. Betriebssystem schickt viele random writes an aufeinanderfolgende LBAs (25, 26, 27, 28 etc.)
2. In der SSD sind diese LBAs per Wear Leveling quer über alle Blöcke vermappt
3. Write Combining Algoritmus merkt was und sagt: halt, warum in zwanzig Blöcke schreiben, was auch in einen einzigen Block passt!
4. SSD puffert die random writes im Cache und schreibt dann die gesamte Gruppe sequentiell in einen Block, der mit völlig anderen LBAs gemappt ist (zb. 57, 3482, 2, 178 etc.)
5. SSD reorganisiert ihre LBA-Tabelle, indem sie einfach umetikettiert: 25 = 57, 26 = 3482, 27 = 2, 28 = 178 und so weiter.

Das Problem dabei: wenn sehr sehr viele random writes durch dieses Verfahren in sequentielle writes umgewandelt wurden... dann ist der nächste anstehende sequentielle Zugriff im Gegenteil plötzlich random, weil die LBA-Tabelle so konfus umgeschrieben wurde!

Das ist das was man im allgemeinen unter Blockfragmentierung versteht.
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh