SATA & AMD X570 Performance Problem + Erfahrung mit AMD Support

Da keine Lösung (Firmwareupdate?) in Sicht ist, habe ich mal dem AMD Support geschrieben, jedoch scheinen die dort nicht wirklich kompetent:
"Fun"-Fact: Damit hast du mehr Rückmeldung bekommen als ich.
Ich habe zu der Thematik einiges getestet, verschiedenste Konfigurationen, Installationen (Software, Treiber und Win10-Versionen/Upgradestände) usw, wirklich viel gebracht hat das allerdings nicht. Deshalb auch damals der Artikel mit der WD_Blue bzw. dem X570 und dem Z370 im Vergleich. So habe ich mir immerhin die bestmögliche Transparenz erhofft, denn der Hinweis dazu steht auch in jedem Review verlinkt, die genutzten Testsysteme sowieso. Denn, dass Quervergleiche damit schwierig sind, ist natürlich ein Fakt. Trotzdem bin ich der Überzeugung, dass wir so die größtmögliche Transparenz für die Leser schaffen konnten. Als der B550 erschien, hatte ich das direkt im Hinterkopf und daher gleich verglichen. Bei Hardwareluxx haben wir ja meist auch einen (rudimentären) SATA-Benchmark drin, die Werte zu allen getesteten X570-Boards seht ihr in den jeweiligen Review. Da der B550 bedeutend besser abschnitt als die vorherigen X570-Tests, habe ich den Wechsel dazu angestoßen. Aktuell ist das der einzig machbare Weg. Denn eine Testplattform mit TR(X)4-Chipsatz kann ich nicht einfach aus dem Hut zaubern ;)
Was Rocket Lake angeht, werde ich mir die Sache in Bezug auf die SSD-Reviews sicherlich neu überdenken, so bald entsprechende Reviews verfügbar sind.

Der Hersteller misst bestimmt nicht mit Crystal Disk Mark oder AS SSD. :)
Also, es gibt für SSD-Reviews nicht von jedem Hersteller überhaupt entsprechende Informationen oder eine Handreichung, aber wenn doch, dann ist CDM bislang immer als Referenz dabei gewesen, AS SSD (nur) teilweise.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Nur leider wird in den Mainboard Reviews die SATA Performance nur mit ATTO und nicht mit CDM gebencht. Ihr habt zwar eine alte SSD mit dem Sandforce SF-228 die nur mit extrem komprimierbaren Daten gute Wert (vor allem schreibend) liefert, aber man kann bei CDM ja auch auf 0-Fill umstellen und bekommt dann auch extrem komprimierbare Testdaten. Es wäre jedenfalls schön auch bei der SATA Performance die Latenz und die IOPS zu erhalten.
Aktuell ist das der einzig machbare Weg. Denn eine Testplattform mit TR(X)4-Chipsatz kann ich nicht einfach aus dem Hut zaubern
Der TRX40 Chipsatz ist doch im Grunde auch ein X570 der dort ja auch ein I/O Die drin steckt, es steht also zu befürchten das es dort auch die gleichen SATA Performance Probleme gibt.
Was Rocket Lake angeht, werde ich mir die Sache in Bezug auf die SSD-Reviews sicherlich neu überdenken, so bald entsprechende Reviews verfügbar sind.
Es wäre toll wenn ihr beim Review der Plattform (oder eben danach) auch noch einen Review mit einer aktuellen PCIe 4.0 und SATA SSD die ihr auch auf dem aktuellen SSD Testrechner macht oder schon gemacht habt, ausführen könntet. So könnte man sehen wie groß die Performance Unterschiede zwischen den Plattformen sind. Zumal ihr bei den SSD Reviews ja auch die Ergebnisse von Reviews auf der alten Testplattform aufführt, so dass z.B. die 870 Evo bei AS-SSD 4k_64 Read nur auf 213,67MB/s kommt, während die 860 Evo mit 378,67MB/s angegben ist. Dabei sieht man ja auch an den 365,45MB/s der WD Blue 3D am Z370 gegenüber nur 109,78MB/s am X570, wie groß der Einfluss der Plattform auf die IOPS ist und eine 870 Evo kann auf der passenden Plattform sich weiter mehr als nur die 214MB/s erzielen. Leider fehlt aber in den Tabellen, außer eben bei der WD Blue, der Hinweis auf die Testplattform mit der die Werte ermittelt wurden.
 
