News Surface Pro 4: Schlechte Schreibleistung der SSD ohne alternativen Treiber

R4Z3R, Du reimst Du da was zusammen, wieso sollte man es bei AHCI nicht genutzt haben weil Platten das nicht unterstützen? Umgekehrt wird ein Schuh draus, der AHCI Treiber verwendet eben nur dann FUA oder sync Befehle, wenn die Anwendung das Flushen verlangt, während der NVMe Treiber von Microsoft dies offenbar dauernd macht, wenn der zweit Haken nicht gesetzt ist, obwohl der erst gesetzt wurde und damit die Nutzung des Laufwerkscaches erlaubt wurde. Erst wenn man den rausnimmt, verhält sich AHCI ganz ähnlich und dann sind auch die Schreibraten von SATA SSDs im Keller, da hat Microsoft Mist gebaut, für mich gibt es da nichts drüber zu diskutieren und ich vermute die Ursache liegt einfach darin, dass es eben zuerst nur Enterprise SSDs mit NVMe gab, die ignorieren solche Befehle eben und daher haben die Programmierer die Konsequenzen davon nicht bemerken können, die fallen jetzt erst bei den Consumer NVMe SSDs auf, die keine Stützkondensatoren haben und damit kein sync-Faking.

Der Ball liegt bei Microsoft, die müssen ihren Treiber überarbeiten!

Holt schrieb:

der AHCI Treiber verwendet eben nur dann FUA oder sync Befehle, wenn die Anwendung das Flushen verlangt, während der NVMe Treiber von Microsoft dies offenbar dauernd macht, wenn der zweit Haken nicht gesetzt ist, obwohl der erst gesetzt wurde und damit die Nutzung des Laufwerkscaches erlaubt wurde.

Zum Vergrößern anklicken....

Das klingt grundsätzlich einleuchtend und schlüssig. Gibts dazu was handfestes oder ist das dein Rückschluss aus der ganzen Thematik?

Das erschließt sich doch schon alleine aus dem Verhalten bei den verschiedenen Konfigurationen der beiden Einstellungen zum Cache, z.B. bei AS-SSD im Vergleich zu einer AHCI SSD. Jeweils mit dem Microsofttreiber und natürlich vorausgesetzt die SSDs respektieren diese Einstellungen und machen kein sync-faking.

@Holt:

Sorry, aber:

a) Du hast nach wie vor nicht vollständig verstanden was die beiden Optionen in Windows eigentlich tun. Vor allem bei der zweiten Checkbox.

b) FUAs werden unter AHCI weder von Windows noch Linux genutzt, weil sie nicht von Anfang an im SATA Protokoll waren - sie kamen erst zusammen mit NCQ. Zudem killt man mit FUAs auf herkömmlichen Platten die Performance erst recht.

Google doch einfach. Zwei Stunden und du weist gut Bescheid. Wir müssen nichts vermuten, die Infos sind alle da.
(<Hier kommen die Links rein,wenn ich mal Zeit hab>)

Ist doch nicht so schwer:

Microsoft verwendet nun bei nvme - im Gegensatz zum AHCI-Fall - tatsächlich FUAs. Das ist konservativ und kann die Performance deutlich beeinträchtigen, wenn eine Platte mit dieser vorbei-am-cache Strategie nicht gut zurechtkommt.

Deaktiviert man die FUAs über die zweite Checkbox ist alles wieder gut.

Bei AHCI war das nie ein Thema, weil: FUAs werden dort gar nicht verwendet - weder von Windows noch Linux! Man bedient sich dort sich lediglich der Cache Flush Funktion, die man alle Paar datenblocks einmischt, um so zumindest regelmäßig die Info zu haben: Alles auf der Platte.
Eine Art FUA in Sparversion-Implementierung also, die dafür aber auch kaum Performance kostet.

Microsoft geht halt einen sehr sicheren Weg bei nvme - denn das OS kann nicht wissen ob die SSD eine Power Loss Protection hat. Im Zweifel muss also davon ausgehen dass es keine hat.

Man könnte vorschlagen, dass MS wieder einen leistungsorientieren Modus implementiert - aber als sichere out-of-the-box-lösung: warum nicht. Viele SSDs kommen mit FUAs ja auch besser zurecht als die Samsungs derzeit.

scheint so, als wenn der Samsung-Treiber im Standby Probleme mit sich bringt

siehe https://www.reddit.com/r/Surface/comments/3rvhor/check_sleepstudy_report_to_find_out_what_drains/

R4Z3R, wir kommen wohl nicht mehr auf einen gemeinsamen Nenner, daher ist das Thema für mich zuende.

tarabas, wo steht da was von der SSD? Aber bzgl. der Leistungsaufnahme scheint es bei den Mainboards / Chipsätzen mit PCIe und Energiesparfunktionen wohl Probleme zu geben, wie Anandtech schon im Review der 950 Pro festgestellt hat:

