Скорость USB Flash

Возможно нужна флешка с указанной способностью.

Возможно нужна флешка с указанной способностью.

С какой способностью? Если вопрос про скорость чтения, то производитель обещает до 1000 МБ/сек.

Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M

Это значит, что этот хаб поддерживает скорость до 10Gb Но чтобы он на этой скорости работал, нужно соответствующее устройство.

Есть мнение, что флешка у вас не очень. Другой вариант что подключаетесь через кабель, а вот он не достигает потребных характеристик.

Есть мнение, что флешка у вас не очень. Другой вариант что подключаетесь через кабель, а вот он не достигает потребных характеристик.

Флешка Kingston. Вроде бы приличный производитель, сильно врать не должен. Версия флешки USB-A. https://www.kingston.com/ru/usb-flash-drives/datatraveler-max

Кабель не использую, флешка вставлена в разъём на материнке.

почему это не должен? обычный производитель поделок, ничем не лучше какого-то апасера. другое дело что в маркетинг вваливают много - это да…

Есть ощущение, что usb-a не поддерживает скорости больше 5Gb. Подтверждения не нашел.

Кингстон настоящий? Упаковка точно как на сайте? Надпись 1Tb меняет цвет под наклоном?

Разьём должен быть помечен как USB 3.2 Gen 2 (aka SuperSpeed 10). В мануале к материнке должно быть указано, какие разъёмы какой скорости.

почему это не должен? обычный производитель поделок

Хорошо. Допустим, флешка у меня бракованная. Как доказать, что дело не в моём компьютере?

Есть ощущение, что usb-a не поддерживает скорости больше 5Gb. Подтверждения не нашел.

Есть какая-то принципиальная проблема с USB-A, или речь идёт о этой конкретной модели?

Кингстон настоящий? Упаковка точно как на сайте? Надпись 1Tb меняет цвет под наклоном?

Похож на настоящий. Я не смог увидеть различий в упаковке, цвет надписи при наклоне меняется.

Разьём должен быть помечен как USB 3.2 Gen 2 (aka SuperSpeed 10). В мануале к материнке должно быть указано, какие разъёмы какой скорости.

А на вывод команды lsusb -t нельзя полагаться?

# lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M

Очень неудачная форма и размер контактов для высоких скоростей. Но верить на слово мне не надо. type C в этом отношении гораздо удачней.

Очень неудачная форма и размер контактов для высоких скоростей. Но верить на слово мне не надо. type C в этом отношении гораздо удачней.

Спасибо за пояснение. При случае я понаблюдаю за различиями в работе разъёмов.

Сделайте сами флеху на основе https://aliexpress.ru/item/1005002702074728.html?sku_id=12000035351305315.

Если нужна готовая, то https://www.citilink.ru/product/fleshka-usb-kingston-datatraveler-micro-128gb-usb3-2-serebristyi-dtmc3-1790335/ – норм вариант.
Запись никакущая, но, опять же, нужна запись, – делайте флеху сами.

Хаб может быть 10 Gbps, а порт 5 Gbps. Например у моей материнки Asrock B450M Pro4 R2.0 восемь USB3 портов – шесть выведены на заднюю IO панель, два выведены на хедер для фронтальной панели корпуса. lsusb -t говорит, что два 4-портовых хаба оба 10 Gbps:

# lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M

Но 10 Gbps портов только два – голубой Type A и Type C на задней панели. Остальные шесть портов синие 5 Gbps.

Хаб может быть 10 Gbps, а порт 5 Gbps.

Вот оно что! Это скорость хаба, а не его портов. Кое-что стало проясняться.

А можно ли какой-то командой узнать возможные скорости работы самих портов до подключения к ним устройств?

А можно ли какой-то командой узнать возможные скорости работы самих портов до подключения к ним устройств?

Отвечу на свой же вопрос: можно.

