Обзор и тестирование SSD-накопителей: обновляем методику

Оглавление

• Вступление
• Размышления
• Новые тесты и реализация
• Тестовый стенд и ПО
• Участники тестирования
• Тестирование производительности
• Заключение

Вступление

На дворе 2016-й год. Твердотельные накопители на флеш-памяти (SSD) на постоянной основе мы тестируем уже три года, опубликовав за это время 116 материалов, а база результатов замеров производительности насчитывает уже 356 строк. И при этом используется одна и та же методика, в которую лишь несколько раз вносились некоторые дополнения и вводились новые тесты, например, на способность переносить интенсивные нагрузки.

Теперь же настало время очередного обновления. И на этот раз более глобального, нежели просто добавление одного-двух графиков. Сам по себе материал скромен в объемах, но все же отдельная публикация будет оптимальной. Помимо того, что не потребуется раздувать в объеме обычные обзоры, копируя из одного в другой полное описание, мы как бы проведем границу между старой и обновленной версиями методик.

Размышления

Методика, не претерпевающая серьезных изменений – это не так плохо на самом деле: мы получаем полную совместимость и возможность сравнить напрямую, например, Crucial V4 и OCZ Trion 150. А использование нехитрого широкодоступного программного обеспечения с простыми настройками позволяет любому пользователю без особых знаний повторить практически полностью весь комплект тестов самостоятельно и сравнить цифры. И в целом эта методика со всеми дополнениями актуальна и сегодня.

Тем не менее, в нее периодически вносились некоторые изменения и добавлялись новые тесты. Таковым, например, стало тестирование твердотельных накопителей посредством Iometer на устойчивость скоростных характеристик и работу алгоритмов «сборки мусора».

А недавно из списка публикуемых результатов тестов мы исключили показатели, получаемые на блоках из однородных данных, которые хорошо поддаются компрессии.

Скоростные характеристики в этом тесте впечатляющи, но, во-первых, процесс ухода контроллеров SandForce практически закончился, накопителей на их основе в продаже осталось не так много. Даже Intel и Kingston, бывшие несколько лет ведущими производителями моделей на контроллерах SandForce, начали склоняться к использованию иных платформ. Например, в ассортименте Kingston сейчас осталось только два SSD на базе SandForce – SSDNow V300 и HyperX Fury. Intel, вернувшись к своим собственным контроллерам в 730-й серии, позже выпустила 535-ю серию, но ее дни уже сочтены: на уходящей неделе были анонсированы накопители на контроллерах Silicon Motion.

Во-вторых, актуальность алгоритмов компрессии данных сильно снизилась – ныне у пользователей в ходу уже изначально хорошо сжатые данные: достаточно вспомнить, что используемый современными офисными пакетами Microsoft формат Open XML (docx, xlsx и т.д.) изначально применяет сжатие ZIP. Другой, не менее популярный тип данных тоже изначально хорошо сжат – изображения, видео.

Но в то же время на рынок сейчас постепенно выходят все новые и новые конфигурации SSD, а производители оных старательно работают над микрокодами, внедряя все новые и новые алгоритмы, не в последнюю очередь нацеленные на повышение производительности при изначально слабой аппаратной платформе. Последним и очень серьезным сочетанием «конфигурация плюс алгоритмы» стал запуск в серийное производство накопителей на TLC NAND производства Micron и Toshiba.

Методика тестов должна отвечать подобным нововведениям, а потому периодически подвергается актуализации. Таким дополнением в этот раз станет введение новой группы тестов на смешанную нагрузку и операций с переменным размером блоков данных. С первым все понятно, но чем продиктовано второе? Оно объясняется еще одним процессом: емкость накопителей растет. Нет, общая планка объемов выпускаемых накопителей пока остается неизменной (по сути лишь Samsung выпустила на рынок Samsung 850 Evo/Pro объемом 2 Тбайт и говорит о скором дебюте версий на 4 Тбайт). Растет величина объемов, интересующих пользователей – цена моделей постоянно снижается и в ряде случаев пользователи берут один емкий SSD, а от HDD отказываются полностью.

Новые тесты и реализация

Встает вопрос о том, как проводить такие тесты. Изобретать велосипед нет смысла: многими ресурсами принято использовать приложение Iometer. И оно потрясающе, учитывая, что первая версия была анонсирована еще в 1998 году. Проект прекратил свое развитие в 2001 году, но в том же году был передан сообществу энтузиастов и в 2003 году пережил второе рождение. Правда, ненадолго: последняя версия вышла в 2006 году. Некоторая жизнь теплится на SourceForge, но принципиальных обновлений более не выпускается.

Причины этого просты: в любом деле нужно знать меру и после определенного момента программный пакет достигает какого-то уровня, достаточного большинству пользователей, когда дальше усовершенствовать уже нечего и начинается не развитие, а «обновление ради обновления»: версия программы растет, но количество полезных нововведений стремится к нулю. Не будем называть конкретные названия, просто скажем, что один такой пример установлен сейчас на 90% персональных ПК.

К счастью, проект Iometer не пошел по этому, крайне модному сейчас пути – здесь нет ни новомодных кнопок в стиле «Metro», ни красочной анимации, ни прочего, зато приложение при объеме чуть меньше 7 Мбайт предлагает пользователю все необходимое для полноценного подробного тестирования. Поэтому не нужно выражать негодование по поводу копирайта «1996-1999 Intel Corporation, Open Source since 2001» в справке о приложении – не в датах дело.

