И снова про Phison E13T, QLC NAND и искусство дрессировки SLC-кэширования

| Обзор | HDD, SSD, флешки, прочие носители информации

Недавно бегло знакомились с новой бюджетной QLC-платформой Phison на примере Seagate Barracuda Q5 500 ГБ, теперь вот появилось – чем дополнить. Тут может возникнуть вопрос – а стоит ли вообще уделять столько внимания подобным бюджетным (даже уже, скорее, ультрабюджетным) накопителям. Во-первых, их таких будет много. В розницу подобными моделями уже точно торгуют Corsair и Silicon Power. Возможно, и не только они – просто специально не искал, а так-то продукт доступен всем партнерам Phison, да и непопулярным ему оказаться сложно. Хоть истинные гурманы и будут крутить носом, но дешевые накопители всегда продаются лучше дорогих. Во-вторых, еще большую популярность такое получит в ОЕМ-сегменте – поскольку какой там в ноутубке SSD пока не купишь не узнаешь, и носом покрутить даже не выйдет. Причем на обзоры даже ориентироваться бесполезно, поскольку для них могут существовать специальные сэмплы… но, кстати, пару «тысячедолларовых» ноутбуков с SSD на четырехканальной модификации Phison E12 и QLC NAND нам уже за последний год точно приносили, а E13T еще дешевле благодаря отсутствию DRAM, так что тем более интересен производителям. Так что и покупателям желательно об этом всем знать побольше – шансы столкнуться велики. Ну и третий пункт (для меня так самый важный) – с бюджеткой играться даже интереснее. Не в том плане, что можно сделать какие-то великие открытия – а в том, что там вообще хот чего-то накопать можно. Optane SSD тестировать скучно – там своей дури достаточно, чтоб каких-то ухищрений не придумывать. В недорогом SSD всяких программных костылей, маскирующих врожденные недостатки будет много.

Вот один нашелся. Интересный с точки зрения теории. Напомню – о чем вообще речь: Seagate Barracuda Q5 это линейка SSD на базе контроллера Phison E13T и 96-слойной QLC 3D NAND Micron с кристаллами по 1 Тбит. Таковых может быть 4, 8 или 16 – что дает емкость в 500 ГБ, 1 ТБ или 2 ТБ. Высокие скорости достигаются исключительно в пределах SLC-кэша, причем для младшей модели это будет верно и при чтении данных: всего четыре кристалла без чередования сами по себе даже читаются не быстро. Чуть более дорогие модели на TLC побыстрее не только из-за того, что сама по себе такая память быстрее, но и потому, что кристаллы там обычно по 512 Гбит или даже 256 Гбит – так что их самих больше. И весь массив памяти в итоге быстрее. Но для QLC «однобитный режим» (т.е. то самое SLC-кэширование) вообще жизненно важен.

Что в этом плане известно про последние контроллеры Phison? Во-первых, под кэш они могут использовать весь массив ячеек. Т.е. в теории «быстро» записать можно примерно треть свободного места в SSD на TLC и четверть на QLC. На деле – чуть-чуть больше, поскольку есть небольшой резерв емкости для выравнивания износа и замены «умирающих» ячеек, но не принципиально. Таким образом, максимальная емкость SLC-кэша при 500 ГБ QLC NAND составляет порядка 125 ГБ. Но это в идеале – поскольку «расчищать» кэш большинство современных контроллеров не рвется. И касается это не только Phison. Логика в этом есть – если накопитель используется в качестве «системного», большинство операций записи – это временные файлы. Создаются, раз-другой читаются и удаляются. Специально освобождать место не нужно, записывать их на долгое хранение – тем более не нужно. Нужно как раз просто быстро записать и быстро же прочитать. Что и сделано. Такая логика работы сносит крышу низкоуровневым утилитам, поскольку они сами (внезапно!) работают также: создают небольшой временный файл, немного внутри него чего-то делают, а потом удаляют. Но не для них, в общем-то, все затевалось. На практике подход полезный.

До тех пор, пока мы не пытаемся записать реально много информации – и надолго. Кэш при этом рано или поздно «кончится», а раз под него ушли все ячейки – то дальше экстренно придется и старые данные ужимать, и новые принимать. Поэтому в таких случаях скорость записи оказывается более низкой, чем могла бы без SLC-кэширования. В общем, нельзя быть на практике одновременно быть здоровым и богатым (точнее, можно – но только если изначально ну очень богатым). На практике оно не слишком мешает при использовании устройства по прямому назначению. А вот если поставить такой SSD дополнительным под данные – будет мешать. Равно как и в том случае, когда на нем этих самых «долговременных» данных относительно много, да еще и они регулярно обновляются. При большой емкости такое может получиться и на практике: если это основной и единственный SSD в ноутбуке. А может и для дополнительного не получиться – если это второй SSD «чисто под игрушки» например. В общем, просто все нюансы нужно учитывать заранее.