# lsusb -d 1d6b:0003 -v 2>/dev/zero | egrep 'Bus [0-9]|bcdUSB|Speed Attribute'

Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  bcdUSB               3.10
      Sublink Speed Attribute count 1
      Speed Attribute ID: 4 5Gb/s Symmetric RX SuperSpeed
      Speed Attribute ID: 4 5Gb/s Symmetric TX SuperSpeed
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  bcdUSB               3.10
      Sublink Speed Attribute count 1
      Speed Attribute ID: 4 5Gb/s Symmetric RX SuperSpeed
      Speed Attribute ID: 4 5Gb/s Symmetric TX SuperSpeed
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  bcdUSB               3.10
      Sublink Speed Attribute count 3
      Speed Attribute ID: 4 5Gb/s Symmetric RX SuperSpeed
      Speed Attribute ID: 4 5Gb/s Symmetric TX SuperSpeed
      Speed Attribute ID: 5 10Gb/s Symmetric RX SuperSpeedPlus
      Speed Attribute ID: 5 10Gb/s Symmetric TX SuperSpeedPlus

доказать кому? магазину или производителю? да навряд получится, пуушо если открыть спеки - скорость окажется «до ХХХ МБ/сек» или «максимальная скорость ХХХ МБ/сек»…

доказать кому?

Для начала хочу доказать самому себе и отсечь случаи кривых рук. И сообщество LOR уже отчасти помогло мне это сделать. То есть конкретно в этом случае проблема была не в флешке.

Теперь 512GB записанных на флешку случайных и практических несжимаемых данных я могу прочитать секунд за 500. Результат, я считаю, отличный. Производитель в этом не обманул.

Правда, скорость записи меня совсем не радует, но об этом я спрошу позже. Возможно, я снова что-то делаю не так. Возможно, нужны какие-то особые условия.

Итак. Теперь флешка подключается на нужой мне скорости:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 2: Dev 7, If 0, Class=Mass Storage, Driver=uas, 10000M

Скорость чтения флешки, предварительно заполненной шумом, соответствует заявленной производителем, хотя и на достаточно большом размере блока:

# dd if=/dev/sdb of=/dev/zero bs=64M iflag=direct
  512110190592 bytes (512 GB, 477 GiB) copied, 512.096 s, 1.0 GB/s

Но скорость записи меня совсем не радует. Причём, на первой же минуте я получил скорость раза в три меньше заявленной производителем. А минуты через 2-3 производительность и вовсе упала до примерно 90 MB/s:

# dd if=/dev/urandom of=/dev/sdb bs=64M iflag=fullblock oflag=direct
   18253611008 bytes (18 GB, 17 GiB) copied, 60.0259 s, 304 MB/s
   26306674688 bytes (26 GB, 24 GiB) copied, 120.254 s, 219 MB/s
   33621540864 bytes (34 GB, 31 GiB) copied, 180.547 s, 186 MB/s
   36976984064 bytes (37 GB, 34 GiB) copied, 240.062 s, 154 MB/s
   39728447488 bytes (40 GB, 37 GiB) copied, 300.076 s, 132 MB/s
   49727668224 bytes (50 GB, 46 GiB) copied, 360.221 s, 138 MB/s
   52479131648 bytes (52 GB, 49 GiB) copied, 420.379 s, 125 MB/s
   60532195328 bytes (61 GB, 56 GiB) copied, 480.294 s, 126 MB/s
   63283658752 bytes (63 GB, 59 GiB) copied, 540.927 s, 117 MB/s
   72678899712 bytes (73 GB, 68 GiB) copied, 600.454 s, 121 MB/s
   75967234048 bytes (76 GB, 71 GiB) copied, 660.576 s, 115 MB/s
   83818971136 bytes (84 GB, 78 GiB) copied, 720.17 s, 116 MB/s
   86771761152 bytes (87 GB, 81 GiB) copied, 781.307 s, 111 MB/s
   90932510720 bytes (91 GB, 85 GiB) copied, 840.185 s, 108 MB/s
   99522445312 bytes (100 GB, 93 GiB) copied, 900.395 s, 111 MB/s
  104220065792 bytes (104 GB, 97 GiB) copied, 960.206 s, 109 MB/s
  110259863552 bytes (110 GB, 103 GiB) copied, 1021.1 s, 108 MB/s
  113011326976 bytes (113 GB, 105 GiB) copied, 1081.56 s, 104 MB/s
  122809221120 bytes (123 GB, 114 GiB) copied, 1140.49 s, 108 MB/s
  125694902272 bytes (126 GB, 117 GiB) copied, 1200.64 s, 105 MB/s
  133680857088 bytes (134 GB, 124 GiB) copied, 1261.18 s, 106 MB/s
  136432320512 bytes (136 GB, 127 GiB) copied, 1321.42 s, 103 MB/s
  142874771456 bytes (143 GB, 133 GiB) copied, 1380.29 s, 104 MB/s
  149250113536 bytes (149 GB, 139 GiB) copied, 1441.42 s, 104 MB/s
  156028108800 bytes (156 GB, 145 GiB) copied, 1500.31 s, 104 MB/s
  159920422912 bytes (160 GB, 149 GiB) copied, 1561.23 s, 102 MB/s
  162671886336 bytes (163 GB, 152 GiB) copied, 1621.33 s, 100 MB/s
  172738215936 bytes (173 GB, 161 GiB) copied, 1680.66 s, 103 MB/s
  175489679360 bytes (175 GB, 163 GiB) copied, 1740.59 s, 101 MB/s
  183475634176 bytes (183 GB, 171 GiB) copied, 1801.36 s, 102 MB/s
  186159988736 bytes (186 GB, 173 GiB) copied, 1860.63 s, 100 MB/s
  194951249920 bytes (195 GB, 182 GiB) copied, 1920.41 s, 102 MB/s
  198843564032 bytes (199 GB, 185 GiB) copied, 1980.41 s, 100 MB/s
  206225539072 bytes (206 GB, 192 GiB) copied, 2040.43 s, 101 MB/s
  209513873408 bytes (210 GB, 195 GiB) copied, 2100.48 s, 99.7 MB/s
  212265336832 bytes (212 GB, 198 GiB) copied, 2161.08 s, 98.2 MB/s
  222264557568 bytes (222 GB, 207 GiB) copied, 2221.07 s, 100 MB/s
  225016020992 bytes (225 GB, 210 GiB) copied, 2280.49 s, 98.7 MB/s
  232934866944 bytes (233 GB, 217 GiB) copied, 2340.52 s, 99.5 MB/s
  235686330368 bytes (236 GB, 220 GiB) copied, 2400.64 s, 98.2 MB/s
  245282897920 bytes (245 GB, 228 GiB) copied, 2460.57 s, 99.7 MB/s
  248437014528 bytes (248 GB, 231 GiB) copied, 2521.47 s, 98.5 MB/s
  256355860480 bytes (256 GB, 239 GiB) copied, 2580.64 s, 99.3 MB/s
  259107323904 bytes (259 GB, 241 GiB) copied, 2641.31 s, 98.1 MB/s
  264341815296 bytes (264 GB, 246 GiB) copied, 2700.58 s, 97.9 MB/s
  271925116928 bytes (272 GB, 253 GiB) copied, 2760.87 s, 98.5 MB/s
  276958281728 bytes (277 GB, 258 GiB) copied, 2820.6 s, 98.2 MB/s
  282662535168 bytes (283 GB, 263 GiB) copied, 2881.91 s, 98.1 MB/s
  285346889728 bytes (285 GB, 266 GiB) copied, 2940.9 s, 97.0 MB/s
  295480328192 bytes (295 GB, 275 GiB) copied, 3001.8 s, 98.4 MB/s
  298164682752 bytes (298 GB, 278 GiB) copied, 3060.66 s, 97.4 MB/s
  306150637568 bytes (306 GB, 285 GiB) copied, 3121.37 s, 98.1 MB/s
  308902100992 bytes (309 GB, 288 GiB) copied, 3181.25 s, 97.1 MB/s
  317156491264 bytes (317 GB, 295 GiB) copied, 3240.69 s, 97.9 MB/s
  321719894016 bytes (322 GB, 300 GiB) copied, 3301.31 s, 97.5 MB/s
  328967651328 bytes (329 GB, 306 GiB) copied, 3360.72 s, 97.9 MB/s
  332390203392 bytes (332 GB, 310 GiB) copied, 3420.8 s, 97.2 MB/s
  335141666816 bytes (335 GB, 312 GiB) copied, 3481.02 s, 96.3 MB/s
  345409323008 bytes (345 GB, 322 GiB) copied, 3541.78 s, 97.5 MB/s
  348160786432 bytes (348 GB, 324 GiB) copied, 3601.88 s, 96.7 MB/s
  355811196928 bytes (356 GB, 331 GiB) copied, 3660.79 s, 97.2 MB/s
  358562660352 bytes (359 GB, 334 GiB) copied, 3721.12 s, 96.4 MB/s
  368092119040 bytes (368 GB, 343 GiB) copied, 3780.92 s, 97.4 MB/s
  371581779968 bytes (372 GB, 346 GiB) copied, 3841.56 s, 96.7 MB/s
  379299299328 bytes (379 GB, 353 GiB) copied, 3901.67 s, 97.2 MB/s
  382117871616 bytes (382 GB, 356 GiB) copied, 3961.93 s, 96.4 MB/s
  386345730048 bytes (386 GB, 360 GiB) copied, 4020.86 s, 96.1 MB/s
  395069882368 bytes (395 GB, 368 GiB) copied, 4081.24 s, 96.8 MB/s
  398895087616 bytes (399 GB, 372 GiB) copied, 4140.88 s, 96.3 MB/s
  405605974016 bytes (406 GB, 378 GiB) copied, 4201.38 s, 96.5 MB/s
  408357437440 bytes (408 GB, 380 GiB) copied, 4261.55 s, 95.8 MB/s
  418088222720 bytes (418 GB, 389 GiB) copied, 4321.62 s, 96.7 MB/s
  421108121600 bytes (421 GB, 392 GiB) copied, 4382.22 s, 96.1 MB/s
  429228294144 bytes (429 GB, 400 GiB) copied, 4441.94 s, 96.6 MB/s
  431979757568 bytes (432 GB, 402 GiB) copied, 4501.8 s, 96.0 MB/s
  438422208512 bytes (438 GB, 408 GiB) copied, 4561.03 s, 96.1 MB/s
  444596224000 bytes (445 GB, 414 GiB) copied, 4621.41 s, 96.2 MB/s
  451642654720 bytes (452 GB, 421 GiB) copied, 4680.99 s, 96.5 MB/s
  455467859968 bytes (455 GB, 424 GiB) copied, 4741.92 s, 96.1 MB/s
  458219323392 bytes (458 GB, 427 GiB) copied, 4802.2 s, 95.4 MB/s
  467748782080 bytes (468 GB, 436 GiB) copied, 4861.4 s, 96.2 MB/s
  470500245504 bytes (471 GB, 438 GiB) copied, 4921.75 s, 95.6 MB/s
  478754635776 bytes (479 GB, 446 GiB) copied, 4981.06 s, 96.1 MB/s
  481506099200 bytes (482 GB, 448 GiB) copied, 5041.38 s, 95.5 MB/s
  490230251520 bytes (490 GB, 457 GiB) copied, 5101.08 s, 96.1 MB/s
  493854130176 bytes (494 GB, 460 GiB) copied, 5161.82 s, 95.7 MB/s
  501772976128 bytes (502 GB, 467 GiB) copied, 5221.13 s, 96.1 MB/s
  505128419328 bytes (505 GB, 470 GiB) copied, 5282.42 s, 95.6 MB/s
  507812773888 bytes (508 GB, 473 GiB) copied, 5341.13 s, 95.1 MB/s
  512110190592 bytes (512 GB, 477 GiB) copied, 5359.89 s, 95.5 MB/s