Motherboard power management bugs are tragically common in the desktop space, and devices that incorrectly implement ASPM are common enough that it is seldom enabled by default. As PCIe peripherals of all kinds become more common, the industry is going to have to shape up in this department, but for now consumers should not assume that ASPM will work correctly out of the box.

Zum Vergrößern anklicken....

Bleibt die Frage wie viel besser es bei den Notebooks ist.

Holt schrieb:

tarabas, wo steht da was von der SSD? Aber bzgl. der Leistungsaufnahme scheint es bei den Mainboards / Chipsätzen mit PCIe und Energiesparfunktionen wohl Probleme zu geben, wie Anandtech schon im Review der 950 Pro festgestellt hat: Bleibt die Frage wie viel besser es bei den Notebooks ist.

Zum Vergrößern anklicken....

Habs selber ausprobiert und kann es nach dem sleepstudy Report bestätigen

Holt schrieb:

R4Z3R, wir kommen wohl nicht mehr auf einen gemeinsamen Nenner, daher ist das Thema für mich zuende.

Zum Vergrößern anklicken....

Es geht nicht um einen gemeinsamen Nenner. Der Sachverhalt ist tatsächlich so wie ich ihn dargestellt hatte - eine Meinung kann es höchstens zu der Frage geben, inwiefern Microsoft diese konservative Position bzgl. Write Cache fahren sollte, ob Samsung mehr mit MS absprechen sollte oder andersum.

Bezüglich der Windows-Einstellungen zum Write-Cache, den Unterschieden zwischen NVMe und AHCI und deren Umsetzung in den gängigen OS kann es keine Meinung geben. Das sind Sachverhalte die man nachschlagen kann und jeder kann Sie selbst zusammengooglen.

Hier lässt sich alles wunderbar in 20 Minuten nachlesen:

1. Bezüglich: "Disable Write Cache Buffer Flushing" (Die zweite Checkbox im Windows Dialog):
http://blogs.msdn.com/b/oldnewthing/archive/2010/09/09/10059575.aspx
(Raymond Chen ist Softwareentwickler im Windows-Team)


2. Bezüglich: FUAs in AHCI und wie sie in Betriebssystemen verwendet werden:
https://en.wikipedia.org/wiki/Disk_buffer#Cache_control_from_the_host

Dort heißt es für AHCI:
Windows. "Windows (Vista and up) supports FUA as part of Transactional NTFS, but only for SCSI or Fibre Channel disks [...]"
Linux: "Although the Linux kernel gained support for NCQ around 2007, SATA FUA remains disabled by default [...]"


3. Bezüglich: FUAs in NVMe und wie sie in Betriebssystemen verwendet werden:
http://www.anandtech.com/show/9166/intel-nuc5i7ryh-broadwellu-iris-nuc-review/5

Dort heist es zu Samsung NVMe SSDs i.V.m. dem MS NVME Treiber:
"After discussion with Samsung, it turned out that the performance difference was due to the Microsoft NVMe driver creating FUA (Force Unit Access) I/O write commands. These FUA commands bypass the DRAM cache on the SSD and directly write to the flash, increasing the response time and also lowering bandwidth. For the same access traces, this situation does not happen with the Microsoft AHCI driver."



Schönen Sonntag.

R4Z3R schrieb:

ob nVidia mehr mit MS absprechen sollte

Zum Vergrößern anklicken....

Nochmal: Was hat denn bitte NVidia damit zu tun?

Außerdem bliebe ich dabei, dass schon der Unterschied im Verhalten zwischen AHCI und NVMe bei den jeweils gesetzten Haken eine Bug darstellt, denn mit dem Microsoft NVMe Treiber muss man beide Haken setzen, damit der Schreibcache wirklich genutzt wird und sich die Performance so verhält wie bei AHCI wenn nur der obere gesetzt ist:

For the same access traces, this situation does not happen with the Microsoft AHCI driver.

Zum Vergrößern anklicken....

Wenn ein Programm einfach nur schreibt, muss man daraus keine FUA Befehle generieren, wenn der Nutzer in den Richtlinien die Nutzung des Schreibcaches erlaubt hat, also der obere Haken gesetzt ist!

Holt schrieb:

Nochmal: Was hat denn bitte NVidia damit zu tun?

Zum Vergrößern anklicken....

Ah shit, da sollte natürlich Samsung stehen. In den Posts. Korrigiert, Sorry für die Verwirrung.

Holt schrieb:

Außerdem bliebe ich dabei, dass schon der Unterschied im Verhalten zwischen AHCI und NVMe bei den jeweils gesetzten Haken eine Bug darstellt, denn mit dem Microsoft NVMe Treiber muss man beide Haken setzen, damit der Schreibcache wirklich genutzt wird und sich die Performance so verhält wie bei AHCI wenn nur der obere gesetzt ist:

Zum Vergrößern anklicken....

Deshalb hab ich ja auch gesagt: Man kann schon darüber streiten, ob es sinnvoll von MS ist, dass man bei NVMe so eine konservative Position fährt. Zumal du korrekt anmerkst, dass die gleiche Checkbox in der UI dann das Write Cache Buffer Flushing je nach angebundem Laufwerk unterschiedlich löst.

