KingBank KM220 128GB m.2 pcie3x2 nvme ssd на контроллере marvell 88nv1160
- Цена: $30.00
- Перейти в магазин
Дешевый 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:
Коробка упакована в пакет с пупыркой, дополнительно пару слоев амортизирующего материала.
В коробке с окошком, через которое видно плату, находится пластиковая форма, пазы в ней универсальные — туда можно положить 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
и
smartmontools
smartctl 6.6 2017-10-25 r4570 [i686-w64-mingw32-w10-1703(64)] (daily-20171025)
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
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_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
Самые обсуждаемые обзоры
| +61 |
2632
106
|
| +48 |
2955
62
|
| +20 |
1758
31
|
| +48 |
1770
34
|
ваши бы обзоры тоже были похожи, если бы 90% обзора вы замеряли микрометром размеры всех элементов на плате.
Осталось всего ничего — выяснить что то за циферки и графики и почему они разные, и что с ними делать.
по каким параметрам и критериям оценивать?
а так да. точно, чётко и по существу.
то что нам нужно — SSD Life Left или Percentage of the Rated Lifetime Used
почему они назвали его как percentage used загадка. как и то почему засунули в 05. может в 05 и логично, типа переназначенных мы вам всёравно не покажем, да и знать сколько их умерло вам не надо?
так что вопрос-то интереснее чем кажется.
а то что он рос…
nvmexpress.org/wp-content/uploads/NVM_Express_Revision_1.3.pdf
тогда и таких странных вопросов возникать не будет.
а знать отличия в значениях СМАРТ полезно конечно, но не настолько.
Для затравки в качестве ликбеза почитайте полностью устаревший материал.
во2ых wa никто не отменял, у дисков с такой организацией кеширования он врядли окажется ниже 3-4.
но это олько когда будут писаться полные страницы если накопитель их накопит. а так как у него нет кэша, то он пишет сразу всё? что-то может в кэше оперативки держать? вот это интерсный вопрос.
2. никогда такого не получится, ибо в TLC ячейку чтобы влезло много нужно собрать целый блок и блоком записать, оно же блоками пишет? не страницами?
можно сразу смело на 2 делить? СЛЦ режим пустого накопителя это хорошо, а что будет в реальной системе, когда останется 20-30ГБ или меньше свободного места?
может поэтому СМАРТ поднял тревогу? вы начали усиленно расходовать ресурс? но это слишком сложно. тут просто так не проверить.
возвращаясь к «во1ых» 2 нолика лишних, это как? не 65ТБ, а 0,65ТБ? 650 ГБ? или какие нолики имелись в виду? к ресурсу записи? но они ЛИШНИЕ. не туда значит…
вы уже показываете как за 52 часа скушано почти 3ТБ.
такими темпами можно и ресурс проверить.
получается что таки около 65 ТБ. если производитель заложился на накладные расходы.
для получения этих 73 пришлось предпринимать ряд усилий. в частности перечитывать его в 4 потока 5-6 обьемов. не стоит.
водянное охлаждение тогда уж ставить, на винты же ставили.
Вообще странное решение от производителя сделать так.
Обзор — в избранное, использовать как методичку.
а мать не продается, вы ошиблись сайтом.
состав тестового стенда обычно пишут полностью, а на материнках ещё и БИОС могут указать.
как и ОС и использованные версии драйверов.
а то ведь как получится: Оп, а на 7-ке результаты другие, да?
забыт ТРИМ и ГК, скорее всего ещё есть выравнивание износа. это всё тоже ресурс записи флеша.
почему испорчено? а как же резерв?
TLC режим — всё равно записывается весь блок, скорее всего на такие нагрузки просто не рассчитано.
фактор времени скорее всего тоже роль играет. прогнозы строятся исходя из текущей нагрузки. или тут проще и тупее?слишком сложно, там скорее всего ничего не учитывается.P.S. А не трудно в КДИ поставить отобрражение в нормальную 10-ю систему?
Судя по тестам других бюджетных SSD, скорее всего действительно от балды. Может на нуле протянуть без ошибок не одну сотню гигабайт, а может отпахать на сотне процентов и внезапно лавинообразно сдохнуть.
есть конечно всякие emlc/etlc, в которых вроде бы запись осуществляется медленее, что бы заряд дозировался точнее. но насколько именно этот аспект влияет на ресурс, а насколько другие требования к срокам сохранности — это вопрос.