Понятно, что в этом случае я ограничен производительностью /dev/urandom, но не настолько же!

# dd if=/dev/urandom of=/dev/zero bs=64M count=1k
  68719476736 bytes (69 GB, 64 GiB) copied, 145.585 s, 472 MB/s

Что я теперь сделал не так? В каком режиме скорость записи флешки должна достигать 900 MB/s? Это должны быть какие-то хорошо сжимаемые данные? Или требуется интенсивное охдаждение, чтобы избежать телпового дросселирования? Или требуется что-то еще?

По моему это типично и для SSD. В пределах SLC области запись быстрая, когда SLC область заполнена, начинается перенос данных из SLC области в TLC область, скорость записи падает до скорости записи на TLC.

Но скорость записи меня совсем не радует. Причём, на первой же минуте я получил скорость раза в три меньше заявленной производителем.

Добро пожаловать в дивный мир потребительской техники и дешёвой флеш-памяти. Выше уже пояснили за SLC кеш. Ещё веселее будет когда условно 90% объёма флешки будет забито. Тогда она и 100 МиБ/с скорее всего не возьмёт потому что кеша не будет совсем.

У производителя наверняка в рекламе/инструкции/whatever написано ключевое «up to». В теории может, на практике всё зависит от многих факторов.

А ещё не забываем про волшебное слово «trim» который может не работать, и перед записью блока новых данных флешка каждый раз сначала будет стирать старые данные и только потом уже писать новые. Получится уже не 100, а 50 (условно), лол.

