Для того чтобы убедиться в том, что SSD-накопитель быстрее магнитного диска не нужны никакие тесты. Это и так понятно. А вот в ситуации, когда нужно понять, почему на одной платформе дисковая система «подтормаживает», в то время когда этот же накопитель чуть ли не в полтора раза эффективнее в других компьютерах, — уже стоит оценить производительность диска специальными тестами. Их достаточно много. Их знают все, и все ими пользуются. Секрет их популярности зависит от методики оценки и, в конечном счете, — от того, насколько правдоподобны результаты.
В последнее время стало модным считать скорость записи файлов с помощью Java-приложений, использующих Non-Blocking I/O технологию. Наша команда тоже решила отличиться на этом поприще. Хотелось представить сообществу профессионалов свою работу в надежде услышать конструктивную критику и получить полезные советы.
NIOBench — так называется утилита, предназначенная для оценки скорости копирования файлов на магнитных и твердотельных носителях с различными интерфейсами.

Спасибо !
давно киевского гуру не было

_________________
ремонт ноутбуков, планшетов в Одессе
продажа паяльных станций Термопро ик-650
и расходных материалов для пайки и ремонта

Скачал архив, 29к, распаковал, а нет файла запуска проги.

Не надо распаковывать, файл *.jar запускается в среде Java.

Именно так, как говорит Alex Mo!
Для запуска выполняемого JAR-архива требуется установка JRE (Java Runtime Environment) в соответствии с типом платформы и ОС. После этого файлы "JAR" становятся "кликабельными" либо можно выполнить запуск в консольном режиме:
java -jar <имя>.jar
По идее, приложение будет работать и в Windows, и в Unix-подобных операционных средах. Нужно проверять.

А какой смысл мерять?
Если оно уже куплено и какое есть.
Разброс скорости одинаковых устройств составляет порядка 10-20%. В силу разброса их параметров.
Ну, а уж про систему, расположение, фрагментацию конкретных файлов на носителе, общее заполнение носителя. Это вообще - пальцев в небо, разброс скорости может быть в разы.

Метрика, как самоцель точно не нужна. Но иногда бывает полезно. Наблюдать эффективность сжатия при записи на SSD. Или деградацию SSD мониторить (хотя, об этом еще говорить рано). Инструментарий все же. Один из многих.

про деградацию и изменение скорости при ней - поподробнее пжалста

_________________
ремонт ноутбуков, планшетов в Одессе
продажа паяльных станций Термопро ик-650
и расходных материалов для пайки и ремонта

SSD скажем, весьма "дерганое" устройство.
Если с чтением еще более меннее нормально.
То на записи его колбасит, так что график похлеще чем у пилы зубья.
А все с вязано прежде всего, сколько и где чистых и грязных страниц. Внешние алгоритмы сжатия ему по барабану.
А с внутренними все на столько запутано...
Фактически в каждом устройстве, в зависимости от того какие и с какими параметрами Nand микросхемы в него попали применяется свой оптимальный под эти параметры алгоритм хранения данных.
Купив два одинаковых по торговому названию SSD, наверняка в них будут разные алгоритмы хранения данных. Не говоря о том, что просто контроллеры и микросхемы, будут совершенно не взаимозаменяемыми, от разных поставщиков.
Что было в текущий момент на складе то и поставили. Гибкое производство. Чтоб не секунды не простаивала линия.

Максим, известно точно, что SandForce имеет возможность упаковывать данные при записи в SSD. Пока нет достоверной информации, что это умеют делать другие контроллеры (мы изучали SK Hynix на SH87820BB, фактически это купленная разработка Link-A-Media Devices, — ни доказать, ни опровергнуть, но по ощущениям там нет упаковки).

Собственно, для проверки этого факта в тесте NIOBench есть два сценария: или мы измеряем скорость копирования с помощью пусть и огромного, но состоящего из одних нулей паттерна; или мы наполняем паттерн рандомизированными данными (на важно, софтверный рандомайз или аппаратный, тем более, что не все процы поддерживают аппаратный; AMD судя по всему пока не хочет, хотя и умеет). Будем собирать данные, и анализировать их.

В процессе бесчеловечных испытаний одного SSD (не будем называть производителя) обнаружилось, что со временем трансфер заметно снизился. Не катастрофически, но уже видно невооруженным глазом. Нужно и здесь собрать статистику, чтобы принять решение. Еще бы проверить себя, выполнив Secure Erase, чтобы привести SSD к состоянию "из коробки" (если это поможет, конечно). Понятно, что такие эксперименты со своими накопителями делать не стоит.

