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

Status
Für weitere Antworten geschlossen.
******* schrieb:
Das wird ja immer schöner, könnten das die Beta Tester mal testen? ;)
Zum Vergrößern anklicken....

Das die SMART und wear-leveling Informationen gelöscht werden bei einem Full Flash wissen wir schon seit Ewigkeiten. Deshalb ist es ja ein Full Flash. Man muss sich nur mal die SMART Informationen anschauen nach einem Full Flash um das zu erkennen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@antiram

ich hatte zuletzt 2000 GB write auf der UD (seit Downgrade 1571 und anschliesendem Upgrade auf 1916) und das innerhalb von ca 3 wochen, und ich hab mich noch halbwegs zurück gehalten ^^.
Diese writes bestanden aus sehr kleinen bis sehr großen dateien, die gesamte palette, mach ich immer so das die UD in den beta tests in kürzester zeit 10-30 mal vollgeschrieben wird.
hab aber vor 3 tagen nochmal nen downgrade gemacht weil ich die probleme hier im forum versucht habe nachzustellen (deswegen isses jetzt im moment wieder weniger weil die 1571 ja alles zurücksetzt), sprich downgrade, dann auf 1819 dann 1916, hier war dann kein 80% bug festzustellen, ich hatte aber auch nicht genug zeit das die UD mit 1819 einbricht obwohl ich versucht habe es zu provozieren.
Ich weiß aber das meine UD mit 1819 irgendwann von jetzt auf gleich einbricht, das kann 10 minuten nach installation sein, das kann aber auch nen tag oder ne woche dauern, wenn der einbruch aber kommt, dann kommt er innerhalb weniger augenblicke (ich hab den einbruch sogar schonmal während eines ATTO benches live mitbekommen ^^) und meiner meinung nach kann das nur am wear leveling liegen, liegt dann dieser einbruch vor und man macht ein update direkt zur 1916 kommts zum 80% bug, so meine vermutung.
 
Zuletzt bearbeitet:
pinki schrieb:
das ändert nichts daran das ein downgrade auf 1571 das problem behebt, woran es genau liegt wissen wir nicht wir wissen aber, ein downgrade bzw flashen der 1571 downgrades mit anschliesendem update auf 1916 behebt das problem mit dem 80% bug... ist nunmal so
Zum Vergrößern anklicken....

Genau das hatte ich gemacht - von der 1711!!!!!

Als Gratisbetatester bin ich mir zu schade.
 
und du hast den bug ganz sicher?
wie genau sieht der denn bei dir aus?
wie voll ist deine UD?
Hast du BSOD´s?

Das das downgraden keine befriedigende lösung ist, finden wir ja auch, allein weil eben alles wieder auf 0 ist und das kann nicht gut sein.

Ich habe ja die hoffnung das se die sache nochmal angehen bei STT und es deswegen ein paar tage dauert bis die 1916 für die GX/ME kommt, habe mich auch schon zum testen angeboten falls noch was dran gedreht wird außer die namens berichtigung, ich tu doch alles damit ihr zufrieden seit ^^.
 
Zuletzt bearbeitet:
A_H schrieb:
Genau das hatte ich gemacht - von der 1711!!!!!
Zum Vergrößern anklicken....
Bei mir gings ja auch direkt von der 1571 zur 1916 _ohne _ 1711 oder 1819 jemals ausprobiert zu haben, trotzdem hatte ich ebenso die massiven Probleme.

Aber ich hab nun nach der ganzen "Workaround-Prozedur" auch noch den FSC ausprobiert und der wetzt sehr flott ohne BSOD und das PRT flutscht den TRIM Befehl auch sehr zügig durch. Scheint erstmal wieder alles im Lot zu sein. Wie lange wohl?

Aber ich bleibe insgesamt auch eher skeptisch eingestellt. Das ganze muß eigentlich alles viel einfacher, sanfter und vor allem ohne wiederkehrende Probleme vonstatten gehen. Und ohne zusätzliche Release-Verwirrungen seitens ST.
 
Wenn man den 80% Bug hat, dann sofort. Der kommt nicht erst nach ner Weile.
 
pinki schrieb:
und du hast den bug ganz sicher?
wie genau sieht der denn bei dir aus?
wie voll ist deine UD?
Hast du BSOD´s?

