Im gleichen externen Gehäuse? Oder in einem anderen, ggf. einem Exemplar des gleichen Typs?dianos schrieb:Bei Übertragung auf SSD (im extern. Gehhäuse) mit USB 3.0 und Win10 trat das Problem wie gesagt nicht auf.
Dann waren es nicht die UX States, die erst mit der finalen xHCI 1.0 Spezifikation eingeführt wurden und zu den Problemen bei alten USB Geräten führen, die nur die xHCI 0.96 (also den Entwurf der xHCI Norm der noch keine UX-States kannte) unterstützen.dianos schrieb:Das Problem mit dem erwähnten Adapter tritt hier auch bei USB 2.0 und Windows 7 (bei einem anderen Laptop) auf.
Du meinst als Attribut 0xC7 bzw. 199 welches die Übertragungsfehler zwischen dem Controller der Platte (SSD oder HDD) und dem SATA Host Controller anzeigt, welches bei den Gehäuse der USB-SATA Bridgechip im Gehäuse ist. Die haben mit den USB Kabeln im Prinzip nichts zu tun, aber ob es nicht auch USB-SATA Bridgechips gibt bei denen USB Problem dann zu diesen Fehlern führen, kann ich auch nicht ausschließen. Im PC ist eigentlich immer das SATA Datenkabel schuld, ggf. auch ein Wechselrahmane, beides gibt es in den USB-Gehäuse aber fast nie und daher sitzt dort meist die Platte nicht ordentlich auf der Buchse und verursacht diese Fehler.dianos schrieb:SMART auslesen: die CRC Datenübertragungsfehler waren anschliessend fast immer erhöht. (Bei Verwendung eines älteren Adapter trat das Problem nicht auf.)
Poste man den Screenshot von CrystalDiskInfo für die Platte, ziehe aber bitte das Fenster soweit auf, dass alle Attribute und auch die Rohwerte vollständig sichtbar sind. Dann müsste man viele Ausschaltabbrüche / unerwartete Spannungsabfälle sehen, wenn die Spannungsversorgung das Problem ist, aber eigentlich keine Ultra-DMA-CRC Fehler.dianos schrieb:Meine Vermutung für die Ursache liegt in der Stromversorgung, die bei einer HDD ohnehin wohl kritischer ist als bei einer SSD.
Data cable ja, aber Power cable wäre sehr ungewöhnlich. Die Übertragungen werden ja seit der Einführung der Ultra-DMA Modie bei PATA mit einer CRC32 pro FIS (Übertragungspaket mit Befehlen oder max. 8192 Byte Nutzdaten) abgesichert und wenn die CRC32 nicht zum Inhalt des Paketes passt, dann gibt es so einen CRC Fehler und die Übertragung muss wiederholt werden, weshalb diese Probleme dann auf die Perforamance gehen, wenn sie öfter auftreten.dianos schrieb:Auch HD Sentinel schreibt dazu. "...attribute 199 Ultra ATA CRC Error Count Count of errors during data transfer between disk and host:
Indicate problem with the power supply or data cable. ......"
Diese Chips brauchen im Vergleich zu den HDDs und SSDs aber alle recht wenig, der Unterschied in der Leistungsaufnahme von einem zum anderen dürfte den Kohl nicht fett machen.dianos schrieb:Jmicron selbst gibt in dem von mir zitierten obigen Link an, dass der Leistungsbedarf des JMS567 signifikant niedriger ist als bei vorigen Bridges.
Sonst nimm einen aktiven Hub, also einen mit einem eigenen Netzteil, die kosten ab so um die 20€ und liefern dann mehr als genug ledianos schrieb:Mit einem Y-Kabel hätte ich mal den problematischen Adapter hier testen können, hatte aber keins hier.
Mr.Seymour Buds, die Werte sind in Ordung und das Datenkabel war es wohl auch nicht, denn es gibt keine Ultra-DMA-CRC Fehler. Probiere es mal ein FW Update, denn die neusten FW ist die MU03 für die MX200 (war ein Versehen, es geht um die MX100), deren Changelog zeigt mal wieder, dass es Verbesserungen im Zusammenhang mit dem Energiespareinstellungen gab:
Crucials SSDs mit Marvell Controllern hatten immer Probleme mit Energespareinstellungen, das zieht sich seid der C300 durch die Changelogs aller FW Updates und man sollte bei den SSDs dann besser die Energiespareinstellungen deaktivieren, auch wenn dann im Idle nicht wirklich sparsam und für Notebooks daher eher nicht zu empfehlen sind.
- Change made to ensure that Identify Word 59, Bit 8 (Multiple logical sector setting is valid) is not reset after Device Sleep transition
- Change made to ensure that SATA speed negotiation is not performed upon exiting of Device Sleep
- Change made to ensure Controller Register settings are correctly saved prior to transitioning to Device Sleep
- Change to SSD default operation to allow drive to respond to host while recovering from Error condition
Es gibt zwar 28 unerwartete Spannungsabfälle, aber bei 366 Einschaltungen würde ich diese ja noch eher als normal ansehen, denn manchmal stützt ein Rechner oder man geht ins BIOS und beim Verlassen des BIOS/UEFI kommt es auch gerne dazu, weil die BIOS den Platten dann eben keinen Hinweis auf einen bevorstehenden Spannungsabfall schicken.
Zuletzt bearbeitet: