Transferrate sinkt auf 0!

Okay. Für nächstes Mal weiß ich bescheid. Und ich werd das mal beobachten. Das erklärt aber nicht, warum ich das gleiche Problem mit meinem USB-Stick habe. :-/

Also Mainboard einschicken?
 
Prüfe erst einmal ob die Platte korrekt eingebaut ist, also wirklich fest in der Buchse sitzt. Beim Stick könnte es auch eine andere Ursache haben, die meisten Sticks sind ja bei kurzen zufälligen Schreibzugriffen, was gerade beim Schrieben kleiner Dateien und der Metadaten des Filesystems passiert, extrem langsam.

Den Chipsatztreiber hast Du installiert? Ist dieses unselige Anniversary Update von Win 10 installiert?
 
Also. Ich hab die Festplatte noch einmal ausgebaut, die Kontakte überprüft und stabil wieder eingebaut. Dann habe ich sowohl den Stick, als auch die Festplatte mal auf meinem Laptop (Ubuntu) an USB 3.0 ausprobiert. Dort lief alles stabil und mit hohen Transferraten (dreimal getestet mit unterschiedlichen Datenmengen).

Jap, installiert. Nein, Redstone ist bei mir noch nicht installiert. Mein Build ist 1511.

Weitere Ideen? Sonst würde ich Montag das Mainboard einschicken. Auch wenn ich's ungern mache, weil ich dann ohne PC da stehe...
 
Zuletzt bearbeitet:
Wenn es unter Linux problemlos läuft, sollte es nicht an der HW liegen. Schau mal ob jetzt der Rohwert vom Attribut C7 stabil ist und sich nicht mehr ändert.
 
Holt schrieb:
Wenn es unter Linux problemlos läuft [...]

Ja, auf meinem Laptop. Da läuft es reibungslos. Das Problem besteht aber auf meinem PC - und dort sowohl unter Linux, als auch unter Windows. ;) Interessanterweise kopiert er unter Linux mehr Daten, bevor der Transfer abbricht. Darum ist es mir zuerst auch gar nicht aufgefallen und ich dachte unter Linux sei alles okay.

Wenn ich an meinem PC versuche Daten auf die Festplatte zu kopieren steigt der Rohwert tatsächlich an. Ich kopier jetzt nochmal einige Daten über meinen Laptop und schau mir dann dort den C7-Wert nochmal an. Wenn sich da nichts ändert, muss es doch an der PC-Hardware liegen, oder nicht?

Auf jedenfall vielen Dank bis hier hin. :-)

Update: Auf meinem Laptop hab ich jetzt nochmal 7GB kopiert. Der C7-Raw-Wert hat sich allerdings nicht geändert. Das Problem scheint tatsächlich nur auf meinen PC beschränkt zu sein.

Bei meinem USB-Stick hab ich übrigens das gleich Problem auch am Laptop. :-/

Update 2: Ein weiterer Test auf dem PC unter Ubuntu hat wieder stabile Transferraten erbracht. Hab jetzt 15 Minuten mit 100 MB/s kopieren können. Also irgendwie versteh ich dieses System nicht. :freak: Scheint also doch ein Windows-Fehler zu sein. Ahhh!
 
Zuletzt bearbeitet:
Ist vielleicht einfach Dreck/Staub in den Buchsen die sich negativ auf die Signalqualität auswirken?
 
@rg88: Bei tatsächlich allen Buchsen tritt das Problem auf. Ich hab jetzt noch einmal kräftig gepustet, um Dreck/Staub als Ursache auszuschließen. Aber das brachte keinen Effekt. Außerdem siehe Update 2, vorheriger Post. Auf rätselhafte Weise scheint es bei Ubuntu an diesem PC wieder zu funktionieren. Dass es zuvor nicht funktioniert hat könnte aber eventuell darin begründet sein, dass ich Ubuntu von der Live-CD gestartet habe.

Ich glaube ich versuche einfach mal eine komplette Neuinstallation des Windows 10 Betriebssystems mit der neuen Redstone-Version - aber nicht heute. Vielleicht bringt das ja den erhofften Erfolg...
 