Der TRX40 Chipsatz ist doch im Grunde auch ein X570 der dort ja auch ein I/O Die drin steckt, es steht also zu befürchten das es dort auch die gleichen SATA Performance Probleme gibt.
Richtig, wäre aber eben zu testen. Ansonsten sind die PCIe4-Alternativen eben rar und mehrere Systeme parallel sind nun wirklich nicht darstellbar...
Es wäre toll wenn ihr beim Review der Plattform (oder eben danach) auch noch einen Review mit einer aktuellen PCIe 4.0 und SATA SSD die ihr auch auf dem aktuellen SSD Testrechner macht oder schon gemacht habt, ausführen könntet. So könnte man sehen wie groß die Performance Unterschiede zwischen den Plattformen sind. Zumal ihr bei den SSD Reviews ja auch die Ergebnisse von Reviews auf der alten Testplattform aufführt, so dass z.B. die 870 Evo bei AS-SSD 4k_64 Read nur auf 213,67MB/s kommt, während die 860 Evo mit 378,67MB/s angegben ist. Dabei sieht man ja auch an den 365,45MB/s der WD Blue 3D am Z370 gegenüber nur 109,78MB/s am X570, wie groß der Einfluss der Plattform auf die IOPS ist und eine 870 Evo kann auf der passenden Plattform sich weiter mehr als nur die 214MB/s erzielen. Leider fehlt aber in den Tabellen, außer eben bei der WD Blue, der Hinweis auf die Testplattform mit der die Werte ermittelt wurden.
Ich kann nichts versprechen, was ich nicht alleine beeinflussen kann. Wie gesagt hab ich bei Rocket Lake das Thema im Hinterkopf, ob sich dann ein erneuter Wechsel des Testsystems aufdrängt und ermöglicht, wird man sehen.

Zum Hinweis bzgl. des Einflusses des Testsystems ist mittlerweile einiges geschrieben worden (v.a. in den Kommentaren zum Artikel der 870 EVO), von daher kann ich nur zustimmen und mich wiederholen: Der Hinweis zur eingeschränkten Vergleichbarkeit steht in jedem Artikel, leider kann ich nicht jede SSD stets auf neuen Plattformen testen. Das hat sich bei der WD_Blue angeboten, daher da auch der explizite Hinweis und der Artikel. Jeweils noch das Testsystem hinter den SSD-Namen zu schreiben, gibt das Layout nicht so wirklich her. Den Klick auf die SSD muss daher jeder User selbst übernehmen. Ich denke, da sind wir halt irgendwo an den Grenzen des vertretbaren Aufwands - es muss ja umgekehrt auch keiner die Werte vergleichen, sondern kann einfach die Zahlen auch selbst lesen und für sich interpretieren.

