SSD UltraDrive Supertalent / OCZ Vertex SSD / Indilinx Barefoot Controller [Part 5|1]

Status
Für weitere Antworten geschlossen.
ist das eine umkonfigurierte 1711, so wie die 1.4, 1.41 1.4b o.ä. bei OCZ oder ist das ein neuer Build mit neuer Nummer. Bei den OCZ 1711 Varianten kann man ja hin und her wechseln. Zwischen den Buildnummern ist das downgrade schwierig.

Welche Verbesserungen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
also ich würde ja nieeee im leben meine system SSD unter windoof Flashen...
mach doch mal für nen bruchteil einer sekunde den strom von deiner SSD während du in windoof bist... was passiert.... genau... blue screen... und jetzt überleg mal was da wärend des flashens höchstwahrscheinlich passieren würde... genau der flash würde mitten drin abgebrochen weil je für nen bruchteil die SSD nichtmehr existend wäre für windoof und was wäre dann... genau... RMA.
Achso - klar im DOS haste natürlich keinen Stromausfall:lol:
 
HI leute
Habe nun meine ST 128gb bekommen läuft einwandfrei Firmeware ist die 1571 drauf :hail: das einzige was mir aufgefallen ist das ich ein schwarzes schönes Gehäuse habe ohne jeglichen Schriftzug ,haben das den alle dachte da würde Super Talent draufstehen.Habe gleich einen HDTune Bench gemacht Vollgendes Ergebniss kam raus:


Gegenüber alls vergleich meine alte Core V2:


Bin schwer zufrieden danke für die Informationen und beratungen hier :wink:
 
Zuletzt bearbeitet:
Mh naja, im DOS dauert das FW-Update (da nicht destruktiv wohl) keine Sekunde, in Windows viel länger, also ist die Chance kleiner, dass genau zu der Zeit ein Stromausfall die SSD plättet :d

Das Problem von Windows-flashern ist halt, dass sie nur auf Windows laufen, was für andere User doch etwas blöder sein kann.
 
Die neuen Gehäuse von ST haben den Schriftzug leider nicht mehr drauf.
 
Was nichts daran ändert, dass man W7 noch nicht produktiv einsetzen sollte - zumindest sollte das jeder gesunde Menschenverstand sagen...

Warum? Es ist ein fertiges Betriebssystem, läuft objektiv besser als die Vorgänger, unterstützt Vista-Treiber (für die wenigen Geräte, die nicht ohnehin schon direkt unterstützt werden), usw.

Nur weil 1 Firma (Indilinx) es nicht schafft, eine fehlerfreie Firmware zu entwickeln, bzw. hinreichend zu testen vor der Veröffentlichung, hält das doch niemanden davon ab, auf Win7 umzusteigen.

Ich verstehe diese "Angstmache" vor Win7 überhaupt nicht. Wie gesagt, es läuft schon seit der Beta besser als Vista und unterstützt mehr Software und Hardware als XP.

Wenn man was nicht produktiv einsetzen sollte, dann ist das Vista, aber sicher nicht Win7...

LG!
 
Die neuen Gehäuse von ST haben den Schriftzug leider nicht mehr drauf.

Danke für die Info. Hab mich schon gewundert; dachte im ersten Augenblick an "ominösen Grauimport"! :d

---------- Beitrag hinzugefügt um 12:09 ---------- Vorheriger Beitrag war um 12:00 ----------

Warum? Es ist ein fertiges Betriebssystem, läuft objektiv besser als die Vorgänger, unterstützt Vista-Treiber (für die wenigen Geräte, die nicht ohnehin schon direkt unterstützt werden), usw.

Nur weil 1 Firma (Indilinx) es nicht schafft, eine fehlerfreie Firmware zu entwickeln, bzw. hinreichend zu testen vor der Veröffentlichung, hält das doch niemanden davon ab, auf Win7 umzusteigen.

Ich verstehe diese "Angstmache" vor Win7 überhaupt nicht. Wie gesagt, es läuft schon seit der Beta besser als Vista und unterstützt mehr Software und Hardware als XP.

Wenn man was nicht produktiv einsetzen sollte, dann ist das Vista, aber sicher nicht Win7...

LG!

Win 7 läuft doch hervorragend mit FW 1571 und man kann durchaus "produktiv" damit arbeiten!