Нагрев тоже играет роль, но скорее всего дополнительное охлаждение тут особо не поможет.

Ну и если это флешка, а не nvme ssd с собственным dram кешем, то вопросы к мелкоблочке тут совсем не к месту))

Ну и если это флешка, а не nvme ssd с собственным dram кешем, то вопросы к мелкоблочке тут совсем не к месту))

Все тесты я проводил с блоками по 64 МБ. Подскажите, это достаточно крупный блок для тестирования максимальных скоростей данной флешки?

Получится уже не 100, а 50 (условно), лол.

Примерно так у меня и получается. Я утром прогнал бенчмарк gnome-disks и на короткое время увидел скорость записи 900 МБ/сек. Затем сколько раз ни пытался, всегда получал 50-60 МБ/сек. Видимо, флешке надо отлежаться какое-то время. Сейчас пытаюсь выяснить, сколько именно времени флешка должна отдыхать.

У производителя наверняка в рекламе/инструкции/whatever написано ключевое «up to». В теории может, на практике всё зависит от многих факторов.

Это я понимаю. Кроме этого я пытаюсь выяснить, от каких именно факторов зависит скорость записи для конкретно этой модели. Буду рад любым советам по этой теме.

с блоками по 64 МБ

ИМХО, это слишком крупный блок, попробуйте 1Мбайт или ещё меньше. Ну, и я не знаю, но вдруг флешка сжимает данные, попробуйте не random, а для начала вобще нули, а потом какие-нибудь обычные файлы, их можно на tmpfs поместить. Хотя можно и urandom на tmpfs.

А так у вас получается, что сначала dd читает блок из urandom, потом пишет, он же не одновременно читает и пишет, ЕМНИП.

ИМХО, это слишком крупный блок, попробуйте 1Мбайт или ещё меньше.

Слишком крупный для чего?

Я тестировал блоки и меньшего размера. Могу сказать, что для чистой (конкретно этой) флешки можно смело использовать блок 4 МБ без заметного снижения скорости чтения, но для флешки, заполненной псевдослучайными данными, скорость чтения при размере блока 4 МБ уменьшилась процентов на 10 от максимальной. Даже при блоке 32 МБ скорость чтения чуть снижена. А так как в данном топике я сосредоточился на исследовании максимальных скоростей, поэтому рассматривал лишь тесты с блоком 64 МБ. Тесты с размером блока 128 МБ и выше привели лишь к снижению скорости, впрочем несущественному.

Упомянул же я о размере блока в ответ на сообщение Slavik763, предложившего не рассматривать мелкоблочку. Если потребуется, я готов увеличить размер блока ещё сильнее, но пока не вижу оснований для этого.

вдруг флешка сжимает данные, попробуйте не random, а для начала вобще нули

Хорошая идея, спасибо. Я обычно первую запись на носитель выполняю из /dev/urandom, чтобы проверить, как это скажется на скорости чтения. А потом уже тестирую запись нулей. Одну полную перезапись нулями я выполнил сутки назад, другая выполняется прямо сейчас и закончится примерно через час. Но уже сейчас появились вопросы.

