
Espero que alguien pueda darme una pista sobre dónde buscar. Mi Crucial MX300 750 MB funciona mucho mejor en Windows que en Linux y no puedo entender por qué. Estos son los resultados:
- Windows: 533 MB/svelocidad máxima de lectura Resultados de la prueba CrystalDiskMark 8.0.0 de Crucial_CT750MX300SSD1 /dev/sdb6
- Linux: 346 MB/svelocidad máxima de lectura
~$ hdparm -Ttv /dev/sdb6
/dev/sdb6:
multcount = 0 (off)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 25665/255/63, sectors = 127432704, start = 83892224
Timing cached reads: 16474 MB in 1.99 seconds = 8269.94 MB/sec
Timing buffered disk reads: 1038 MB in 3.00 seconds = 345.86 MB/sec
~$ hdparm -V
hdparm v9.58
~$ smartctl -d ata -x /dev/sdb | grep "SATA\|Firmware"
Firmware Version: M0CR070 # <-- latest firmware
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
~$ lspci -nnk
SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Mobile SATA AHCI Controller [8086:1c03] (rev 04)
Subsystem: Lenovo ThinkPad T520 [17aa:21cf]
Kernel driver in use: ahci
Kernel modules: ahci
~$ dmesg
[ 1.917727] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.920398] ata2.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[ 1.920405] ata2.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 1.920409] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 1.920772] ata2.00: supports DRM functions and may not be fully accessible
[ 1.921965] ata2.00: ATA-10: Crucial_CT750MX300SSD1, M0CR070, max UDMA/133
[ 1.921971] ata2.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[ 1.926973] ata2.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[ 1.926980] ata2.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 1.926984] ata2.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 1.927288] ata2.00: supports DRM functions and may not be fully accessible
[ 1.930516] ata2.00: configured for UDMA/133
[ 1.941605] ata2.00: Enabling discard_zeroes_data
~$ uname -r
5.8.0-40-generic
~$ cat /sys/block/sdb/queue/scheduler
[mq-deadline] none
El mismo disco se midió a 485 MB/seg usando hdparmaquí:
lptp [ ~ ]: sudo hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 12388 MB in 2.00 seconds = 6197.19 MB/sec Timing buffered disk reads: 1454 MB in 3.00 seconds = 484.59 MB/sec
Por lo tanto, no parece que hdparm no sea comparable a CrystalDiskMark. También probé con la última iso en vivo de Debian, así como con la iso de Ubuntu 16.04.7 e instalé el kernel principal 5.10.10. Los mismos resultados de hdparm.
Entonces, por el momento se puede descartar lo siguiente como causa de la diferencia en el rendimiento:
- el SSD
- la gestión de energía
- mi instalación de linux
- probablemente el núcleo también
EDITAR:
encontré estopublicación antiguamío donde el mismo disco funcionaba mucho mejor en Linux y en la misma computadora portátil... No sé qué está pasando aquí... Acabo de probar el SSD con el mismo programa en Windows y¡Los resultados son los mismos que en aquel entonces!
EDITAR 2: Se actualizó el BIOS. Ningún cambio.
EDITAR 3: ¡En una iso en vivo de Ubuntu 16.04.1, hdparm mide diferentes valores!
ubuntu@ubuntu:~$ sudo hdparm -Tt /dev/sdb
/dev/sdb:
Timing cached reads: 15580 MB in 2.00 seconds = 7795.60 MB/sec
Timing buffered disk reads: 1308 MB in 3.00 seconds = 435.76 MB/sec
ubuntu@ubuntu:~$ hdparm -V
hdparm v9.48
ubuntu@ubuntu:~$ uname -r
4.4.0-31-generic
ubuntu@ubuntu:~$ lsb_release -d
Description: Ubuntu 16.04.1 LTS
EDITAR 4: ¡¡Es el núcleo!!
ubuntu@ubuntu:~$ uname -r
4.9.253-0409253-generic
ubuntu@ubuntu:~$ sudo hdparm -Ttv /dev/sdb
[...]
Timing buffered disk reads: 1302 MB in 3.00 seconds = 433.43 MB/sec
ubuntu@ubuntu:~$ uname -r
4.10.0-041000rc1-generic
ubuntu@ubuntu:~$ sudo hdparm -Ttv /dev/sdb
[...]
Timing buffered disk reads: 1028 MB in 3.01 seconds = 342.02 MB/sec
Todo lo demás en el sistema de prueba se mantuvo igual. Si es un error del kernel, ha estado ahí desde 4.10. Presentaré un informe sobre bugzilla y espero que alguien se tome el tiempo para ello.