SSD kaum schneller als HDD

Dann dürfte vermutlich der NVMe Treiber oder die Einstellung so sein, dass da FUA Befehle genutzt werden, die SSDs also gezwungen werden die Daten direkt in NAND zu schreiben, ohne ihren Schreibcache verwenden zu können oder das Programm welche die Daten kopiert, nutzt zu kurze Zugriffe. Teste doch mal mit dd, da kann man dies ja über den Parameter bs angeben und schau was bei welchen Blockgrößen rauskommt.
 
Also es wird nur schlimmer wenn ich ich mit 512 oder 4000 anstelle von 1024 ran gehe.

TheComputerImUsing:/mnt/Kingston-480GB/folder$ dd if=/mnt/Kingston-480GB/folder/file.zip of=/mnt/Kingston-480GB/folder/file.zip2.zip bs=4000
1043522+1 records in
1043522+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 59,7687 s, 69,8 MB/s

TheComputerImUsing:/mnt/Kingston-480GB/folder$ dd if=/mnt/Kingston-480GB/folder/file.zip of=/mnt/Kingston-480GB/folder/file.zip2.zip bs=512
8152522+1 records in
8152522+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 196,402 s, 21,3 MB/s

Normal liege ich bei 100MB/s
 
bs=512 ist viel zu wenig und bs=4000 komplett falsch, wenn dann 4096, was 4K sind. Nimm mal 128K, 256K, 512K, 1M, 2M, 4M usw. dann kommen da sinnvolle Werte raus. Im AHCI Modus kann schon bei SATA ein Zugriff über 2^16 LBAs gehen (im IDE Modus über 2^8) und so richtig die volle Speed erreichen die SATA SSDs bei QD1 erst ab 512k pro Zugriff und NVMe SSDs brauchen noch längere Zugriffe.

Wenn Du die reine Lesegeschwindigkeit testen willst, dann nehme of=/dev/null und wenn Du die reine Schreibgeschwindigkeit ermitteln willst, dann if=/dev/zero, dazu musst Du dann aber unbedingt auch
count=N angeben, wobei der Wert von N mal dem von bs (default ist da 512 Byte) dann die Gesamtgröße der erzeugten Testdatei ergibt.
 
So richtig besser wird es nicht...

bs=512K
7961+1 records in
7961+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 32,8852 s, 127 MB/s

bs=1024K
3980+1 records in
3980+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 22,4298 s, 186 MB/s

bs=4096K
995+1 records in
995+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 22,8207 s, 183 MB/s

bs=8M
497+1 records in
497+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 20,4153 s, 204 MB/s

bs=32M
124+1 records in
124+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 23,2302 s, 180 MB/s
 
Immer noch mit if=/mnt/Kingston-480GB/folder/file.zip of=/mnt/Kingston-480GB/folder/file.zip2.zip, also dem gleichzeitigen Lesen und Schreiben von der gleichen SSDD? Dann ist es kein Wunder, denn beim gleichzeitigen Lesen und Schreiben auf die gleiche SSD brechen die mit NAND Flash alles mehr oder weniger stark ein, nur die Intel Optanes eben nicht:

optane 905p 1-5tb Mixed_Read_Write.png


(Quelle)

Man zahlt eben dafür wie eine SSD auch dann noch performt wenn sie recht voll ist und die Workloads anspruchsvoller werden wie eben bei parallelen Lesen und Schreibvorgängen, wie es Tweaktown sehr passend im Review der Optane 905P schreibt:

Teste doch mal mit dd if=/dev/zero of=/mnt/Kingston-480GB/folder/test count=2000 bs=2M und dann mit dd if=/mnt/Kingston-480GB/folder/test of=/dev/null bs=512K bzw. dd if=/mnt/Kingston-480GB/folder/file.zip of=/dev/null bs=2M

PS: Hier bei Anandtech ein Test der A1000 bei gemischten Lese- und Schreibzugriffen.
 
Zuletzt bearbeitet:
Hallo @Holt
a) ich bin mir bewusst das kopieren von und auf das gleiche Laufwerk nicht die volle Leistung bringen kann, aber das ist hier egal, weil es mir um ein Vergleich zwischen Windows / Ubuntu geht. Dort mache ich die selbe Operation (egal ob das nun ein idealer test ist oder nicht) und die Werte sind mind. 3 mal so gut
b) ich bin mir auch ueber die Limitationen der von mir verwendeten SSDs bewusst, diese sind aber hier weitestgehend zu vernachlaessigen weil 1) Die Platte aktuell 3% voll ist 2) Die Dateigroesse klein Genug ist um nicht ins Limit vom zu laufen 3) Es sich aber denn noch um sequenzielles Schreiben von "grossen" Datein handelt (ergo wir sind hier im idealen Use Case)

Die Frage bleibt: Warum schaft es Ubuntu auf beiden SSDs nicht die Leistung zu erreichen welche ich under gleichen Bedingungen in Windows 10 (pro) abrufen kann?

Zu deinen Tests... die Schreibrate bleibt bei den etwa 180MB/s welche ich schon vorher gesehen hatte.