И вчера и сегодня я выполнял полную перезапись нулями с размером блока 64 МБ. Но вчера средняя скорость записи составила 119 МБ/сек, а сегодня лишь 32 МБ/сек. Вчера флешка была перезаписана полностью. Сегодня пока только на 3/4, но вряд ли результат сильно изменится. Как могла возникнуть такая разница в скорости? Скорость интерфейса я уже проверил: 10 Gbps. Но даже порт на 480 Mbps мог бы обеспечить скорость в 40 МБ/сек, если я правильно посчитал.

А так у вас получается, что сначала dd читает блок из urandom, потом пишет, он же не одновременно читает и пишет, ЕМНИП.

А разве данные /dev/urandom формируются не в отдельном потоке?

Сегодня пока только на 3/4, но вряд ли результат сильно изменится.

Тест выполнен до конца, результат изменился не сильно.

# dd if=/dev/zero of=/dev/sdb bs=64M iflag=fullblock oflag=direct

вчера:
512110190592 bytes (512 GB, 477 GiB) copied, 4287.83 s, 119 MB/s

сегодня:
512110190592 bytes (512 GB, 477 GiB) copied, 16080 s, 31.8 MB/s

Между этими двумя тестами я запустил лишь несколько коротких тестов случайной записи gnome-disks.

Почему так сильно упала скорость записи?

Но вчера средняя скорость записи составила 119 МБ/сек, а сегодня лишь 32 МБ/сек. Вчера флешка была перезаписана полностью.

Вчера контроллеру приходилось только писать, а сегодня приходится стирать и писать. Ты ведь не делал blkdiscard перед сегодняшней повторной записью?

tb4/usb4 - 40gbit/s/port?
ну и скорость интерфейса vs скорость флешпамяти.

Вчера контроллеру приходилось только писать, а сегодня приходится стирать и писать. Ты ведь не делал blkdiscard перед сегодняшней повторной записью?

blkdiscard я не делал. Как не делал и вчера между тестом записи с /dev/urandom и /dev/zero. С этой точки зрения оба теста записи нулями имеют похожие условия.

Ради эксперимента я запустил очередной тест записи нулями. Результат узнаю завтра.

tb4/usb4 - 40gbit/s/port? ну и скорость интерфейса vs скорость флешпамяти.

Я ничего не понял. Если можно, расшифруйте, пожалуйста.

Скорость интерфейса осталась неизменной. Но скорость записи упала.

а память какая во флешке - SLC/MLC?
ну и 1гбит против 5 на интерфейсе, такое.
топовые transcend/lexar - 400мбайт/с sustained.

Вот характеристики похожего USB SSD: https://www.techpowerup.com/ssd-specs/netac-zx20-1-tb.d1725

Про флеш-память там написано:

• Micron TLC 3D NAND, 2 chips, 8 dies per chip, 4 planes per die
• 16KB page, tProg = 492us

Тогда получается скорость записи

• 16KB/492us=30 MB/s per plane, 120 MB/s per die, 960 MB/s per chip, 1920 MB/s всего

Вот как при этом получается всего 120 MB/s? Прошивку писали тайваньские китайцы.

предположу что вас обманули те самые хитрые тайваньские китайцы :)

Вчера я сразу же запустил следующий тест на ночь. Скорость записи ещё немного упала, но уже похоже на приближение к какому-то равновесию.

# dd if=/dev/zero of=/dev/sdb bs=64M iflag=fullblock oflag=direct
512110190592 bytes (512 GB, 477 GiB) copied, 17623.4 s, 29.1 MB/s

А разве данные /dev/urandom формируются не в отдельном потоке?

strace на dd запустите и посмотрите. ЕМНИП, он сначала делает read() с размером блока, потом write(). Но, может что и поменялось.

не рассматривать мелкоблочку