Zuletzt bearbeitet:
faraday schrieb:
Wenn ich an meinem PC versuche Daten auf die Festplatte zu kopieren steigt der Rohwert tatsächlich an.
Das ist das USB Gehäuse schuld, die beiden Controller zwischen denen diese Ultra-DMA Übertragungsfehler passieren, sitzen ja in dem USB Gehäuse, der eine auf der Platine der HDD und der andere ist der JMicron Chip auf der Platine in dem USB Gehäuse selbst. Bei Kommunikationsfehler sollte der Host Controller eine Wiederholung der Übertragung anstoßen, verbindlich vorgeschrieben ist das aber für die Übertragungen von Datenpaketen nicht. Es wird aber üblicherweise gemacht und führt dann eben zum Verzögerungen, wie Du sie hier ja auch hast.
faraday schrieb:
Ich kopier jetzt nochmal einige Daten über meinen Laptop und schau mir dann dort den C7-Wert nochmal an.
Mache das, aber es sollte auch dort genauso auftreten und wenn nicht, liegt es vielleicht an der Position des Gehäuses. Also am besten sollte das auf dem Tisch liegen und beim Umstecken nicht bewegt werden.
faraday schrieb:
Wenn sich da nichts ändert, muss es doch an der PC-Hardware liegen, oder nicht?
Nein im Gegenteil, es liegt an dem Gehäuse und der Hersteller CSL ist für billigen Schrott bekannt.
faraday schrieb:
Bei meinem USB-Stick hab ich übrigens das gleich Problem auch am Laptop. :-/
Das mit dem Stick kann wie gesagt auch ganz andere Ursachen haben und dies scheint hier auch der Fall zu sein. Welcher Stick ist es denn genau?
faraday schrieb:
Hab jetzt 15 Minuten mit 100 MB/s kopieren können. Also irgendwie versteh ich dieses System nicht. :freak: Scheint also doch ein Windows-Fehler zu sein. Ahhh!
Hat sich denn während des Tests der Rohwert vom Attribut C7 (dezimal 199) geändert? Das wäre wichtig zu wissen. Und schau ob die HDD wirklich fest auf der Buchse sitzt, sonst wirst Du immer wieder diese Probleme haben. Des ist ja so ein Gehäuse für werkzeuglose Installation der Platte, da kann die im Zweifel immer hin und her rutschen und entsprechend hast Du mal Probleme wenn der Kontakt schlecht ist und mal nicht, wenn sie gerade mal ordentlichen Kontakt bekommt. Nimm lieber ein Gehäuse wo man die Platte ordentlich verschrauben kann, damit vermeidet man solchen Ärger.

faraday schrieb:
@rg88: Bei tatsächlich allen Buchsen tritt das Problem auf.
Du meinst die USB Buchsen und rg88 meinte hoffentlich die SATA Buchse im USB Gehäuse, denn die Ultra-DMA CRC Fehler haben mit der Übertragung über USB rein gar nichts zu tun.
faraday schrieb:
Auf rätselhafte Weise scheint es bei Ubuntu an diesem PC wieder zu funktionieren.
Was aber weder mit Ubuntu noch Windows zu tun haben dürfte, sondern schlicht damit, dass das Gehäuse zwischen den Tests wohl bewegt wurde und die Anschlüsse der HDDs dann mal besseren Kontakt und mal weniger guten Kontakt mit der Buchse im Gehäuse hatten.
faraday schrieb:
Ich glaube ich versuche einfach mal eine komplette Neuinstallation des Windows 10 Betriebssystems mit der neuen Redstone-Version - aber nicht heute. Vielleicht bringt das ja den erhofften Erfolg...
Das glaube ich nicht, aber scheinbar verstehst oder glaubst Du ja nicht was ich Dir schon geschrieben habe.
 
Holt schrieb:
Das glaube ich nicht, aber scheinbar verstehst oder glaubst Du ja nicht was ich Dir schon geschrieben habe.

Ich verstehe es nicht.^^ Wenn ich es täte, würde ich nicht hier fragen. :-)

Holt schrieb:
Was aber weder mit Ubuntu noch Windows zu tun haben dürfte, sondern schlicht damit, dass das Gehäuse zwischen den Tests wohl bewegt wurde und die Anschlüsse der HDDs dann mal besseren Kontakt und mal weniger guten Kontakt mit der Buchse im Gehäuse hatten.

Kommt da vielleicht noch hinzu, dass Ubuntu mit den Übertragungsfehlern weit besser klarkommt, als Windows? Das würde nämlich einiges erklären, z.B. die scheinbare Stabilität der Übertragungsrate unter Ubuntu.

Holt schrieb:
Nimm lieber ein Gehäuse wo man die Platte ordentlich verschrauben kann, damit vermeidet man solchen Ärger.

Kannst du mir ein (günstiges) Gehäuse empfehlen? Dann würde ich mir das einfach mal bestellen und ausprobieren.

Holt schrieb:
Das mit dem Stick kann wie gesagt auch ganz andere Ursachen haben und dies scheint hier auch der Fall zu sein. Welcher Stick ist es denn genau?

Siehe DriveControllerInfo-Screenshot.

Ich weiß deine Mühe zu schätzen Holt. Danke. :-)
 