Остается лишь разобраться, как тестировать. Iometer – приложение, несколько отличающееся от популярных программ вроде Crystal Disk Mark или AS SSD: здесь нельзя просто нажать кнопку «Start» и получить заветные мегабайты в секунду, пользователю необходимо самому создавать специальные сценарии – размер блоков данных, их тип, характер нагрузки (случайные или линейные операции, соотношение между операциями чтения и записи, глубина очереди запросов и прочее).

По умолчанию Iometer поставляется с набором готовых сценариев, но они ориентированы скорее на серверное применение, а потому для тестирования SSD в бытовых условиях не слишком пригодны, и общепринятой методикой, сложившейся в последнее время, является иной набор тестов. К сожалению, сейчас уже сложно вспомнить, кто начал тестировать накопители по такой методике первым. Но это было давно и с тех пор переменилось многое. Выросла производительность, на смену HDD пришли SSD. А обозреватели до сих пор продолжают тестировать накопители сценариями продолжительностью, как правило, около трех минут.

Это Kingston SSDNow V Series в 2009-2010 годах под мелкоблочной нагрузкой на операциях записи мог выдавать 6-8 Мбайт/с. Сегодня же все обстоит совершенно иначе. Даже медленные модели вроде Samsung 650 120 Гбайт обеспечивают до 30 Мбайт/с, что за обсуждаемые три минуты составит больше 5 Гбайт записанных данных. Говорить же про скоростные SSD и вовсе не приходится. Например, OCZ Vector 180 240 Гбайт на одиночных операциях мелкоблочной записи способен обеспечить скорость примерно 120 Мбайт/с – больше 21 Гбайт записи. А флагманский Samsung SM951 256 Гбайт достигает 150 Мбайт/с – 26 Гбайт данных за три минуты.

Для рядового пользователя это просто фантастическая цифра сама по себе: в домашнем ПК просто нечего писать с таким характером нагрузки. Зато такие объемы возникают при копировании файлов, но тут речь об операциях крупными блоками и зачастую линейных – операционные системы давно научились в той или иной мере консолидировать данные для ускорения операций. И здесь уже совсем иные скорости и иной характер нагрузки на накопитель.

Все бы ничего, но время вмешалось и тут, достаточно вспомнить новинки второй половины прошлого года: платформы Silicon Motion и Phison, использующие TLC NAND. Накопители, построенные на них, просто физически неспособны обеспечить полноценное быстродействие при таких нагрузках. Точнее, могут, но большую часть времени скорость записи будет невысока, ибо накопителю попросту не хватит объема SLC-буфера. Тогда как в реальной жизни, что уже отмечено выше, пользователю редко приходится писать большие объемы данных. И потому полученные результаты не будут соответствовать практическому использованию.

Простой пример. Размер буфера у конфигурации Phison PS3110-S10 + 19 нм TLC ToggleNAND A19 Toshiba объемом 120 Гбайт составляет чуть меньше 1 Гбайт.

И результаты, полученные в ходе непрерывного продолжительного теста, попросту не будут отображать реальной картины, с которой придется столкнуться пользователю.

Это не отменяет того факта, что его ожидает безрадостная картина при копировании больших объемов, особенно внутри накопителя (смешанная крупноблочная нагрузка).

Как в реальной жизни не бывает только черного и только белого, так и здесь: это данность, а не крест на всей идее TLC-накопителей. Просто всякой вещи есть свое место.

Суммируя все вышесказанное, было решено прийти к двум группам тестов:

• Мелкоблочная (4 Кбайт) нагрузка чтения и записи с глубиной очереди 1, 2, 4, 8, 16, 32 и 64 на протяжении одной минуты;
• Нагрузка чтения и записи (размер блоков от 512 Байт до 256 Кбайт) с типичной для пользовательского ПК глубиной очереди 4 на протяжении трех минут.

При этом в каждой группе тесты будут разнесены по времени и между ними задан временной интервал (в зависимости от тестов, от минуты до трех), в течение которого накопитель простаивает.

Это необходимо для того, чтобы в тестируемом устройстве успевали отработать встроенные алгоритмы «сборки мусора» и это больше походило на реальное практическое применение, потому как без этого мы будем возвращаться к тому же самому: нереально большие для «домашней» эксплуатации объемы единовременно записываемых данных. Особенно это важно для конфигураций с SLC-режимом, где контроллеру нужно время для консолидации данных, записанных в таком режиме. Например, протестированному недавно Plextor M7V объемом 512 Гбайт на это необходимо около 30 секунд, что видно по его энергопотреблению.

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

• 100% чтения;
• 80% чтения и 20% записи;
• 60% чтения и 40% записи;
• 40% чтения и 60% записи;
• 20% чтения и 80% записи;
• 100% записи.

Крупноблочная же нагрузка обычно возникает лишь на операциях перемещения или копирования данных между накопителями, а потому тут нет особого смысла делать смешанную нагрузку. Здесь мы будем ограничиваться нашим традиционным набором операций с файлами. Но один тест появится и тут – параллельные линейные чтение и запись.

Все операции будут проводиться поверх файловой системы NTFS в рамках одного файла объемом 8 Гбайт, который пересоздается заново между сценариями. Значения на графиках – средние по совокупности ежесекундных замеров.

реклама