Ich bin mir in diesem Zusammenhang auch gar nicht so sicher, wie man SSD-Reviews heute idealerweise gestalten sollte und welche Benchmarks überhaupt für User noch halbwegs interessant sind. überhaupt gelesen und verstanden werden. Die X570-Frage von @DJMCM ist ja das beste Beispiel, da es ein vermeintliches Problem beschreibt, das offenbar kaum jemanden überhaupt interessiert. Zumindest entdecke ich weltweit sehr wenig Resonanz dazu, von Herstellerseite allemal und hier im Luxx sind es doch auch immer die selben paar User, die darüber schreiben. Im Alltag da draußen scheint es wenig zu interessieren. Was mich wieder zur Frage nach modernen SSD-Reviews führt: wie müssten die (realistisch) aussehen? Beim Vergleich zwischen X570 und Z370 stellen wir zwar prominent den Umstand fest, dass bei vielen parallelen Anfragen die AM4-Plattform verhältnismäßig stark einbricht, doch ist das überhaupt ein Wert, der im Alltag erreicht wird? Der eine Rolle spielt?
Umgekehrt ist ja X570 bei den 4K-QD1-Werten deutlich besser als die Intel-Plattform und vermutlich beschreibt das den täglichen Use-Case tatsächlich besser; deshalb ist der X570 am Ende bei den Anwendungstests auch in etwa um das Mittel von 20 Prozent schneller. Und im Consistency-Test ist der Unterschied (sowieso bei einer SSD der Klasse einer WD_Blue, hier wäre die 870 EVO interessant gewesen) zu vernachlässigen.
Gerade in dem Kontext, dass das Thema des TE kaum Beachtung findet, müsste man schon fragen, ob Tests dieser Art noch sinnvoll sind. Ich lese selbstverständlich auch Reviews anderer Seiten und überlege mir dabei, ob ich es mir nicht auch viel einfacher machen könnte.
 
Also, es gibt für SSD-Reviews nicht von jedem Hersteller überhaupt entsprechende Informationen oder eine Handreichung, aber wenn doch, dann ist CDM bislang immer als Referenz dabei gewesen, AS SSD (nur) teilweise.
Welchen Hersteller meinst du damit genau, den Datenträger Hersteller oder den Chip Hersteller?
Ich meinte es auf den Chip Hersteller bezogen, also noch ohne Controller Latenzen.

Bei mir scheint die 860 Evo 1 TB SATA 3 auch bei CDM wie festgenagelt bei 488MB/s Schreibgeschwindigkeit.

Wenn ich allerdings eine 6 GByte große Datei (Windows 10 20H2 Image) von meiner NVME auf die 860 Evo kopiere dauert das ca. 7 Sekunden bis sie fertig kopiert ist.
Der Peak geht dann auf über 1800MByte, erst die letzten Sekunden geht sie auf die ~480MByte/s herunter.

Jetzt könnten wir Diskutieren was Praxistauglicher ist, der CDM oder die Reale Kopierzeit. 8-)


Edit Wenn man den Abstand der Vertikalen Linien im Diagramm als 1 Sekunde definiert, wäre es 6000MiB : 10 = 600MiB/S schreib Leistung.
Real habe ich mit der Stoppuhr 6,94 Sekunden gemessen von klick auf Einfügen bis das Diagramm von Windows weg war. :fresse2:
 
Zuletzt bearbeitet:
Welchen Hersteller meinst du damit genau, den Datenträger Hersteller oder den Chip Hersteller?
Ich meinte es auf den Chip Hersteller bezogen, also noch ohne Controller Latenzen.
Achso; ja natürlich kommen solche Informationen wenn überhaupt sowieso nur vom SSD-Hersteller (also dem Gesamtprodukt).
 
Die X570-Frage von @DJMCM ist ja das beste Beispiel, da es ein vermeintliches Problem beschreibt, das offenbar kaum jemanden überhaupt interessiert.
Vermutlich weil die meisten die sich ein X570 Board kaufen, dann sowieso vor allem auf NVMe SSDs setzen, SATA SSDs sind ja inzwischen schon eher am Aussterben.
Was mich wieder zur Frage nach modernen SSD-Reviews führt: wie müssten die (realistisch) aussehen?
Zumindest sollte die SSD nicht leer sein, die wenigstens Leute betreiben die SSDs recht leer, meist ist sie eher viel zu voll, aber gerade leere SSDs profitieren z.B. vom Pseudo-SLC Schreibcache und haben auch weniger Probleme wenn der DRAM Cache fehlt, weil sie Zugriffe ja dann sowieso über einen kleinen Adressraum erfolgen.