Для меня мелкоблочка это килобайты. Алгоритмы чтения и записи флеш-памяти сильно различаются. Чтение — это просто чтение, разве что как-то метаданные неудачно сформировались и всё время не влазят в кеш контроллера, он всё время вынужден считывать с флеша информацию, где находится тот или иной блок данных. А запись идёт через SLC-кеш, требует список готовых к записи блоков и т.д. Вполне возможно, что контроллер флешки не имеет в кеше такого большого списка готовых к записи блоков, чтобы уместить 64 мегабайта. Может 900 МБ/с достигаются только при мелких блоках и общим объёмом десяток-другой мегабайт.

лишь 32 МБ/сек.

Дикость какая-то, ИМХО, производитель на такие объёмы и скорость интерфейса мог бы уж поставить контроллер поумнее, который понимает, что там одни нули и не писать их, а просто помечать блок свободным.

Вот как при этом получается всего 120 MB/s?

Где получается 120 Мегабайт/с? Там средняя скорость записи всего накопителя 272 МБ/с, а в SLC-кеш 1600 МБ/с.

У топикстартера получается 120 MB/s. При первом проходе после покупки. А сейчас у него вообще 30 MB/s. Сделает blkdiscard, наверное опять поднимется до 120 MB/s.

У топикстартера получается 120 MB/s. При первом проходе после покупки. А сейчас у него вообще 30 MB/s. Сделает blkdiscard, наверное опять поднимется до 120 MB/s.

blkdiscard сделаю позже. А пока я хочу понять, до какого предела скорость продолжит падать.

Сегодня я сделал ещё одну полную перезапись нулями, и скорость снизилась. И картина уже не столь похожа на приближение к какому-то стабильному уровню, как мне казалось в прошлом тесте.

512110190592 bytes (512 GB, 477 GiB) copied, 19281.2 s, 26.6 MB/s

Собственно, вопрос: Почему скорость падает с каждой новой перезаписью? Такое поведение не согласуется с моим пониманием работы флеш-памяти. Напомню: blkdiscard для этой флешки я не выполнял ни разу.

Вполне возможно, что контроллер флешки не имеет в кеше такого большого списка готовых к записи блоков, чтобы уместить 64 мегабайта

Я согласен с этим аргументом, предостережение разумное. Тем не менее в бенчарке gnome-disks, в начале которого я смог получить заявленную производителем скорость записи, я как раз использовал размер блока 64 MiB, тут мне повезло. К gnome-disks я планирую вернуться позже, когда начну экспериментировать с blkdiscard.

ИМХО, производитель на такие объёмы и скорость интерфейса мог бы уж поставить контроллер поумнее, который понимает, что там одни нули и не писать их, а просто помечать блок свободным.

Я тоже не ожидал увидеть такого поведения этой флешки. Но, с другой стороны, измерения получаются более правдоподобными.

blkdiscard я не делал. Как не делал и вчера между тестом записи с /dev/urandom и /dev/zero. С этой точки зрения оба теста записи нулями имеют похожие условия.

У меня появилась гипотеза. Я смогу проверить её позже, но, возможно, у кого-то уже есть готовый ответ.

Между этими двумя тестами я не выполнял blkdiscard, но я запускал gnome-disks и перед запуском бенчмарка я машинально создал раздел на весь доступный объём флешки. Возможно, blkdiscard для нового раздела был запущен неявным для меня образом.

512110190592 bytes (512 GB, 477 GiB) copied, 19281.2 s, 26.6 MB/s

Ещё одна перезапись нулями:

512110190592 bytes (512 GB, 477 GiB) copied, 19770.8 s, 25.9 MB/s

Скорость продолжает снижаться, но я закончу эту серию экспериментов. Пора проверить другие режимы работы флешки.

Я забыл проверить свою гипотезу, поспешив запустить blkdiscard.

Выполнил несколько тестов записи в gnome-disks. Перед каждым тестом записи я запустил blkdiscard.

 2k x   2 MiB: 899 MB/s
 1k x   4 MiB: 900 MB/s
512 x   8 MiB: 911 MB/s
256 x  16 MiB: 922 MB/s
128 x  32 MiB: 933 MB/s
 64 x  64 MiB: 935 MB/s
 32 x 128 MiB: 939 MB/s
 16 x 256 MiB: 941 MB/s
  8 x 512 MiB: 941 MB/s

