
- Цена: $30.00
Коробка упакована в пакет с пупыркой, дополнительно пару слоев амортизирующего материала.
В коробке с окошком, через которое видно плату, находится пластиковая форма, пазы в ней универсальные — туда можно положить m.2 2280, m.2 2242 и msata, причем одновременно.
Вообщем все это малоинтересно кроме того что приехало в целости и даже коробка почти не помялась.
Рассмотрим сам накопитель. Плата односторонняя, на нижней стороны нет ни элементов, ни мест под них. Что нетипично — ключ разьема type M, хотя использующие 2 линии накопители чаще делают в виде type B. Пайка аккуратная, флюс полностью отмыт.
Флеш:
Контроллер:
На снимках у продавца можно было увидеть 128G версию с флешем с левой маркировкой micron 29F512G08EEHAF в количестве 2шт — если верить обозначению это 2хкристальные сборки B16A (tlc, 64L, 256gbit) и 240G — spectek pgf36 -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
и
Copyright © 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: KINGBANK KM220 128GB
Serial Number: I47ZS3H000932
Firmware Version: V2.4.A
PCI Vendor/Subsystem ID: 0x1d97
IEEE OUI Identifier: 0x5b6230
Controller ID: 0
Number of Namespaces: 1
Namespace 1 Size/Capacity: 128 035 676 160 [128 GB]
Namespace 1 Utilization: 0
Namespace 1 Formatted LBA Size: 512
Local Time is: Wed Jan 09 20:50:48 2019 RTZST
Firmware Updates (0x02): 1 Slot
Optional Admin Commands (0x0004): Frmw_DL
Optional NVM Commands (0x000c): DS_Mngmt Wr_Zero
Maximum Data Transfer Size: 64 Pages
Warning Comp. Temp. Threshold: 100 Celsius
Critical Comp. Temp. Threshold: 120 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 3.20W — — 0 0 0 0 0 0
1 + 3.00W — — 1 1 1 1 10 10
2 + 2.70W — — 2 2 2 2 10 10
3 — 0.2700W — — 3 3 3 3 10 1500
4 — 0.0050W — — 4 4 4 4 8200 6000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x00
Temperature: 47 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 0
Data Units Written: 0
Host Read Commands: 6
Host Write Commands: 0
Controller Busy Time: 0
Power Cycles: 1
Power On Hours: 0
Unsafe Shutdowns: 0
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 47 Celsius
Error Information (NVMe Log 0x01, max 8 entries)
No Errors Logged
в отчете 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_MACHINESYSTEMCurrentControlSetControlStorPort
ключа 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 DeviceRaidPort2 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, т.е. дефектов не так уж и много.
(c) 2017 Источник материала