Beim Vergleich zwischen X570 und Z370 stellen wir zwar prominent den Umstand fest, dass bei vielen parallelen Anfragen die AM4-Plattform verhältnismäßig stark einbricht, doch ist das überhaupt ein Wert, der im Alltag erreicht wird?
Natürlich wird kein Heimanwender im Alltag 32 oder noch mehr parallele Zugriffe haben, aber auch damit bleibt die Frage wie sich dies bei QDs im Bereich über 1 bis so 4, mehr Zugriffe dürften im Alltag selten sein, dann auswirkt? Also ob es nur ein Cut bei ganz vielen parallelen Zugriffen ist oder sich auch vorher schon auswirkt.
auch in etwa um das Mittel von 20 Prozent schneller.
20% halte ich für ein Gerücht, obwohl man natürlich nicht vergessen sollte, dass gerade die 4k QD1 Werte sehr von den Energiespareinstellungen abhängen. Bei AMD Systemen dürfte dies meist der AMD Energiesparplan sein, da müsste man also auch drauf achten welcher Energiesparplan eingestellt ist bzw. welcher von denen von MS diesem bzgl. der für diese Performance relevanten Einstellungen entspricht.
 
Vermutlich weil die meisten die sich ein X570 Board kaufen, dann sowieso vor allem auf NVMe SSDs setzen, SATA SSDs sind ja inzwischen schon eher am Aussterben.
Kann natürlich gut sein.
Zumindest sollte die SSD nicht leer sein, die wenigstens Leute betreiben die SSDs recht leer, meist ist sie eher viel zu voll, aber gerade leere SSDs profitieren z.B. vom Pseudo-SLC Schreibcache und haben auch weniger Probleme wenn der DRAM Cache fehlt, weil sie Zugriffe ja dann sowieso über einen kleinen Adressraum erfolgen.
Vielleicht könnte man die Anwendungsbenchmarks bei 80% Füllstand durchführen, um das Szenario etwas besser abzudecken. Muss ich mal testen.

Natürlich wird kein Heimanwender im Alltag 32 oder noch mehr parallele Zugriffe haben, aber auch damit bleibt die Frage wie sich dies bei QDs im Bereich über 1 bis so 4, mehr Zugriffe dürften im Alltag selten sein, dann auswirkt? Also ob es nur ein Cut bei ganz vielen parallelen Zugriffen ist oder sich auch vorher schon auswirkt.
Laut Iometer ja, da testen wir ja QD1 und QD3.
20% halte ich für ein Gerücht, obwohl man natürlich nicht vergessen sollte, dass gerade die 4k QD1 Werte sehr von den Energiespareinstellungen abhängen. Bei AMD Systemen dürfte dies meist der AMD Energiesparplan sein, da müsste man also auch drauf achten welcher Energiesparplan eingestellt ist bzw. welcher von denen von MS diesem bzgl. der für diese Performance relevanten Einstellungen entspricht.
Die 20% waren letztlich das mittlere Ergebnis der WD_Blue im Vergleich zwischen X570 und Z370. Natürlich sind die Unterschiede je nach Anwendung und damit Nutzerprofil verschieden; wird fast ausschließlich gelesen sind die Werte fast exakt gleich, wurde hingegen viel geschrieben, war die AMD-Plattform deutlich schneller. Man muss dazu sagen, dass die Werte bereits jeweils das Mittel aus drei Durchläufen sind, von daher ist das schon halbwegs belastbar.
 
Mal eine kleine Checkliste:

- Datenträger, Chip Hersteller, Firmware Version.

- Windows Version, Patch Level, EnergieSparplan*.

- Test Programm Version, Einstellungen.

- Hardware, SATA Leitungen, Temperatur des Datenträger & Füllstand.

- Praxis Einsatz.