Не верный подход.
Во первых SSD в принципе не умеет писать в одно и тоже место.
Пока в LBA нули, адресации нет.
Контроллер отдает нули не читая микросхем.
Если что-то записано в любой LBA, то присвается первый чистый физический адрес страницы. Еще одна запись в те же LBA, запишет уже в новое физическое место.
А старые данные потом соберутся и занулятся одним блоком страниц. Чем больше грязных страниц, тем потери на очистку больше.
Ну а сама деградация ячеек, может проявляться только в повторных чтениях. Как только уровень коррекции ECC превысит допустимый, страница пометится как плохая и больше использоваться не будет.
Новые страницы будут назначаться мимо нее.
Т.е. даже классического ремапа у SSD нет, просто физическая адресация сдвинется на одну страницу. и так пока не упрется в последний физический адрес, который больше чем логический объем.

Эксперимент не вполне соответствует Вашим ожиданием:

Картинки отличаются.
А в чем разница в начальных условиях?

Отличаются, конечно. Там где в поле Data: Zeroes — паттерн, заполненный нулями. Там, где Software RNG — программная рандомизация (Random Generation). Паттерн размером 200 мегабайт, скопированный 10 раз. В остальном одинаково.

Это я на своем рабочем нотике запускал (Core 2 Duo T7500) с диском SSD от Intel 335-й серии. По идее, там SandForce, который умеет сжимать данные на лету для записи в NAND.

Я же вам объяснял, нули не пишутся и не читаются на SSD.
Просто физический адрес помечается. как не нужный, затем в простое, механизм сбора мусора, все эти адреса посчитает, в каком блоке их больше всего окажется, из этого блока уберет еще нужные страницы в другие блоки, и занулит весь блок.

А для логического адреса из транслятора известно, что там нули. И контроллер просто отдаст нули, не читая микросхему.

С нулями разобрались. Как быть с единицами?

Насчет единиц не в курсе.
По желанию производителя скорее всего.
Такая ситуация достаточно редкая, когда все единицы.
Но в целом на физическом уровне после зануления, в ячейках все единицы, а пишутся только нули.
Записать в место нуля единицу в принципе не возможно.
Только занулить целый блок страниц. т.е. уже записанную страницу, нельзя переписать.
И сама информация ни когда не пишется в страницы, как есть. Всегда применяется преобразование. XOR. Интерлив, чередование, сжатие, шифрование. Чтобы распределить нагрузку на ключи ячеек.

Считайте, что в изоморфном сценарии пишем единицы, иначе — псевдослучайные данные. Теперь можно перейти и к сути вопроса.

Принесут как ни будь в ремонт SSD, которую поддерживает комплекс и умеет читать через техно команды дампы микросхем.
Можно будет поиследовать эти вопросы.
А сейчас ни одного SSD нет под рукой. Себе я их не покупаю, совершенно не зачем.
Характер работы такой что все приходится хранить и копировать только на HDD в немеряных объемах. От SSD ни какого проку при такой работе.

Вышла обновленная версия 0.30. В ней уже реализовано раздельное измерение скорости чтения, записи и копирования файла. Поскольку утилита — это Java-приложение, ей без разницы, где работать: Linux, Windows — всё едино. Сегодня отлаживались по сборкой седьмого CentOS:

[align=center][/align]

При старте теста по всем полям Errore#3. Путь - корень "С".
Может, как-то связано с правами доступа? Как джава аплет стартануть с правами админа? Или среду нужно с правами запускать?

* Замечал интересный и странный нюанс. При чтении ССД в виктории при простое проца скорость ниже. Если чем грузануть проц - скорость чтения растет.
Прикол повторяем. С чем он связан?

Я запускал в конкретной директории, где с правами юзера было все ОК (см. скриншот). Наверное, пользователь должен сам озаботить эти вопросом, выбирая путь для тестирования. Стоит попробовать несколько вариантов, т.к. я лично тоже натыкался на Error #3, но ошибка не повторялась и можно было в этой же директории выполнять тест. Мы только начали отлаживаться под Линуксом, неожиданности еще ждут нас )



Хороший вопрос. Постараемся его промоделировать и в Виктории, и в NIOBench.

Если "Виктория" тестирует диск в режиме верификации, а не в режиме чтения (есть там такая опция), то проверка целостности данных производится внутри накопителя и формируется статус, а читаемые данные в память не передаются. В этом случае, трафик между накопителем и памятью практически отсутствует (будь то PIO или DMA), поэтому система может "засыпать" и впоследствии долго реагировать на прерывание.

P.S. Вышла новая версия софта NIOBench, теперь уже v0.42. Загрузить можно с этой страницы.

Работа над софтом кипит Скоро будет новая, улучшенная версия.