Der SanDisk Cruzer Blade, eine Hochleistungsstick ist das auch nicht gerade, da kann es schon mal sein, dass der eben bei kleinen zufälligen Schreibzugriffen wirklich mal in Stocken kommt, solche Sticks sind bei zufälligen Schreibzugriffen ja noch viel langsamer als HDDs. Es kann auch noch eine andere Ursache haben, aber zuerst einmal würde ich versuchen die Problem mit der HDD zu beseitigen, schau als vor und nach jedem Test immer auf das entsprechende Attribut in den S.M.A.R.T. Werten und solltest Du dann feststellen, dass bei Problemen immer auch ein Anstieg des Rohwertes vom Attribut C7 erfolgt, dann weißt Du das genau dort die Ursache ist.

Mit Linux oder Windows hat es dann nicht viel zu tun, allenfalls mit der Anzeige der Schreib- Leseraten oder dem Cacheverhalten, denn die Wiederholungen der Übertragungen werden ja von USB-SATA Bridgechip veranlasst und wenn er das bei Kommunikationsproblemen nicht macht, dann müsste es zu einer Fehlermeldung kommen, denn die Daten sind ja dann eben nicht korrekt übertragen worden. Ein Gehäuse kann ich nicht empfehlen, ich habe mit ewig keines gekauft.
 
Holt schrieb:
schau als vor und nach jedem Test immer auf das entsprechende Attribut in den S.M.A.R.T. Werten und solltest Du dann feststellen, dass bei Problemen immer auch ein Anstieg des Rohwertes vom Attribut C7 erfolgt, dann weißt Du das genau dort die Ursache ist.

Ja, bisher gibt es da eine gewisse Koinzidenz. Jedes mal, nachdem es Probleme gab, ist der Wert angestiegen. Ansonsten blieb er konstant. Also liegt's an der Bridge?
 
Es liegt irgendwo am Gehäuse, die Kommunikation bei der die Fehler auftreten findet ja wie gesagt nur dort drin statt, eben zwischen dem Chip auf der Platine in dem Gehäuse und dem Chip auf der Platine der HDD. Dann werden da eben Wiederholungen der Übertragungen nötig und in der Zeit kann eben keine Übertragung über USB stattfinden, daher fällt die Transferrate eben dann auch auf 0.

Was genau das Problem ist, kann man nur raten, aber wenn die Fehler mal auftreten und mal nicht, dann liegt der Verdacht nahe, dass eben die Steckerleiste der Platte nicht immer ordentlich in der Buche steckt, je nachdem wie das Gehäuse bewegt wird. Daher eben der Rat sich ein Gehäuse zu kaufen bei dem die HDD wirklich festgeschraubt werden kann damit das nicht passiert und der Hinweis, dass diese Gehäuse Schrott ist, weil es eben die Platte nicht so ordentlich fixiert, dass ständig einen sicherer Kontakt gewährleistet ist.
 
Während der Übertragung unter Ubuntu habe ich mal am Gehäuse gewackelt. Die Übertragungsrate blieb stabil. Auch unter Windows brach die Rate nicht ein, direkt nachdem ich gewackelt habe.

Darüber hinaus hat sich der C7-Wert nach einem Test unter Ubuntu nicht geändert.
 
Zuletzt bearbeitet:
Wenn sich der Rohwert von C7 nicht ändern hat, dann wundert es auch nicht, dass es kein Problem gab. Du muss nun nur hinbekommen das es immer so bleibt, dann könntest Du das Gehäuse auch behalten. Wenn es mal wieder zu dem Problem kommt, dann schau halt auf den Rohwert von C7 und ich wette der hat sich dann auch wieder erhöht.
 
Sooo. Ich hab mir jetzt ein neues Festplattengehäuse zugelegt. Bisher läuft alles stabil. War wohl doch der Fehler, danke! Und ich war schon kurz davor, mein Mainboard einzuschicken. :rolleyes:
 
Ich habe jetzt nicht alles durchgelesen, aber evtl. ist das UBS Kabel zu lang oder defekt? Bei USB 3 musst du auf die Kabellänge aufpassen, wie ich selber gemerkt hatte. Bis ca. 1 m länge ist es ok.
 
Nö, Holt hat das doch sehr ausführlich erklärt anhand der SMART-Werte, wo das Problem liegt. Und das ist nicht das USB-Kabel. Soviel Text wärs jetzt auch nicht gewesen zu lesen, sind ja nur zwei Seiten
 
Das wild der Reihe Austauschen von Teilen nach dem Motto, ein blindes Huhn findet ja auch mal ein Korn, scheint eben populärer zu sein als eine systematische Fehlersuche und mancher kann es selbst dann nicht lassen, wenn die Suche zum Erfolg geführt hat.
 
Für so eine systematische Fehlersuche braucht man allerdings auch ein fundiertes Wissen. Nunja, jetzt bin ich jedenfalls schlauer - für's nächste Mal. ;)

Danke nochmal!
 
Zurück
Oben