Und irgendwann kommt dann auch en vernünftiges FW-Update von SST; da bin ich mir sicher!:angel:
 
Unter Linux gibt es mit TRIM keine Probleme.
Da die 1711 die erste FW war die TRIM unterstützt besteht immer noch die Möglichkeit, dass es ein Fehler in einem Windows Treiber sein kann. Bei MS konnte ja auch keiner TRIM testen mangels passender FW.
Wenn ein neues BS erscheint gibt es immer Treiber und FW Probleme in unterschiedlichen Ausprägungen.
Wenn TRIM unter Linux mit 1711 einwandfrei läuft, kann man umgekehrt auch schlussfolgern, dass es eben doch an WIn7 liegen kann.

Mit der 1711 wurde ein neues feature freigeschaltet, das von einem neuen BS unterstützt wird. Der fehler tritt nur mit TRIM auf (ich selbst zB hab meine UD immer noch mit 1711 unter Vista 64 laufen OHNE Probleme) und deswegen kann es einfach auch am MS Treiber liegen?
Magst Du nun behaupten MS hat keine bugs in seiner software?
 
Zuletzt bearbeitet:
Unter Linux gibt es mit TRIM keine Probleme.
Da die 1711 die erste FW war die TRIM unterstützt besteht immer noch die Möglichkeit, dass es ein Fehler in einem Windows Treiber sein kann. Bei MS konnte ja auch keiner TRIM testen mangels üpassender FW.
Wenn ein neues BS erscheitn gibt es immer Treiber und FW Probleme in unterscheidlichen AUsprägungen.
WEnn TRIM unter Linux mit 1711 einwandfrei läuft, kann man umgekehrt auch schlussfolgern, dass es eben doch an WIn7 liegen kann.

Mit der 1711 wurde ein neues feature freigeschaltet, das von einem neuen BS unterstützt wird. Der fehler tritt nur mit TRIM auf (ich selbst zB hab meine UD immer noch mit 1711 unter Vista 64 laufen OHNE Probleme) und deswegen kann es einfach auch am MS Treiber liegen.
Magst DU nun behaupten MS hat keine bugs in seiner software?

In Linux gibt es exakt dieselben Probleme wie unter Win 7.
Nur bemerkt das kein Mensch, weil TRIM noch von keinem Kernel
unterstützt wird. Man muss per Hand den Source Code patchen und
dann seinen eigenen Kernel bauen. Ich habe es ausprobiert und es
war schrecklich. Das ganze System ist nach einer kurzen Zeit
absolut unbrauchbar, da der Kernel auf die SSD wartet, die ewig
für die Verarbeitung der TRIM Befehle braucht (der Kernel sendet
einen TRIM Befehl für jedes Extent jeder gelöschten Datei).
Wenn man das System lange genug in diesem Zustand laufen
lässt hat man sehr schnell ein korruptes Filesystem...
 
In Linux gibt es exakt dieselben Probleme wie unter Win 7.
Nur bemerkt das kein Mensch, weil TRIM noch von keinem Kernel
unterstützt wird. Man muss per Hand den Source Code patchen und
dann seinen eigenen Kernel bauen. Ich habe es ausprobiert und es
war schrecklich. Das ganze System ist nach einer kurzen Zeit
absolut unbrauchbar, da der Kernel auf die SSD wartet, die ewig
für die Verarbeitung der TRIM Befehle braucht (der Kernel sendet
einen TRIM Befehl für jedes Extent jeder gelöschten Datei).
Wenn man das System lange genug in diesem Zustand laufen
lässt hat man sehr schnell ein korruptes Filesystem...

Ich meine hier gelesen zu haben, dass ein user sagte dass 1711 unter linux einwandfrei läuft....
Anyway, Indilinx kümmert sich aktuell um eine Lösung.
 
@ Kat-CeDe und @antiram
Also, habe ein Lappi, 965Express-Chipsatz, nur AHCI möglich, und da muß das Problem liegen, -vermute ich-
Fedora läuft mit jeder FW problemlos bei mir, nur Ubuntu-Derivate (Ubuntu selbst, oder Mint...etc.) haben Probleme mit einigen FW Versionen, die ich schon nannte,
auch wenn Linux nicht selbst auf der ssd installiert ist, sonder auf einer anderen hdd
 