Das das downgraden keine befriedigende lösung ist, finden wir ja auch, allein weil eben alles wieder auf 0 ist und das kann nicht gut sein.
Zum Vergrößern anklicken....

Thema:
Ich installiere nicht jedes unbekannte Testprogramm. Ich habe ein Image mit etwa 5GB mehrmals von der Platte auf die SSD kopiert. Anfangs waren es fast 150MB/s, dann 50, ich wurde neugierig, dann 20, mir ging die Muffe, ich habe eine kleinere Datei genommen, bei 95% und weniger als 3MB/s habe ich aufgehört. Das System war fast eingefroren, ich wollte löschen, das ging aber wegen der Systemwiederherstellung nicht echt. Nach 20 Minuten hatte ich mich aus der zähen Pampe wieder raus gewühlt - das System rannte wieder.
 
Zuletzt bearbeitet:
pinki schrieb:
und du hast den bug ganz sicher?
wie genau sieht der denn bei dir aus?
wie voll ist deine UD?
Hast du BSOD´s?

Das das downgraden keine befriedigende lösung ist, finden wir ja auch, allein weil eben alles wieder auf 0 ist und das kann nicht gut sein.

Ich habe ja die hoffnung das se die sache nochmal angehen bei STT und es deswegen ein paar tage dauert bis die 1916 für die GX/ME kommt, habe mich auch schon zum testen angeboten falls noch was dran gedreht wird außer die namens berichtigung, ich tu doch alles damit ihr zufrieden seit ^^.
Zum Vergrößern anklicken....

2TB, also wahrscheinlich nicht mehr als 1% in der lifetime anzeige.
Hauptsache Indinlinx weiß, daß es beim updaten probleme mit 80% bug gibt.

---------- Beitrag hinzugefügt um 16:00 ---------- Vorheriger Beitrag war um 15:37 ----------
Greystoke schrieb:
und das PRT flutscht den TRIM Befehl auch sehr zügig durch.
Zum Vergrößern anklicken....
deshalb bin ich auf das update neugierig. Unmittelbar aufeinanderfolgende trims sind bei 1711, 1819 sehr langsam. 1571 kann ich nicht testen mit linux.

wie lange dauerte das wipern bei 1571 im Vergleich zu 1916?
wie lange dauerte das wipern bei 1819 im Vergleich zu 1916?

---------- Beitrag hinzugefügt um 16:01 ---------- Vorheriger Beitrag war um 15:37 ----------

bei halbwegs ähnlichem Füllstand, is klar

---------- Beitrag hinzugefügt um 16:01 ---------- Vorheriger Beitrag war um 15:37 ----------

bei halbwegs ähnlichem Füllstand, is klar
 
1-2 sekunden dauert rim /wiper mit 1916 ca

Wenns nach 3 wochen intensiefster tests und mehr als unnormalem schreibverahlten nicht auftaucht mit dem Bug dann bin ich mir sicher das es auch zukünftig nicht kommt.
Und ja das Problem wurde gemeldet, zur Beta Phase der 1881 sogar schon, die zeigte dieses verhalten nämlich auch, allerdings bei jedem, bei der 1916 scheints nicht jeden zu treffen.

@A_H

FreeSpaceCleaner musst nichtmal installieren, saugen, doppelklicken, rennt, ohne installation, kannst also danach wieder löschen.
Wäre jedenfalls interessant wie es bei dir durch läuft.
Macht nix anderes als alle freien bereiche deiner UD mit 0en zu beschreiben, wahlweise auch mit 1en (haken bei ff setzen)
 
Zuletzt bearbeitet:
danke yeah gröhl,
sowas hat doch vorher mit dem windows wiper 3-4min gedauert, oddrr?
Konnte das windows wiper nie selber laufen lassen
 
Matze71 schrieb:
Wie schon 100 mal im Thread geschrieben, Du kannst SanitaryErase im laufenden Windowsbetrieb benutzen, einfach starten, es kommt irgendwann zu einem Bluescreen, nach einem Bootvorgang (oder SSD stromlos machen) ist alles weg!
Zum Vergrößern anklicken....

Ups, ok danke. Verzeihung, hab ich nicht gelesen.
Die Variante "Sanitary Erase mittels BartPE auf USB" werd ich trotzdem mal testen und schreiben, falls das Erfolg haben sollte. Aber erst, wenn die fehlerbereinigte 1916 (ohne Namensbug) erschienen ist.