Das würde ich Grob als Praxis Test an Infos erwarten.


*
ab_festplatte_hiddenozckqx.jpg
 
wird fast ausschließlich gelesen sind die Werte fast exakt gleich, wurde hingegen viel geschrieben, war die AMD-Plattform deutlich schneller.
Nur erfolgen Schreibvorgänge in aller Regel gepuffert und seltsamerweise hat due Blue bei Blue bei AS-SSD bei 4k Lesend auf dem X570 mit 33,97MB/s zu 29,37MB/s auf dem Z370 besser und bei 4k Schreibend mit 80,04MB/s zu 96,55MB/s auf dem Z370 besser abgeschnitten. Bei 4k_64 Schreibend ist sie mit 78,28MB/s auf dem X570 sogar noch minimal langsamer als bei QD1 gewesen. Allerdings sehe ich im Screenshot in der Galerie auch, dass ihr die Zugriffszeit Lesend auf dem Z370 nicht ermitteln konntet, es also einen Unterschied bzgl. der Seicherheitseinstellungen oder -software geben muss und nur auf dem Z370er System Low-Level Zugriffe unterdrückt wurden und außerdem passen die Werte aus dem Screenshot des X570 nicht zu denen in der Tabelle, währen sie z.B. am X570 laut Tabelle bei 4k_64 Schreibend nur 78,28MB/s haben soll, zeigt der Screenshot 184,98MB/s an, Keine Ahnung was da passiert ist, aber wenn z.B. auf der glechen Plattform durch irgendeine Änderung derartige Abweichungen auftreten können, ist es ja praktisch unmöglich noch irgendwas über die daran getestete SSDs auszusagen.
 
Ich würde die zu geringe Schreib Leistung eher auf das Test Programm schieben, weil im Alltag gibt es keine Probleme mit der Schreibleistung.
Womöglich haben einfach mehr Leute aus dem Intel Lager gespendet damit der Test Algorithmus von CDM besser auf Intel Plattformen läuft, also eher Marketing PR.

Ich werde CDM jedenfalls nicht mehr ernst nehmen. :)
 
Die Werte, die CDM ermittelt sind, auf jeden Fall näher an der Realität als dein oben gezeigter "Alltagstest". Auf ein SATA-SSD können niemals 6GB in 7s geschrieben werden. Das entspräche einem Durchsatz von 860MB/s. Das liegt weit über dem maximal möglichen (Netto)Durchsatz des SATA-Interfaces von ca. 560 MB/s.
 
Die Werte, die CDM ermittelt sind, auf jeden Fall näher an der Realität als dein oben gezeigter "Alltagstest". Auf ein SATA-SSD können niemals 6GB in 7s geschrieben werden. Das entspräche einem Durchsatz von 860MB/s. Das liegt weit über dem maximal möglichen (Netto)Durchsatz des SATA-Interfaces von ca. 560 MB/s.
Warum nicht? Werden die IC halt kurz bis an die Thermal Grenze gedrückt und dann gedrosselt nach 5 Sekunden.
Der CPU Boost macht es doch auch nicht anders, warum sollte das bei SSD über SATA3 nicht Funktionieren? (Stichwort: Kompression in Echtzeit mit 24 Threads?)

Glaube was du willst, aber ich versteife mich nicht auf Werte die nur den Verschleiß meiner Datenträger begünstigt, dann verdient der SSD Hersteller wieder daran. ;)
 