der fehler trat mit btrfs auf, das ist alpha. fehler trat ab block 18446744073709551615 auf, ab 70368744177663 GIGABYTE kamen fehler...
http://www.ocztechnologyforum.com/forum/showthread.php?p=424883#post424883

ich hab mal das W7 trim mit den linux trimpatches verglichen.
ca. 30000 Dateien = 326MB löschen

das w7 schickt danach alle 10s 1 trim raus. Das geht ein paar Minuten so. Dann ist wieder ruhe und es kommt nur noch manchmal ein trim. sehr schön.

Die linuxpatches ballern dagegen so schnell so EXTREM viele trims raus, keine chance mitzuzählen. trotzdem gabs bei den tests von mark lord keine dateisystemfehler
http://www.ocztechnologyforum.com/forum/showthread.php?p=424839#post424839

Ich hab hier ein in kvm(drin rumgefrickelt) installiertes w7 rc. hat filesystemfehler, komplett erledigt. DA WURDE NIEMALS EIN SEKTOR DURCH TRIM GELÖSCHT. Kann natürlich auch an der frickelei liegen, aber unwahrscheinlich weil meine frickelei nichts schreibt. vielleicht aber kurze verzögerungen hervorruft?
 
Zuletzt bearbeitet:
der fehler trat mit btrfs auf, das ist alpha. fehler trat ab block 18446744073709551615 auf, ab 70368744177663 GIGABYTE kamen fehler...

;-) . OK, die Frage ist nur wo die 18446744073709551615 her kommt?
Aber du hast Recht, es könnte ein von TRIM unabhängiges Problem sein.


antiram schrieb:
ich hab mal das W7 trim mit den linux trimpatches verglichen.
ca. 30000 Dateien = 326MB löschen

das w7 schickt danach alle 10s 1 trim raus. Das geht ein paar Minuten so. Dann ist wieder ruhe und es kommt nur noch manchmal ein trim. sehr schön.

Die linuxpatches ballern dagegen so schnell so EXTREM viele trims raus, keine chance mitzuzählen. trotzdem gabs bei den tests von mark lord keine dateisystemfehler.

Ja, ich hoffe die nächste Version der TRIM Patches von Matthew Wilcox
wird sich dann ähnlich wie Win7 verhalten.

antiram schrieb:
Ich hab hier ein in kvm(drin rumgefrickelt) installiertes w7 rc. hat filesystemfehler, komplett erledigt. DA WURDE NIEMALS EIN SEKTOR DURCH TRIM GELÖSCHT. Kann natürlich auch an der frickelei liegen, aber unwahrscheinlich weil meine frickelei nichts schreibt. vielleicht aber kurze verzögerungen hervorruft?

Interessant. Das ganze lief auf der SSD? Und wann traten die
Fehler auf? Sofort nach der Installation?
 
@SSDFix,
die Release-Linux-Versionen haben Trim noch nicht drin wie schon gesagt. Bei Linux wird die heiße Trim-Phase wohl im September/Oktober beginnen wenn die neuen Distris rauskommen die wohl auf Kernel 2.30/2.31 besieren werden.

Nachdem was ich hier gelesen habe muß da aber wohl noch gearbeitet werden. Falls ein Trim bei einer ST wirklich bis zu 100ms braucht kann es in Linux nicht so bleiben wie es jetzt, richtigerweise, gedacht ist.

Ralf
 
So bin wieder zurück unter den SSDlern ;-).

Vielen Dank an SSDfix für den schnellen Austausch.
Am Sa eingeschickt. Heute eine nagelneue SSD mit Firmware 1571 zurückbekommen und es läuft wieder!

:hail: :d
 
Interessant. Das ganze lief auf der SSD? Und wann traten die
Fehler auf? Sofort nach der Installation?
das kvm image lag auf einem ext3 auf einem lvm auf einer western digital mit echten platten und köpfen. ext3 war fehlerfrei.