Morpog schrieb:
Der wiper und autotrim kann bei dir nicht funktionieren, da du den Intel Matrix Storage Manager mit dem dazugehörigen iaStor Treiber installiert hast.
Nur mit dem MSAHCI Treiber von Microsoft funktioniert TRIM unter dem AHCI Modus.
Das wäre mit FW 1916 nicht wirklich besser geworden (erst nach Tagen, weil GC langsam ist).
Zum Vergrößern anklicken....

Das weiß ich. Da ich Vista und nicht Windows7 hab, habe ich sowieso kein TRIM seits des BS. Unter Win7 werde ich auch nur MSAHCI Treiber verwenden, wenn bis dahin nicht gerade die Intel RST Treiber den TRIM Befehl durchlassen.
Ich werde wie gesagt die SSD mittels Sanitary Erase "zurücksetzen", damit mit der 1916 das GC nicht erst ewig versuchen muß, das jetzige Chaos zu beseitigen. Danach werde ich erst das Windows Image zurückspielen. Sicher ist sicher.
 
Zuletzt bearbeitet:
@ antiram...
Hab dir mal nen kleines Wiper Video gemacht ;)

das ist bei ner 64 GB UD mit 44,8 GB freiem platz, denke das ist schnell genug ^^

James Cameron für arme ^^ <-- war jetzt auch deutlich billiger als zb Avatar und hat auch keine 20 jahre drehzeit gebraucht ^^

Edit:
Link wurde editiert, fucking RapidShare, ganz runter scrollen ;)
 
Zuletzt bearbeitet:
kannst ja rein setzen ;) hast die erlaubniss ^^

PS link editiert, fucking rapidshare
 
ok, geht
wie lange hat sowas bei dir mit 1571 oder 1711 oder 1819 gedauert?

ich kann mit linux hdparm wiper auch in 1-2s zb. 20GB trimmen. Aber halt nur mit einem (1) einzigen riesigen trim Befehl. Wenn man mehrere kleinere trims nacheinader schickt wird krötenlahm.
das indilinx optimierte wiperscript (1 riesiger trim) braucht zb. insgesamt 3-4s
das inteloptimierte wiperscript (10-20 kleinere trims) braucht bei indilinx zb. 30s
 
Zuletzt bearbeitet:
ich geh davon aus, daß das windows wiper mehrere trims schickt, ansonsten wäre es schon bei 1571,1711,1819 sauschnell gewesen.

Deshalb die Frage wie lange es ca. bei 1571,1711,1819 gedauert hat.
 
Einen Screenshot Deines Desktops kannst Du mit der 'Druck' Taste machen (dann einfach in ein Bildbearbeitungsproramm einfügen).
Unter Win 7 gibt es als Bordmittel das 'Snipping Tool', damit geht es auch sehr komfortabel.
 
******* schrieb:
Pinke @ Oscars

Edit: Du atmest so schwer. ;)
Zum Vergrößern anklicken....

Raucherlunge ^^

in bayern würd man jetzt sagen

I wor mit dr fotzn direkt neba dr kammera, auf deutsch, die kammera war direkt neben meinem kopf/mund/atemorgan deswegen kommt dir das wohl so vor ;)

lol wie primitiv ^^
 
Zuletzt bearbeitet:
:shot: Doch erst lesen, dann antworten.

Video müsste mit Camtasia funktionieren!?!
 
+++ camstudio

Super Programm, lastet aber einen Kern zu 50-100% aus. Aber das dürfte bei anderen nicht anders aussehen :)
 
Habe eben nochmal AS SSD laufen lassen,
irgendwie macht die Platte jetzt im Seq. Lesen knapp 15MB/s weniger, ist zwar nicht die welt aber ist das normal?

Edit: seit dem Update auf 1916 vor zwei Tagen
 
Zuletzt bearbeitet:
Ich bedanke mich bei denne die mir gesten erklärt haben wie man die ssd zurückflasht. es hat funktioniert die ssd läuft noch und die bechmarks sehen auch ok aus. ach übrigens ist es möglich dass eine schraube mit sekundenkleber oder sowas befestigt wurde? denn ich hab 3 schrauben mit dem schrabenzieher rausgedrehr doch die eine musste ich bohren.
 
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