Максимальная скорость записи достигнута для блока размером 256 MiB, составив 941 MB/s.

Эксперименты с blkdiscard + dd:

# blkdiscard -f /dev/sdb; dd if=/dev/zero of=/dev/sdb bs=256M count=16 iflag=fullblock oflag=direct
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 5.02245 s, 855 MB/s

. bs=256M count=32 
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 10.0078 s, 858 MB/s

. bs=256M count=64
17179869184 bytes (17 GB, 16 GiB) copied, 20.0643 s, 856 MB/s

. bs=256M count=128
34359738368 bytes (34 GB, 32 GiB) copied, 40.1018 s, 857 MB/s

. bs=256M count=256
68719476736 bytes (69 GB, 64 GiB) copied, 204.592 s, 336 MB/s

Объём в 32 GiB можно записать за 40 секунд со скоростью 857 MB/s. Отличный результат, я считаю. Объём в 64 GiB пересылается уже не так быстро, со скоростью 336 MB/s.

Вопрос: Почему тест записи с помощью dd показывает меньшую скорость в сравнении с тестом в gnome-disks?

Кто ж его знает, что там делает и что считает этот gnome-disks. По strace видно, что он одним потоком делает блокирующиеся вызовы read, write, fsync:

lseek(11</dev/sdc>, 833617920, SEEK_SET) = 833617920
read(11</dev/sdc>, ""..., 4096) = 4096
lseek(11</dev/sdc>, 833617920, SEEK_SET) = 833617920
read(11</dev/sdc>, ""..., 2097152) = 2097152
lseek(11</dev/sdc>, 833617920, SEEK_SET) = 833617920
read(11</dev/sdc>, ""..., 4096) = 4096
lseek(11</dev/sdc>, 833617920, SEEK_SET) = 833617920
write(11</dev/sdc>, ""..., 2097152) = 2097152
fsync(11</dev/sdc>)                     = 0

Хочешь настоящий инструмент для бенчмаркинга – бери fio.

можно ещё попробовать поиграться с /sys/block/sdX/queue/read_ahead_kb

можно ещё попробовать поиграться с /sys/block/sdX/queue/read_ahead_kb

А это как-то повлияет, если я тестирую флешку с помощью dd с флагом direct? Меня в первую очередь интересуют аппаратные возможности флешки. И преимущественно режимы последовательного чтения-записи относительно крупными кусками.

Для такого берут pcie 4-5 nvme.

Выше уже пояснили за SLC кеш. Ещё веселее будет когда условно 90% объёма флешки будет забито. Тогда она и 100 МиБ/с скорее всего не возьмёт потому что кеша не будет совсем.

Так и вышло. Я сделал серию тестов записи с предварительной очисткой ячеек перед каждой записью. Первые 47 GiB пишутся на скорости 840-850 МБ/сек, затем скорость стабильно держится на уровне 121 МБ/сек, и где-то на оставшихся 90% скатывается до 70-90 МБ/сек. Причём, не играет роли, заполняю ли я флешку от начала к концу или от конца к началу. Заполняю я крупными кусками по 32 GiB.

Получается, что я не могу использовать эту флешку в том режиме, в котором планировал: вставить в комп, быстро записать данные, вытащить флешку, вставить в другой комп, быстро прочитать данные и сразу вытащить. Флешке потребуется время на перенос данных из кеша. А без питания она это не сделает. Для неё нужен другой сценарий использования.

В целом я понял, чего от этой флешки ожидать, и как её можно использовать без неожиданностей в отношении скорости.

Спасибо всем, кто помогал мне разобраться в этом.

У меня остался один вопрос, но он в большей степени теоретический. Почему, если не очищать ячейки, при многократной перезаписи всего объёма скорость записи на флешку продолжает деградировать?

Мне хорошо понятна ступенька на первых 10% заполнения флешки, когда кеш не успевает освободиться. Смутно понятна ступенька, когда незаполненными остались последние 10% объёма флешки. Но совершенно непонятно, почему скорость продолжает падать при кратной перезаписи. Где-то там тоже наверняка присутствуют ступеньки, но я их пока не искал.