Zuletzt bearbeitet:
Die Werte, die CDM ermittelt sind, auf jeden Fall näher an der Realität als dein oben gezeigter "Alltagstest".
Das würde ich nicht sagen, die Werte von CDM zeigen was die jeweilige SSD bei den bei den unterschiedlichen Tests mit ihren unterschiedlichen Zugriffslängen (4k, 128k und 1M) und QDs jeweils erreichen kann. So wie bei CDM gebencht wird, sind aber die Zugriffe in der Praxis nie, von daher sind diese Werte wirklich nah an irgendeiner Realität.
Auf ein SATA-SSD können niemals 6GB in 7s geschrieben werden. Das entspräche einem Durchsatz von 860MB/s. Das liegt weit über dem maximal möglichen (Netto)Durchsatz des SATA-Interfaces
Das stimmt zwar, aber auch bei irgendwelchen Alltagstest lauern eben eine Menge Fall die zu Fehlern führen können, wie eben der Schreibcache von Windows. Durch den kann es eben auch dazu kommen, dass 6GB in 7s geschrieben werden, wenn man die Zeit auf Basis der Anwendung ermittelt, für die der Schreibvorgang abgeschlossen ist, sobald das letzte Byte in den Schreibpuffer geschrieben wurde, auch wenn aus dem Schreibcache danach noch auf die SSD geschrieben wird, was ja auch der Sinn eines Schreibcaches ist. Synthetische Benchmarks wie AS-SSD oder CDM versuchen die Effekte der Caches des Betriebssystem, Windows nutzt wie jedes moderne OS sonst unbelegtes RAM als Diskcache und daher kann der auch bei wiederholtem Lesen ins Spiel kommen, kopiere mal eine nicht zu große Datei (einige 100MB bis wenige GB) von einem USB Stick an einem USB2 Port zweimal hintereinander auf eine SSD und schau wie viel schneller dies beim zweiten mal geht!

Es gibt eben so oder so: Wer misst misst Mist!
 
...der Schreibcache von Windows. Durch den kann es eben auch dazu kommen, dass 6GB in 7s geschrieben werden, wenn man die Zeit auf Basis der Anwendung ermittelt, für die der Schreibvorgang abgeschlossen ist, sobald das letzte Byte in den Schreibpuffer geschrieben wurde, auch wenn aus dem Schreibcache danach noch auf die SSD geschrieben wird, was ja auch der Sinn eines Schreibcaches ist. Synthetische Benchmarks wie AS-SSD oder CDM versuchen die Effekte der Caches des Betriebssystem, Windows nutzt wie jedes moderne OS sonst unbelegtes RAM als Diskcache und daher kann der auch bei wiederholtem Lesen ins Spiel kommen, kopiere mal eine nicht zu große Datei (einige 100MB bis wenige GB) von einem USB Stick an einem USB2 Port zweimal hintereinander auf eine SSD und schau wie viel schneller dies beim zweiten mal geht!

Es gibt eben so oder so: Wer misst misst Mist!
Danke, gut erklärt. Genauso könnte er gleich PrimoCache installieren - dann wären die 6GB nicht in 7, sondern gar in 2 Sekunden (scheinbar) kopiert!
 
Kann sein das so eine 3rd Party Cachsoftware einen noch größeren Schreibcache anlegt als Windows es machen würde, aber der Grund warum es solche Cacheprogramme überhaupt gibt, ist dass die Benchmarks zwar ihr bestes tun um Windows eigene Caches zu umgehen, die wollen ja eben die Performance der SSDs messen und nicht die des Caches, aber bei 3rd Party Software keine Chance haben. Deshalb bringen die im Alltag kaum was bis gar nichts oder können wegen des zusätzlichen Verwaltungsaufwands sogar eine Bremse sein, obwohl sie in den Benchmarks so vielversprechend sind.
 
Danke, gut erklärt. Genauso könnte er gleich PrimoCache installieren - dann wären die 6GB nicht in 7, sondern gar in 2 Sekunden (scheinbar) kopiert!
Das habe ich, aber ich brauche es dank NVME PCI-Express 4.0 nicht mehr.

Das mit dem Windows Cache im RAM ist völlig daher geholt, sonst würde doch der Taskmanager den Verbrauch Anzeigen, es sind aber nur 7,4GB von 5,3GB (im idle) beleget und die CPU zuckt auch nicht bei der Auslastung.

