Чи залежить продуктивність mass storage пристрою від вмісту записуваних файлів? У часи, коли монополія на реалізацію зовнішньої пам'яті обчислювальних систем належала накопичувачам на магнітних дисках, таке питання здалося б дивним. Очевидно, у таких пристроях, час передачі файлу визначається його розміром, а також фрагментацією, що змушує пристрій виконувати додаткове позиціонування. І немає причин для виникнення залежності швидкості від вмісту, якщо говорити виключно про апаратну продуктивність, не беручи до уваги програмні драйвери, що виконують архівацію або шифрування даних на рівні файлової системи. А як справи з цим питанням у твердотільних дисків?
На це питання ми спробували знайти відповідь, написавши java-додаток, що використовує Non-Blocking I/O технологію обміну. У підсумку з'явився NIOBench, за допомогою якого можна отримати бенчмарки магнітних і твердотільних носіїв з різними інтерфейсами, а фактично - будь-якого зовнішнього накопичувача (за винятком, хіба що, пристроїв з дисципліною доступу Read Only, але і на них є свої плани).
У процесі розробки виникла низка ситуацій, коли потрібно було визначатися зі сценаріями тестування. Залишимо робочі моменти в стінах лабораторії, зупинимося детально на такому важливому аспекті, як вибір тестового патерну. Використовувати евристичні методи, як це реалізовано, наприклад, в AS SSD, не було резону: по суті, - це повторення пройденого. Вирішено було шукати свій варіант. Перш, ніж перейти до його викладу, трохи нудних спогадів.
Фактор нулів і одиниць
Сучасні мікросхеми енергонезалежної Flash-пам'яті, що застосовуються в твердотільних накопичувачах мають власний вбудований автомат запису, оптимально управляючим процесом програмування запам'ятовуючої матриці. Всередині такої мікросхеми знаходиться основна частина логіки программатора постійного запам'ятовуючого пристрою (ПЗУ). Ця обставина не тільки робить електронний пристрій компактним, але й охороняє інтелектуальну власність виробника, перетворюючи чіп на «чорну скриньку».
Тому, для наочності, розглянемо «антикварні» мікросхеми з електричним програмуванням, ультрафіолетовим стиранням і об'ємом 2 кілобайти. Очевидно, пристрої 30-річної давності істотно відрізняються від сучасних, тим не менш, ряд фізичних принципів і ефектів, зберегли свою актуальність.
Ріс. 1. Інтерфейс мікросхем містить лінії адреси, даних, управління та харчування
Як відомо, після стирання такої мікросхеми, комірки пам'яті встановлюються в стан 0FFh або «всі одиниці». Байти, значення яких має бути 0FFh можна просто не записувати. Крім того, кількість і (або) тривалість програмуючих імпульсів, необхідних для запису байту, залежить від співвідношення кількості нулів і одиниць у цьому байті. Таким чином, очевидна залежність часу запису від даних. Зазначимо, що якщо в записуваних даних нулів значно більше, ніж одиниць, розробник пристрою може прийняти рішення зберігати дані в інверсному вигляді, заощадивши не тільки час запису, але і ресурс мікросхеми і навіть деяку (нехай і мікроскопічну) частину споживаної потужності.
Фактор стиснення
Накопичувач, який архівує інформацію неминуче повинен використовувати алгоритм, що аналізує і перетворює потоки даних, що курсують між хост-інтерфейсом і матрицею Flash-пам'яті.
А це означає, що час обробки даних буде різним, залежно від ентропії, якщо, звичайно, розробник пристрою не нівелює цей ефект навмисно.
Тест NIOBench
У версії v0.42 бенчмарка NIOBench реалізовано сценарій заповнення тестових паттерів (копіюваних файлів) псевдопромінювальними даними. Типово, як заповнювач використовуються нулі.
Підтримується два види генераторів випадкових чисел:
- Програмний, методи класуutil.Random
- Апаратний, інструкція RDRAND, яка опціонально підтримується процесорами
Якщо інструкція RDRAND не підтримується або відсутня нативна бібліотека під цю ОС, параметр Hardware RNG не активується - бенчмарки можна виконати в режимі заповнення нулями або c програмною генерацією тестового патерну псевдопромінювальними числами. Опція Data, вибирає один з трьох методів тестування:
- Zeroes - заповнення тестових файлів нулями
- Software RNG (Random Number Generator) - заповнення тестових файлів псевдопромінювальними даними, отриманими програмно, методами класу java.util.Random
- Hardware RNG - заповнення тестових файлів псевдовипадковими даними, отриманими апаратно, за допомогою машинної інструкції RDRAND
Режими 1 і 2 підтримуються на всіх платформах. Режим 3 підтримується за умови підтримки процесором інструкції RDRAND та наявності нативної бібліотеки для даної ОС. У цій версії присутні нативні бібліотеки для Windows 32/64. Планується підтримка інструкції RDRAND і під Linux.
Нативні бібліотеки упаковані в складі виконуваного JAR-архіву. Підключення до java програми, процедур, написаних на асемблері, базується на специфікації JNI (Java Native Interface).
Про результати
Під час тестових операцій таблиця у верхній частині вікна утиліти NIOBench заповнюється отриманими результатами. По стовпчиках рознесена статистика бенчмарок: середня, мінімальна і максимальна швидкості. Прострочено виводяться медіани читання, записи та копіювання, а потім - середні значення, отримані в процесі виконання цих самих операцій.
Користувач може зберегти текстовий рапорт виконання бенчмарок. У ньому детально представлені результати по кожній з ітерацій, заданих у полі Count. Дані, що беруть участь в обчисленнях медіан, відзначені літерою «M».
Під час розробки сценарію тесту поставлено завдання виміряти виключно продуктивність накопичувача (або схем архівації даних, що працюють на рівнях, нижче файлових API, що можливо в деяких системах збереження даних) і її залежність від даних. При цьому необхідно виключити залежність результатів від продуктивності самого генератора випадкових чисел. Тому масиви тестових даних заповнюються один раз при старті програми, а не під час виконання вимірювальної операції. Залежно від стану опції Data, що вибирає метод тестування, використовується один з трьох заздалегідь підготовлених масивів (нулі, soft-RNG, hard-RNG). Тестові дані повторюються з періодом 1 мегабайт.
Технологія розробки та зневадження
Написання і налагодження java-програми виконані в середовищі NetBeans 8.1. Асемблерні бібліотеки написані в середовищі FASM Editor 2.0, відтрансльовані за допомогою Flat Assembler 1.71.49. Зневаджування 32-бітового асемблерного коду виконується в OllyDbg v2.01. Зневаджування 64-бітового асемблерного коду виконується в FDBG v0025.
