KingBank KM220 128GB m.2 pcie3x2 nvme ssd на контроллере marvell 88nv1160

Дешевый pcie/nvme накопитель возбудивший к себе сугубо академический интерес достаточно редко встречающимся контроллером — marvell 88nv1160. С практической точки зрения его использование вряд ли оправдано.

Коробка упакована в пакет с пупыркой, дополнительно пару слоев амортизирующего материала.
В коробке с окошком, через которое видно плату, находится пластиковая форма, пазы в ней универсальные — туда можно положить m.2 2280, m.2 2242 и msata, причем одновременно.



Вообщем все это малоинтересно кроме того что приехало в целости и даже коробка почти не помялась.

Рассмотрим сам накопитель. Плата односторонняя, на нижней стороны нет ни элементов, ни мест под них. Что нетипично — ключ разьема type M, хотя использующие 2 линии накопители чаще делают в виде type B. Пайка аккуратная, флюс полностью отмыт.



Флеш:


Контроллер:


На снимках у продавца можно было увидеть 128G версию с флешем с левой маркировкой micron 29F512G08EEHAF в количестве 2шт — если верить обозначению это 2хкристальные сборки B16A (tlc, 64L, 256gbit) и 240G — spectek pfg36 -5 as, однокристальные B17A (tlc, 64L, 512gbit), 4шт.
По факту приехало нечто с маркировкой неизвестного происхождения TS1256G151 4шт, про которую даже гугль не слышал.

Пара слов про контроллер — это безбуферный (dramless) контроллер, с поддержкой host memory buffer (hmb) — использования для своих нужд буфера выделенного из основной памяти. Поддержка hmb есть в стандартном драйвере nvme из состава windows 10 версии 1607 и выше, другие драйвера с таковой поддержкой мне не известны.

Перейдем к тестам.
В качестве стенда использовалась z77+i7-3770k, накопитель был установлен во втором процессорном слоте pcie x16 в таком вот переходничке (соответственно процессорные линии для видеокарты урезались до 8):


Тесты проводились под windows 10 версии 1703 с использованием драйвера stornvme, так же windows 7 sp1 с использованием драйвера samsung v1.4. В обеих системах в свойствах накопителя была включена настройка «Отключить очистку буфера кэша записей Windows для этого устройства».

Информация о диске от CDI


и


в отчете smartctl можно заметить нетипичную особенность — прошивка не поддерживает команду Format Unit, которую можно применять для полной очистки накопителя (примерно как secure erase у sata, хотя и там и там это не основное их назначение), что полезно для аккуратности при тестировании. В итоге для очистки диcка пришлось использовать трим (создаем/форматируем раздел, удаляем раздел в консоли управления дисками ос).
Так же видно что поддерживается единственный размер сектора — 512 байт. Например контроллеры от phison (E7/E8) поддерживают так же и 4k.

Сначала на пустой диск была осуществлена запись всего обьема посредством aida/diskbench, выполнено чтение записанного диска, и повторная запись без очистки — посмотреть каким образом осуществляется slc-кеширование. Для кеширования используется почти весь доступный обьем, и раз он чуть выше трети — значит флеш действительно tlc.
Так же видно, что повторная запись выполнялась напрямую в tlc режиме. Чтение при блоке в 1M не достигает максимальных показателей.




Дополнительно был проведен эксперимент с записью очищенного диска с паузами в моменты заполнения slc-кеша, для того что бы контроллер мог сбросить кеш в tlc. Пометки на графике — время необходимое для этого копирования, контролируемое по потреблению. Видно что до 90% заполнения доступного пользователю обьема контроллер в фоне осуществляет сброс slc-кеша, а далее идет прямая запись в tlc.


Рандомная запись на пустой диск 4k блоком с выравниванием на 4k и очередью в 32:


Вернемся к исследованию работы HMB. Накопитель поддерживает буфер следующего размера:
HMB Preffered Size: 122880 KB
HMB Minimum Size: 8192 KB

Драйвер stornvme умолчательно использует следующие настройки:
HMB: Enabled
HMB Size: 64 M

Это поведение можно настроить путем создания в разделе реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorPort
ключа HMBAllocationPolicy типа DWORD со следующими значениями.
0 = Disabled
1 = Minimum
2 = Maximum
3 = Device Usage Based
параметр применяется после перезагрузки.

Были проверены все перечисленные варианты:
0:
HMB: Disabled
HMB Size: 0 M

1 или 3:
HMB: Enabled
HMB Size: 8 M

2 или отсутствие параметра:
HMB: Enabled
HMB Size: 64 M

так же эту информацию можно увидеть в журнале событий системы в разделе:
Microsoft-Windows-Storage-Storport/Operational
в следующем виде, например для значения «2»:
Host Memory Buffer Allocation for \Device\RaidPort2 succeeded.
Failure Reason: None
Allocation Policy: Maximum
Attemped to Allocate: 0x4000000 bytes
Actually Allocated: 0x4000000 bytes
Device Minimum: 0x800000 bytes
Device Preferred: 0x7800000 bytes
Policy Maximum: 0x4000000 bytes

По идее буфер используется для кеширования данных транслятора, и его влияние должно проявляться при произвольном доступе к области диска разного обьема.
Для диска последовательно прописанного по всему обьему были выполнены замеры скорости произвольного чтения блоком 4k выравненным на 4k и глубиной очереди в 32.

По всему обьему:


Растянутый график первых 10%.


Зависимость от обьема и наличия HMB достаточно хорошо прослеживается, если без HMB резкое падение скорости происходит на области менее гигабайта, то с минимальным размером уже 5-10 гигабайт, а с 64M спад растягивается на весь обьем. К сожалению каким образом можно разрешить выделение буфера максимального, поддерживаемого диском, обьема мне неизвестно.

Рассмотрим результаты прочей синтетики в двух вариантах, под W7 и под W10 с 64M HMB.
ATTO с разной глубиной очереди (1/4/8):




CDM5 с размером области в 100M/1G/4G:



на рандомном чтении видно значительное преимущество при использовании HMB, на записи же в рандомных подтестах наоборот, но возможно это связано с отличием применяемых драйверов.

Факультативно CDM 3/6 версий, позволяющие убедится что в целом их результаты (в схожих подтестах) близки к CDM5:



Некоторые замеры потребления: в простое потребление составило ~0.21А (стенд не обеспечивал режимов глубокого сна), максимум достигался на последовательном чтении — 0.80А, на записи в slc-кеш — 0.53А. На произвольном доступе потребление было ниже.

Максимальная температура по смарту, которую удалось достичь, составила 73C при ~27C окружающей среды, пирометр при этом намерял на контроллере градусов на 5 ниже, также во время чтения (потребовалось ~12 минут и 6 обьемов, после чего температура стабилизировалась). Троттлинга при этом не наблюдалось.
С небольшим паразитным обдувом от вентилятора видеокарты температура была градусов на 15 ниже (пришлось прикрыть «окно» в переходнике).

Сколь либо заметных задержек во время отработки трим отмечено не было.

В процессе ознакомления с диском выяснилась странная особенность — ресурс его расходовался слишком быстро, в частности к концу тестов набежало целых 11%:


Было решено оценить, какой предел по циклам стирания использует прошивка для вычисления нормализованного показателя. Как выше выяснено, полностью записанный диск повторно пишется в tlc режиме напрямую, при этом wa обычно весьма близок к 1, что позволяет провести следующий эксперимент: был запущен тест, выполняющий циклическую перезапись всего обьема (для этого использовался hd_speed) с параллельным ежесекундным ведением лога смарта. Вот выдержка из него двух моментов перехода процентов расхода ресурса, 7->8 и 8->9:
Time(ms), Temp( C ),HostRead(GB),HostWrite(GB),Used(%)
3515093,57,3623,1959,7
3516078,57,3623,1959,8
…
8834093,57,3623,2650,8
8835078,57,3623,2650,9

получается 2650-1959=691GB на 1%.
тут следует отметить, что у современного флеша полный обьем в идеальном случае (отсутствие заводских дефектов) несколько превосходит ближайшую степень двойки. Например один из вероятных кандидатов — imft B16A, содержит 1008 блоков по 36MB, или ~110.7% от формально декларируемых «256gbit» или ~141.75GB для 4х кристаллов.
Вернемся к определению предела
691/128~5.4, а с учетом вышесказанного вероятно это 5 ровно. т.е. 100% — 500 циклов. Аномально скромно для достаточно современного контроллера с поддержкой ldpc. Остается надеяться что константа была задана «от балды», и «100%» расход ресурса по смарту не означает вообщем-то ничего.
Заодно можно прикинуть, что полный обьем флеша составляет 691/5~138GB, т.е. дефектов не так уж и много.

upd.05.2020 немного подробностей насчет флеша, действительно B16A:

v0.1a
OS: 10.0 build 15063 
Drive   : 4(USB)
Model   : KINGBANK KM220 128GB                    
Fw      : V2.4.A  
Size    : 122104 MB
LBA Size: 512
AdminCmd: 0x00 0x01 0x02 0x04 0x05 0x06 0x08 0x09 0x0A 0x0C 0x10 0x11 0xFD 0xFE
I/O Cmd : 0x00 0x01 0x02 0x08 0x09
FwInfo  : DM1160-B0 -V2.4    -Apr 17 2018 13:09:47 svn-135
NandInfo: MICRON_3DT_1DIE_B16A_DW_DC
Bank00: 0x2c,0xa4,0x8,0x32,0xa1,0x0,0x0,0x0 - Micron 64L(B16A) TLC 256Gb/CE 256Gb/die
Bank02: 0x2c,0xa4,0x8,0x32,0xa1,0x0,0x0,0x0 - Micron 64L(B16A) TLC 256Gb/CE 256Gb/die
Bank04: 0x2c,0xa4,0x8,0x32,0xa1,0x0,0x0,0x0 - Micron 64L(B16A) TLC 256Gb/CE 256Gb/die
Bank06: 0x2c,0xa4,0x8,0x32,0xa1,0x0,0x0,0x0 - Micron 64L(B16A) TLC 256Gb/CE 256Gb/die
Flash params:
00 00 00 00 | f8 01 04 00 | 00 48 00 00 | 00 18 00 00
00 20 01 00 | 00 60 00 00 | 00 10 a0 48 | 20 00 08 00
2c 00 02 04 | 01 01 00 00 | 00 18 08 00 | 04 00 08 00
Block/Plane: 504
Plane      : 2