dd if=/dev/zero of=/mnt/Kingston-480GB/JD/test count=2000 bs=2M
2000+0 records in
2000+0 records out
4194304000 bytes (4,2 GB, 3,9 GiB) copied, 22,572 s, 186 MB/s

dd if=/mnt/Kingston-480GB/folder/file.zip of=/dev/null bs=2M
1990+1 records in
1990+1 records out
4174091269 bytes (4,2 GB, 3,9 GiB) copied, 7,851 s, 532 MB/s
 
Was gibt denn hdparm -tT --direct /dev/nvme0n1 aus, bei mehreren NVMe SSDs musst Du nvme0n1 ggf. entsprechend anpassen. Ansonsten kenne ich mich mit Ubuntu leider nicht aus, aber wenn man mit den richtigen Stichworten googled, so scheinst Du mit dem Problem nicht alleine zu stehen.
 
hdparm funktioniert nicht bei NVMes da es auf SATA aufsetzt, soweit ich das ueberblicke, versuche es aber gerne nochmal heute Abend. Bin auch nicht wirklich der Linux Guru
Gruesse,
Daisho
 
Also bei CentOS 7.5 geht es, ich hatte es extra vorher noch ausprobiert.
 
Ging widererwarten doch..

Kingston
/dev/nvme0n1:
Timing O_DIRECT cached reads: 2274 MB in 2.00 seconds = 1136.98 MB/sec
Timing O_DIRECT disk reads: 3898 MB in 3.00 seconds = 1299.03 MB/sec

Crucial
/dev/nvme1n1:
Timing O_DIRECT cached reads: 2330 MB in 2.00 seconds = 1164.45 MB/sec
Timing O_DIRECT disk reads: 3706 MB in 3.00 seconds = 1234.42 MB/sec
 
Seltsam, wieso ist denn cached bei Dir langsamer? Bei mir kommen mit der Intel DC P3600 7589MB/s in der ersten Zeile und 1613MB/s in der zweiten Zeile raus. Auch mit der SM863 sind es 8132 bzw. 529MB/s. Da scheint was mit der Cacheeinstellung nicht zu passen.
 
Vermutung ins Blaue (habe selbst keine nvme Laufwerke).

0. Über welches Dateisystem reden wir eigentlich bei deinen Tests?

1. Du hast in der /etc/fstab als Option discard gesetzt. Da braucht es in vielen Fällen nicht, es reicht der Cronjob für Trim den Ubuntu sowieso eingerichtet hat.

2. Alignment prüfen via sudo parted /dev/nvmeX und parted nochmals ohne Parameter aufrufen und mit einem print all
An sich willst du Sektorgrößen von 4096 Byte bzw. 4K und ein Alignment an eben jenen 4K großen Sektoren.
 
@Piktogramm
1) Die Tests laufen im allg. auf NTFS (zwecks Vergleichbarkeit mit Windows) aber die Zahlen sehen auch auf meiner ext4 Partition nicht anders aus. (Es gibt ja Aussagen das Linux mit der NTFS Implementierung mit unter Probleme hat aber so ichtig kann ich zu dem Thema keine einheitliche Aussage finden im Netz)

2) Wo siehst Du das ich das gesetzt habe? Um ehrlich zu sein hab ich da nichts dran gedreht, alles was da eingestellt ist kommt so aus der Ubuntu base install.
Und im allg. zu dem Thema, ich lese da ganz viele unterschiedliche Meinungen zu ob man nun discard nehmen soll oder Trim (manche wollen das bei jedem start via cron job reinhaengen, andere sagen 1 mal die Woche oder wenn noetig haendisch reicht) und was nun besser / schlechter fuer die SSD ist.

3) Werde ich mir heute Abend ansehen und vielleicht kommen wir dann ja ein Stueck weiter.