die w7 installation hab ich installiert als der rc rauskam auf einem ide.c das wie eine festplatte aussieht. später sah die ide.c wie eine ssd aus, dh. hat trim ready gemeldet, aber das trim command hat ide.c mit einem fehler beantwortet (wie 1571). W7 ignoriert die Fehlerantworten und schickt trotzdem weiter die trims. hab dann mit karmic mit .29 und allen trimpatches weitergemacht damit ide.c fehlerfrei mit ready antwortet. am nächsten tag war die w7 installation beim ersten boot damit erledigt. eine zweite neue installation ist nach derzeit ca. 10-15 boots und 2-3h Betriebszeit fehlerfrei.
 
Zuletzt bearbeitet:
Nachtrag zur sehr geringen Minimal und Average Transfer Rate:




Die war deswegen so niedrig, weil ich währenddessen von ner alten HDD auf die neue Seagate 1.5 TB ~ 400 GB Daten geschoben hab !

Das kam mir doch ein bisschen wenig vor, als ich den Vergleichswert zur 128er gesehen hab ! :fresse:

ja das sieht schon viel besser aus :d
 
Ähm mal ne frage hat hier jemand auf seine ssd win7 installiert und dan im bootmenü auf löschen gedrückt dann partition erstellen wenn ja kann mir einer erklären warum da automatisch eine kleine partition erstellt wird mit 100mb?

AH sorry gefunden ;) wenn es jemand nicht weiss hier steht warum

On a fresh installation of Windows 7, the installer will create the Bitlocker partition. If you do not intend to use Bitlocker, this partition can be subsequently removed.

The 100MB system/boot partition will be available for Ultimate, Business and Enterprise editions.
 
Zuletzt bearbeitet:
Ich habe eigentlich bisher keine Probleme mit der 1711-Firmware unter Windows 7. TRIM ist eingeschaltet und im Gegensatz zur älteren Firmware habe ich bisher keine Performance-Einbußen zu verzeichnen. Bei der alten Firmware musste ich schon einmal manuell trimmen - und das schon nach einer knappen Woche nach Kauf (Schreibraten auf 15-30 MB runtergesackt). Mit der neuen Firmware sind die Schreibraten immer gleich gut. Ich verwende ein AMD 785G Motherboard mit SB710.
 
Zuletzt bearbeitet:
Geht ganz einfach die während der Installation zu entfernen:

Partition erstellen (bei der Meldung ja drücken), die Partition C: (wo das System draufkommen würde) löschen, danach die System Reserved anwählen und mit der gelöschten (unallocated) mergen - feddisch.
 
Benchmarkmäßig geht meine ST-GX mit aktuelle Firmware mittlerweile ganz schön in die Knie. Aber unter Realbedingungen merke ich davon eigentlich nicht wirklich was. Ab und an muss ich noch XP von meiner HD booten und dann ist es immer wieder ein Genuss auf Win7 auf SDD zu arbeiten. :)
 
Ich habe jetzt seit erscheinen die 1711 Firmware drauf, mit dem Freespace Cleaner hat es bereits getrimmt.

Eben hab ich aber mal AS SSD bemüht: und die ssd war eingebrochen. Manueles ausführen der wiper.exe brachte wieder volle geschwindigkeit, obwohl Trim in Win7 eingeschalten ist...

das letztens erwähnte datei korruptionsproblem tauchte bisher derweil nicht wieder auf.
 
Hi Leute, ich bin ma wieda da,

so hab ein Problem mit meiner Ultradrive, wollte heute meinen PC starten, und nix, kein boot up, un zwar stand dann da dass es keine st mehr sein würde sondern eine yatapdong barefoot etc mit 137gb, also nicht mehr meine st mit 64 gb sondern nur der controller?
also ich weiss nich mehr weiter, hab alles normale gemacht, sprich:
batterie raus, vom netz, sata kabel gewechselt, cmos reset, etc.

hab dann gegoogelt un scheint auch kein wirkliche hilfe für dieses Problem zu geben, also muss ich das gute stück wohl einschicken, firmware war die alte 15er, hab die seriennummer mit tix und das gute stück wurde im IDE modus genutzt.


wie siehten des aus mit Garantie, läuft die wie bei ocz auch über den Hersteller oder geht das Über den Händler?!
 
Gibt es ein Wiper-Tool für die SuperTalent 64GB Disks unter Win7 64Bit?
Das "UltraDrive_PRT_v1571" meint es könne keine Disk finden auf die es angewendet werden kann. :confused:
 
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