Но делать это просто только в «вырожденных» случаях. Например, если мы пытаемся записать на SSD весь его объем за короткое время. Получаются характерные графики, к которым уже все привыкли. А если заполнение происходит не одномоментно, но пишем мы «больше кэша» и в процессе ничего не стирая? Тут какая-то часть данных будет расчищаться – чтобы можно было опять писать быстро. Варианта работы два – «житейская» очередь (FIFO) и стек (LIFO). С первым – понятно: первыми в основной массив переносятся самые старые данные из кэша, причем даже если он еще «не кончился», но просто прошло отведенное время – раз уж сразу не стерли, значит, наверное, надо хранить. Но при той же оптимизации «под темпы» — возможен и второй: чем позже записали, тем больше шансов, что сотрут (не через час, так через два). А что мы имеем в этом случае?

Тут на помощь приходит старый добрый NASPT. Картинка чуть отличается от более ранней – поскольку это другая платформа и, главное, немного другое программное обеспечение. Но это детали. А вот значима логика работы программы и способ ее использования: сначала она записывает файлы, которые будет читать любым способом или писать с произвольной адресацией, а потом уже идут сами тесты. Можно сразу после создания файлов, можно с паузой – чтоб внутренние процессы после подготовки успели завершиться. Я, естественно, давно пользуюсь вторым способом. А для тестирования в заполненном состоянии между «подготовкой» и тестированием на накопитель записывается еще куча файлов на 80+% емкости, которым тоже даем отлежаться с пол-часика.

Процесс создания файлов идет снизу вверх (если смотреть по диаграмме), первая подготовительная (обязательная) фаза – 160 ГБ, дополнительная до повтора тестов – еще 240 ГБ. Судя по результатам, самые старые файлы вытесняются только на стадии заполнения – почему падает скорость их чтения. Несмотря на то, что записали мы, вообще-то, и при подготовке больше, чем емкость кэша – «чистить» его контроллер практически не желает. Поэтому, кстати, и скорость записи оказывается стабильно низкой – а некуда писать быстро. Запас ячеек не сделан.

Вот если стереть что-то записанное – точно появится. Но только в тех количествах, сколько сотрем. Поэтому подойдем к вопросу получения красивых циферок просто «в лоб»: все тесты будет готовить и запускать по одному. Причем по циклу «подготовка-прогон-очистка». В этом случае у нас самый большой объем предварительной записи – 64 ГБ, т.е. от максимальных для пустого SSD 125 ГБ свободна почти половина.

Красное – это тестирование пустого накопителя, и синее – это тестирование пустого накопителя. В одинаковых условиях, одной программой – но с небольшой сменой алгоритма ее использования. Заявленные скоростные показатели, кстати – 2300 МБ/с при чтении и 900 МБ/с при записи. На чтении получилось чуть меньше, а на записи – даже больше. Главное – «правильно» читать и писать: не выбираясь за пределы SLC-кэша. И тут, кстати, повезло в какой-то степени, что попался накопитель всего на 500 ГБ – у терабайтного Q5 кэша уже порядка 250 ГБ, так что после записи 160 ГБ там бы осталось достаточно места, чтобы все проскочило без сучка без задоринки, а проблемы начались бы на следующем этапе тестирования – после заполнения данными «до упора».

Низкоуровневые же утилиты «пробить защиту» не могут – они создают маленький файл, что-то с ним делают и удаляют. И именно маленький – по-умолчанию всего-то с 1 ГБ обычно. А это даже на уже «пожившем» и поработавшем накопителе с вероятностью 146% попадет в кэш. Единственный вариант что-то увидеть – как раз в таком состоянии (а не из коробки) прогнать какой-нибудь CrystalDiskMark не менее двух раз и сравнить результаты. При повторном запуске они должны увеличиться – поскольку создание и удаление рабочего файла при первом «расчисти» место в кэше. Только никто так не делает обычно. И вообще считается, что для бюджетных SSD подходят простые и быстрые методики тестирования. Да нет – простых как раз достаточно разве что для топовых моделей: где все и так хорошо. Без дополнительных ухищрений – способных сильно испортить жизнь, если разработчики «не угадают» с рабочими сценариями.

Ну а основные выводы не меняются. Бояться QLC не нужно. Избегать при прочих равных – полезно. Поскольку оно и на том же кэшировании скажется: потенциальный размер SLC-кэша на 500 ГБ, соответственно, 125 и 166 ГБ – так что и реально в него «попасть» на TLC будет проще. Ну а так основная «хорошая» ниша для SSD на этой памяти – дополнительные накопители, причем высокой емкости. В этом случае и экономический эффект более заметен – и тормозов поменьше. По разным причинам возникающих – но результат-то одинаковый.

 

2 комментария

AnotherStranger
Толку мало от разницы последовательной чтении/записи в домашних системах на современных SSD дисках. Их надо сравнивать по самому узкому месту — рандомное чтение/запись мелких файлов (на заполненном диске). Именно эта операция больше всего «тормозит» работу диска.
Последний раз редактировалось
222934529@vkontakte
А чё ты хотел сына маминой подруги?

Добавить комментарий