Interessant wäre zu sehen, was andere NVMe-Laufwerke und deren Treiber so mit dieser ganzen Thematik umgehen.

Wenn Du meine Beiträge dazu hier im Thread gelesen hättest, wüsstest Du wie andere NVMe Laufwerke und Treiber mit der Thematik umgehen.

Betrifft das auch die surface 3 Geräte?

Haben die eine Samsung M.2 NVMe SSD? Wenn nicht, dann sind sie auch nicht betroffen.

Mich wundert die Schreibleistung der PM951 SSD auch mit dem richtigen Treiber: 271 MB/s - echt? Das ist alles, bei einer NVMe SSD mit einer Leseleistung von 1200 MB/s?

Auch wenn man eine höhere Geschwindigkeit bei einem Notebook/Tablet mit nur 256GB Speicher natürlich nicht braucht - ich hätte aber erwartet, in einem über 1500 Euro teuren Top-Modell von Microsoft eine SSD zu bekomen, die zumindest 500MB/s schreibend schafft.

Du hast einfach noch nicht verstanden dass eine sequentielle Transferrate von 500 MB/s in der Praxis keine Vorteile bringt, schon gar nicht bei einem System mit nur einem Datenträger. Woher sollen denn Daten mit mehr als 280MB/s ankommen wenn es keine anderen Datenträger gibt?

Dagegen bringt dir die geringere Latenz in Verbindung mit den hohen IOPS tatsächlich einen Vorteil.


Wegen der neuen Partnummer:
MZFLV256 scheint die PCIe 3.0 x2 Version der PM951 zu sein.
Die "normale" PM951 trägt ja die Bezeichnung MZVLV256, wobei das V hier als Form Factor V: PCIe M.2 (22*80, PCIe x4) ausgewiesen wird.

@CB:
Könnt ihr das mal gegentesten und auslesen mit wie vielen Lanes die SSD im Surface angebunden ist?
SIV - System Information Viewer oder HWinfo können das anzeigen, AIDA evtl. auch.

h00bi schrieb:

Du hast einfach noch nicht verstanden dass eine sequentielle Transferrate von 500 MB/s in der Praxis keine Vorteile bringt, schon gar nicht bei einem System mit nur einem Datenträger. Woher sollen denn Daten mit mehr als 280MB/s ankommen wenn es keine anderen Datenträger gibt?

Zum Vergrößern anklicken....

Also wenn du meine fünf Zeilen ganz gelesen hättest, dann hättest du auch gelesen, was ich noch geschrieben habe: "Auch wenn man eine höhere Geschwindigkeit bei einem Notebook/Tablet mit nur 256GB Speicher natürlich nicht braucht (...)"
Dann hättest du mir nicht unterstellen müssen, dass ich nicht kapiert hätte, was man braucht oder nicht braucht.

Und wo die Daten herkommen sollen? Zum Beispiel über eine ganz normale USB 3.0 SSD mit einem UASP fähigen Gehäuse. Da gehen locker 400MB/s!
Und wie sinnvoll oder nicht es nun genau ist, ist nicht die Frage: das Surface kostet über 1500 Euro ohne Tastatur, da sollte es meiner Meinung nach schon top sein - bei dem Preis lasse ich "das reicht in der Praxis schon aus" eigentlich nicht mehr durchgehen!

Hier der Auszug aus System Information Viewer. Das scheint die x2 zu bestätigen.

Was gibt HWInfo an? Da steht klar aufgeschlüsselt nach Maximum Link Width und Current Link Width und das Gleiche für die die Link Speed, da sieht man dann sofort was die Karte (also SSD) unterstützen würde und wie die im Moment angesteuert wird. Oder soll das cryptische x2@4 (x4@3) da etwa schon bedeuten, dass die maximal 4 PCIe 3.0 Lanes unterstützt, aber nur mit 2 angeschlossen ist?

Ja, das soll es bedeuten. HWInfo liefert dann auch die vermuteten Informationen.

Für die PM951 reciht es ja im Prinzip auch, aber wer auf eine 950 Pro aufrüsten will, was spätestens nach Erscheinen der 950 Pro 1TB dann ja ein durchaus berechtiger Wunsch sein kann, der schaut dann wohl in die Röhre nur weil Microsoft 2 Lanes (hat der Chipsatz nicht genug davon?) spart um das Teil noch ein paar mW sparsamer sein zu lassen. Ich sehe schon den Frust der Aufrüster, wenn die ersten sich z.B. hier im Sammelthread melden und nicht die erwarteten Leseraten erzielen können.

Andererseits schützt man die SSD damit natürlich auch ein wenig vor zu hohen Temperaturen, wenn die Transferraten eingeschränkt werden, braucht sie ja auch weniger Energie und erzeugt damit weniger Wärme, aber diese Drosselung würde sie ja sonst sowieso selbst vornehmen.