Ich habe mir schon was dabei gedacht, testet es doch selbst mal mit dem Windows 10 Image, das ist frei verfügbar.
 
Das mit dem Windows Cache im RAM ist völlig daher geholt, sonst würde doch der Taskmanager den Verbrauch Anzeigen, es sind aber nur 7,4GB von 5,3GB (im idle) beleget und die CPU zuckt auch nicht bei der Auslastung.

Das ist überhaupt nicht weit hergeholt, es gibt da extra eine Anzeige "Im Cache" - das was im Cache ist wird nicht in den Verbrauch hereingerechnet. Wenn man was kopiert geht das auch erstmal ordentlich hoch.
 

Anhänge

  • bilder.PNG
    bilder.PNG
    7,1 KB · Aufrufe: 113
Das ist überhaupt nicht weit hergeholt, es gibt da extra eine Anzeige "Im Cache" - das was im Cache ist wird nicht in den Verbrauch hereingerechnet. Wenn man was kopiert geht das auch erstmal ordentlich hoch.
Ich habe beim messen mit der Stoppuhr so lange gewartet bis das Diagramm weg war, im selben Moment war die Datei auch im Ordner Sichtbar mit der korrekten Größe.

Echt Unverschämt wie ihr eine Diffamiert hier!
 
.. im selben Moment war die Datei auch im Ordner Sichtbar mit der korrekten Größe.
Normales Verhalten bei Nutzung eines Cache. Die Dateioperation wird dem Nutzer als abgeschlossen gemeldet, im Hintergrund wird je nach Cacheeinstellung verzögert (deferred cache) weitergeschrieben.
 
Normales Verhalten bei Nutzung eines Cache. Die Dateioperation wird dem Nutzer als abgeschlossen gemeldet, im Hintergrund wird je nach Cacheeinstellung verzögert (deferred cache) weitergeschrieben.
Defered writing macht Windows selbst nicht, dazu wird dann Primo Cache genutzt.

Sorry, falls das so rübergekommen ist. Das war nicht meine Absicht.
Alles gut, es geht nicht um dich oder mich persönlich.

Es war der erste Kopiervorgang, beim zweiten Test waren es schon 2300MByte/S bis das Thermal Throttling anfängt.

Klar mann kann auch 5x5 Sekunden 488 MByte/S im Limit provozieren, das wären dann schon 25 Sekunden Verschleiß provoziert. :)
 
Eigentlich ist Phantomias88 auf meiner Ignoreliste und dies aus gutem Grund, denn er hat wenig Ahnung, viel Fantasie und einen Hass auf alles was mit Intel zu tun hat. Da er aber offenbar hier gerade sehr aktiv ist, habe ich mir die Beiträge mal anzeigen lassen und die Kombination von wenig Ahnung mit viel Fantasie zeigt sich auch hier dann in solchen Aussagen:
Der CPU Boost macht es doch auch nicht anders, warum sollte das bei SSD über SATA3 nicht Funktionieren? (Stichwort: Kompression in Echtzeit mit 24 Threads?)
Klar könnte man auch für SATA eine Datenkompression bei der Übertragung definieren, aber dies ist nie gemacht worden und daher nicht Teil der SATA Spezifikation, zumal es auch unsinnig wäre, da die Controller der Laufwerke ja sonst die Daten dekomprimieren müssten und selbst wenn man die Daten dann immer komprimiert speichern würde, wie es die neuen Konsolen ja machen, ist es inbesondere bei kleinen Datenmengen auch ineffizient bis unmöglich diese über mehrere Threads verteilt zu komprimieren oder zu dekomprimieren. SATA hat also keine Echtzeitkomprimierung der Daten, einzelne SSD Controller (Sandforce und Phison) haben sowas zwar, aber SATA nicht und da SATA der Flaschenhals ist, kann eine Datenkomprimierung daher nicht die Erklärung sein.
 
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