Ich werde im allg. wohl auf aus anderen Gruenden (https://www.computerbase.de/forum/t...icht-wirklich-ins-bios.1861866/#post-22450980) die Firmware der Kingston SSD update mal sehen ob das einen Einfluss hat
 
Für normale Anwendungen (im weit gefasstem "Normal") reicht Trim einmal die Woche per Cronjob, was Ubuntu normalerweise sowieso einrichtet. Anwendungsfälle die von "discard" profitieren würde ich jedoch nicht auf Consumer SSDs laufen lassen. Trim beim Boot klingt nach einem super Vorschlag die Bootzeiten zu maximieren :D.
Ansonsten ist es einfach eine Vermutung, dass discard gesetzt sein könnte.
 
DaishoCB schrieb:
ob man nun discard nehmen soll oder Trim (manche wollen das bei jedem start via cron job reinhaengen, andere sagen 1 mal die Woche oder wenn noetig haendisch reicht) und was nun besser / schlechter fuer die SSD ist.
Die Mountoption discard bedeutet, dass Linux ein Online TRIM ausführt, wie Windows es auch schon seit Win 7 kann, also beim Löschen einer Datei die LBAs auf denen die Datei gestanden hat, getrimmt werden. Der cronjob ist ein Offline TRIM wie das was Windows seit Win 8 im Rahmen des Defragmentierdienstes als Optimierung für SSDs eingeführt hat, dabei wird geschaut welche Cluster des Filesystem unbelegt bzw. von nun gelöschten Dateien belegt sind und diese werden getrimmt. Beide zusammen ist am Besten für die SSD, denn wenn der Controller beschäftigt ist, dann kann er TRIM Befehle auch einfach unter den Tisch fallen lassen und daher macht Sinn regelmäßig mal einen Offline TRIM zu machen, weil dann der Controller möglichst viele nicht mehr von gültigen Daten belegte LBAs möglichst früh freimachen kann. Der Nachteil des Online TRIM ist, dass damit das Löschen langsamer wird, denn eigentlich ist das Löschen nur das Setzen eines Flag in den Verwaltungsdaten des Filesystems, mit Online TRIM muss das OS aber eben auch schauen welche Cluster die Datei belegt hat, umrechnen welchen LBAs diese entsprechen und die TRIM Befehle dafür rausschicken.
Piktogramm schrieb:
Anwendungsfälle die von "discard" profitieren würde ich jedoch nicht auf Consumer SSDs laufen lassen.
Wieso? Das Online TRIM macht gerade bei der typischen Heimanwendernutzung SInn, da dabei viel öfter als bei einer Enterprisenutzung Dateien gelöscht werden.
 
@Holt
Du schreibst oft ware Dinge, aber das ist Unfug. Gerade bei Firmen ist NVMe Speicher mit kurzfristigen Bewegungsdaten gefüllt[1] und man rechnet mit multiplen Drive Writes Per Day (und damit auch Löschungen). Das halten Consumer SSDs weder lang aus, noch fahren Endanwender (dauerhaft) entsprechende Lasten.


[1] Um Daten da nur drauf liegen zu lassen sind die Laufwerke einfach zu teuer.
 
Consumer SSDs sind nicht für schreibintensive Anwendungen gemacht, dies ist richtig, aber pauschale Aussagen über Enterpriseanwendungen sind noch falscher als bei Heimanwendern. Generell ist es aber so, dass bei Enterpriseanwendungen wie Datenbanken praktisch nie Dateien gelöscht werden, die Datafiles werden nur immer größer und bei Virtualisierung werden die Image der VMs i.d.R. auch nicht gelöscht. Beim Caching ist es so, dass die Daten entweder auch direkt überschrieben werden, dann tritt TRIM sowieso nicht in Aktion oder gelöscht und sofort andere unter ihrer Adresse geschrieben werden, dann ist TRIM ebenfalls unnötig, denn durch das Überschreiben weiß ein SSD Controller auch so, dass die alten Daten nun ungültig sind.

Datafiles von Datenbanken lässt man natürlich auch auf den teuren NVME SSDs liegen, da wird ja dauernd drauf zugegriffen und deren Inhalt ändert sich, aber dabei wird gar kein TRIM ausgelöst.
 
Update:
Nach dem ich nun folgende Schritte unternommen habe:
  • BIOS update (Damit ging es dann zumindest unter Windows)
  • Kernel Update
  • Update der Kingston Firmware
  • Installation von nvme-cli
funktioniert nun das schreiben mit solider Geschindigkeit von 450MB/s (Kingston zu Kingston) bis 900MB/s (Kinston zu Crucial) WENN ich ext4 verwende!
Ich kann immer noch nicht mit mehr als 90MB/s - 180MB/s auf NTFS schreiben. Es liegt scheinbar aktuell wirklich am Filesystem.
Hat wer noch Ideen wie ich NTFS mit gescheiter Geschwindigkeit unter Ubuntu betreiben kann ? Ich muesste mir sonst irgend etwas installieren damit ich EXT4 unter Windows nutzen kann, was nicht super einfach klingt (aber angeblich gibt es das)



@Piktogramm zum Thema parted aktuell ist hier scheinbar auf 512B dimensioniert...

Model: KINGSTON SA1000M8480G (nvme)
Disk /dev/nvme1n1: 480GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 331GB 331GB ntfs Kingston-480GB msftdata
2 331GB 480GB 149GB ext4


gleiches gilt fuer die Crucial

Model: CT1000P1SSD8 (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
 
DaishoCB schrieb:
Sector size (logical/physical): 512B/512B
Das die meisten SSDs dies immer noch so angeben, ist unglücklich, denn damit richtet nicht jedes Tool die Partitionen selbstständig an 4k Grenzen aus, wie es für SSDs aber für die optimale Performance nötig ist. Der Start bei 1049kB zeigt, dass es bei Dir auch nicht geklappt hat. Schau Dir die Ausgabe von fdisk -l an, da sollte links der Anfang jede Partition direkt in LBAs erscheinen und der Wert soll ein ganzes Vielfaches von 8 sein, damit die SSD die optimale Performance hat.
 
NTFS-Treiber laufen bei Linux im userspace und das ist ein Garant für "mäßige" Performance wenn es um I/O geht.
Ansonsten das was Holt sagt.
 
Zurück
Oben