Контроллер intel что это
Безопасно внедряйте системы хранения нового поколения
Intel® VMD — это функция масштабируемых процессоров Intel® Xeon®, которая позволяет напрямую контролировать SSD-накопители NVMe и управлять ими с шины PCIe без дополнительных аппаратных адаптеров. Эта надежная функциональность SSD-накопителей NVMe обеспечивает плавный переход к хранилищам данных NVMe при одновременном ограничении времени простоя важнейших объектов инфраструктуры. Благодаря технологии Intel® VMD SSD-накопители с интерфейсом NVMe отличаются надежностью, доступностью и удобством обслуживания (RAS), поэтому вы сможете осуществлять безопасное развертывание систем хранения нового поколения.
Переход на NVMe с технологией Intel® VMD
Технология Intel® Volume Management Device (Intel® VMD) предназначена для управления корпоративного уровня SSD-накопителями NVMe, подключенными к ЦП Intel® Xeon®. Каждый корневой порт состоит из группы из 16 линий PCIe процессора Intel® Xeon®, образующих один домен Intel® VMD. Корневые порты действуют как интегрированный HBA, обеспечивая надежную основу для поддержки экосистемы NVMe с помощью нижеуказанных функций:
Ознакомьтесь с приведенной ниже информацией о технологиях Intel® Virtual RAID on CPU (Intel® VROC) и Direct Assign, касающейся реализаций технологии Intel® VMD и кратких описаний продукции.
На базе процессоров Intel® Xeon®
По мере увеличения вычислительной мощности чрезвычайно важным условием реализации истинного потенциала ЦП становится доступ с высокой пропускной способностью к системам хранения с низким уровнем задержек. Intel® VMD и Intel® VROC являются функциями масштабируемых процессоров Intel® Xeon®, которые позволяют плавно перейти на быстродействующие системы хранения NVMe для обеспечения максимального доступа ЦП к данным без нарушения функций хранения данных.
Поддерживаемые процессоры
Количество доменов VMD на конкретном ЦП зависит от количества линий PCIe. Для каждых 16 линий PCIe доступен один домен Intel VMD.
Примечание: некоторые платформы могут поддерживать дополнительный домен Intel VMD на наборе микросхем, который не включен в приведенный выше расчет. Этот домен используется главным образом для загрузки с целью сохранения линий PCIe ЦП для более производительных устройств.
Интегрированный RAID-контроллер: Intel® Virtual RAID on CPU
Intel® Virtual RAID on CPU (Intel® VROC) — решение RAID корпоративного класса, которое позволяет повысить производительность SSD-накопителей NVMe. Аппаратное обеспечение Intel® VMD позволяет Intel® VROC предоставлять загрузочный RAID без дискретного аппаратного RAID-контроллера HBA.
Драйверы Intel® VMD и Intel® VROC поставляются вместе в составе блока системы хранения корпоративного класса через поставщиков платформ. В Windows и Linux эти пакеты обеспечивают возможности управления светодиодами и горячего подключения для массивов RAID0, 1, 5 и 10 с прямым подключением. Если RAID не требуется, то можно использовать Intel® VROC в сквозном режиме для включения только доменов Intel® VMD.
В средах VMware технология Intel® VMD может использоваться как в режиме vSAN, так и в режиме с прямым подключением, при этом дополнительным преимуществом является возможность использования массива RAID1 для избыточного загрузочного тома.
NVMe для HCI: Intel® VMD Direct Assign
В связи с дальнейшим переходом модернизированных ЦОД на архитектуры гиперконвергентной инфраструктуры (HCI) требуются новые инструменты для поддержки платформ более высокой плотности и производительности. Технология Intel® VMD Direct Assign позволяет назначать домен Intel® VMD непосредственно ВМ, полностью обходя гипервизор, с тем чтобы сократить время задержек при хранении данных и увеличить пропускную способность. Гостевая ОС наследует основную функцию Intel® VMD, позволяющую использовать производительность хранилища данных NVMe при реализации HCI при сохранении необходимых функций хранения данных и виртуализации.
Связанная продукция и решения
Системы хранения данных Intel®
Узнайте, как Intel оптимизирует системы хранения в ЦОД и облачных средах с помощью масштабируемых и оптимизированных под системы хранения технологий, открывающих новые возможности.
Семейство твердотельных накопителей Intel® для центров обработки данных
Устраните ограничения производительности с помощью оптимальных накопителей для центров обработки данных. Модернизируйте свою инфраструктуру в соответствии с требованиями цифрового бизнеса. Твердотельные накопители Intel® для центров обработки данных оптимизированы для обеспечения высокой производительности, надежности и долговечности.
Контроллеры Intel® Ethernet Controller серии 800 (до 100 Гбит/с)
Контроллеры серии 800 включают в себя такие функции, как очереди устройств приложений (ADQ) и динамическая персонализация устройств (DDP), а также поддерживают удаленный прямой доступ к памяти (RDMA) по протоколам iWARP и RoCEv2. Они обеспечивают производительность, оптимизированную для рабочих нагрузок, и широкие возможности для соблюдения меняющихся сетевых требований. Контроллеры серии 800 поддерживают скорость до 100 Гбит/с для высокоэффективных серверных рабочих нагрузок, таких как виртуализация сетевых функций, хранение данных, высокопроизводительные вычисления и ИИ, а также гибридное облако.
Контроллеры Intel® Ethernet Controller серии 800 (до 100 Гбит/с)
Контроллер Intel® Ethernet E810
Контроллер Intel® Ethernet E810 Поддерживают скорость до 100 Гбит/с.
Перемещайте данные быстрее
Продукция Intel® Ethernet со скоростью от 1 до 100 Гбит/с позволяет быстрее перемещать данные с помощью инновационных технологий и архитектуры, масштабируемых с требованиями бизнеса.
Подробности см. на сайте intel.ru/ethernet.
Поддержка
Для работы технологий Intel может потребоваться специальное оборудование, ПО или активация услуг. // Ни один продукт или компонент не может обеспечить абсолютную защиту. // Ваши расходы и результаты могут отличаться. // Производительность зависит от вида использования, конфигурации и других факторов. // См. наши юридические уведомления и отказ от ответственности. // Корпорация Intel выступает за соблюдение прав человека и избегает причастности к их нарушению. См. Глобальные принципы защиты прав человека в корпорации Intel. Продукция и программное обеспечение Intel предназначены только для использования в приложениях, которые не приводят или не способствуют нарушению всемирно признанных прав человека.
Встроенный контроллер одного ноутбука и его наследство
В этом материале я хочу немного рассказать о том, что происходит во встроенном контроллере (Embedded Controller, EC) моего ноутбука. Речь идёт о мультиконтроллере IT8586E, основанном на Intel 8051. Он встроен в ноутбук Lenovo Ideapad 310-15IKB. Но, прежде чем переходить к деталям, полагаю, нелишним будет поговорить о том, что это вообще такое — встроенные контроллеры.
Краткая история встроенных контроллеров на платформах x86
Сначала был создан компьютер IBM PC. Многих это возмутило, данный шаг компании IBM был широко признан неразумным.
В материнскую плату этого компьютера было встроено множество периферийных устройств, вроде Intel 8259 (программируемый контроллер прерываний) или Intel 8253 (программируемый таймер). Обращаться к этим контроллерам можно было, пользуясь инструкциями in/out ядра x86 (и, на самом деле, к контроллерам 8259 и 8253 всё ещё можно обращаться на современных x86-процессоров, но теперь они входят в состав кристалла CPU). Один из контроллеров IBM PC, Intel 8255 (программируемый контроллер интерфейса периферийных устройств), отвечал за взаимодействие с клавиатурой.
Где-то в конце 1980-х периферийные устройства всё чаще и чаще объединяли, включая в состав одной микросхемы несколько таких устройств. Например — это чипы северного моста и южного моста. Один из таких чипов, Super I/O-контроллер, отвечал за взаимодействие с низкоскоростными устройствами, вроде последовательных портов, параллельных портов и контроллеров дисководов гибких дисков. В состав этого чипа часто входил и контроллер клавиатуры.
Ноутбукам, кроме прочего, требовалась особая система управления питанием. Производители портативных компьютеров взглянули на контроллер клавиатуры, на то, что он способен перезагружать компьютер, и сказали: «На самом деле — это замечательно. Давайте сделаем то, что нам нужно, по похожей схеме». В результате к контроллеру клавиатуры были добавлены два порта с похожим интерфейсом, позволяющим отправлять на устройства команды и получать от них данные. И, фактически, во многих платформах эта возможность реализована в том же самом контроллере, который входит в состав Super I/O-чипа.
В середине 1990-х заметным явлением стал стандарт ACPI (Advanced Configuration and Power Interface, усовершенствованный интерфейс управления конфигурацией и питанием). Он определял стандартизированный интерфейс для EC. А именно, через его командный интерфейс можно было обращаться к 8-битному адресному пространству переменных, определяемых производителями оборудования. Эти переменные можно было описывать с помощью языка AML (ACPI Machine Language), средствами AML можно было описывать и код, позволяющий воздействовать на эти переменные.
В конце 2000-х годов микросхемы южного и северного мостов были объединены с CPU. Правда, надо отметить, что интеграция южного моста (PCH, Platform Controller Hub) в CPU, по всей видимости, имеет место лишь на мобильных платформах. Но в ноутбуках EC всё ещё представлен отдельным чипом, который, кроме того, реализует функционал Super I/O-контроллера и контроллера клавиатуры. Он, например, решает следующие задачи:
Схема материнской платы моего ноутбука
Так как EC интенсивно взаимодействует с разными устройствами — неплохо было бы знать о том, что это за устройства. Мне в решении этой задачи повезло — кто-то выложил в интернет так называемые boardview-файлы к интересующей меня плате. В таких файлах содержатся схемы печатных плат, в частности, сведения о компонентах, расположенных на плате, и о том, как они связаны. Между компонентами материнских плат имеется так много соединений, что анализ схемы их связей может оказаться весьма сложной задачей. Я попытался представить связи между компонентами платы в упрощённой форме, результат моих трудов показан на следующей схеме (тут нет большинства линий, имеющих отношение к питанию).
Схема связей компонентов платы (оригинал)
CPU соединён с EC с использованием шины LPC (Low Pin Count), которая, по сути, представляет собой замену шины ISA, применявшейся в более старых компьютерах, в физической реализации которой используется меньше линий связи. Процессор и контроллер взаимодействуют, в основном, по LPC. Но между EC и CPU имеется множество соединений (показанных синими линиями без стрелок), используемых в особых целях. Например — это линия SCI, предназначенная для вызова прерывания от EC в CPU.
Прошивка EC
Раздобыть прошивку контроллера несложно. Я уже извлекал образ BIOS раньше, для других нужд. После его обработки с помощью утилиты cpu_rec в моём распоряжении оказалось примерно 160 Кб 8051-кода из самого начала образа, расположенного до кода, имеющего отношения к UEFI. Контроллер 8051 имеет 16-битное адресное пространство, а значит 160 Кб кода ему не соответствуют. Получается, что речь идёт о так называемой banked-прошивке. То есть — одни части («блоки» или «банки») прошивки в адресном пространстве подвергаются динамической замене на другие части путём воздействия на некие регистры.
Размеры блоков прошивки обычно, в большинстве контроллеров 8051, составляют либо 32, либо 64 Кб. Выяснить их размер при работе с конкретным контроллером можно, поискав повторяющиеся фрагменты кода. Дело в том, что в разных блоках прошивки обычно имеются одинаковые фрагменты, представляющие код общего назначения (быстро найти такие фрагменты можно попробовать, прибегнув к автокорреляции). Оказалось, что в моём случае речь идёт о блоках кода размером 32 Кб.
После того, как я всё это выяснил, меня посетила блестящая идея, которая заключалась в том, чтобы посмотреть даташит исследуемого компонента. Даташит на мой контроллер найти не удалось, но мне попались документы на IT8502E, описывающие устройство достаточно близкое к тому, которое было у меня. В нём, что было очень кстати, подробно описывалось большинство I/O-механизмов и, похоже, описание функционирования прошивки, в основном, соответствовало той прошивке, что была у меня.
При просмотре даташита я наткнулся на упоминание отладочного интерфейса I2C, но он, правда, не был документирован. После некоторых изысканий я нашёл проект ECSpy, который представляет собой Rust-реализацию отладчика для EC, созданную силами компании System76, которая работает над собственной прошивкой для EC.
Отладчик даёт доступ на чтение и запись к оперативной памяти и регистрам ввода/вывода EC. Доступ к регистрам отличается дополнительным ограничением, которое заключается в том, что операция записи чётко определена лишь для триггерных регистров (в результате, например, операция, вызывающая изменение состояния конечного автомата, не сработает).
Ещё в даташите сказано, что возможность отладки нужно включать с помощью регистра, но она и так включена. Доступ к ней осуществляется посредством I/O-портов x86 через Super I/O-чип, поэтому ей можно пользоваться из пользовательского пространства, без необходимости писать драйвер.
Для реверс-инжиниринга тех частей прошивки, которые отвечают за взаимодействие с различными устройствами, могут пригодиться спецификации этих устройств. Я, работая над этим проектом, прочитал часть спецификаций ACPI, SMBus и Smart Battery. В процессе исследования кода прошивки используются следующие ресурсы и инструменты: boardview-файлы, даташиты, спецификации компонентов, отладчик Ghidra, обычный браузер, применяемый для поиска дополнительных сведений вроде скан-кодов, исходный код Linux-драйвера для EC, дизассемблированный машинный ACPI-код, отладчик для EC и его исходный код. В таких делах весьма кстати могут оказаться несколько мониторов, использование которых позволяет ускорить сопоставление информации, полученной из разных источников.
Большой объём работы выполняется в коде главного цикла, ответственном за обработку событий таймера. Таймер в EC запрограммирован так, что он выдаёт прерывание раз в одну миллисекунду. Потом, на основе прерываний таймера, формируются события, которые происходят, например, каждые 10, 50, 100 мс. Обновление ACPI-переменных выполняется, в основном, в этом контексте.
POST-карты в современных ноутбуках
Затем, вместе с тактовыми импульсами, осуществляется последовательный вывод результирующего значения на GPIO-пины.
Вышеприведённая поисковая таблица может показаться вам знакомой. Дело в том, что она позволяет преобразовывать полубайты в шестнадцатеричные числа для их вывода на 7-сегментном дисплее. Если взглянуть на схему материнской платы, там можно увидеть две линии — EC_TX и EC_RX (эти названия, вероятно, не очень удачны, так как одна из них — это линия данных, а другая — тактовая линия, обе они используются лишь для отправки данных). Они ведут к Wi-Fi-чипу, который подключён к плате через разъём M.2. Но эти линии, на самом деле, ни к чему на Wi-Fi-карте не присоединены.
Это наводит на мысль о том, что существуют некие POST-платы, которые можно подключать к разъёму M.2 для решения проблем, возникающих в ходе загрузки ноутбуков. Так как я знаком с протоколом обмена данными, используемым в M.2-картах, я попытался сделать собственный вариант такой платы (она, в целом, представляет собой два последовательно соединённых сдвиговых регистра, подключённых к 7-сегментным дисплеям). Посмотрите — какая симпатичная у меня получилась штука.
Самодельная POST-плата для разъёма M.2
Но я, к сожалению, видимо что-то напутал, так как эта плата, в итоге, так и не заработала, а мне не очень-то хотелось тратить время на поиск и исправление ошибок, допущенных при её создании.
Клавиатурные механизмы
Можно подумать, что вышеописанная задача решается очень легко, что заключается она в просмотре некоей поисковой таблицы и в отправке хосту результатов. Но, увы, скан-коды PS/2 — это настоящий бардак.
Существует три различных набора скан-кодов, между которыми нет ничего общего. EC использует набор №2. Одиночное нажатие и отпускание клавиши не всегда приводит к генерированию одного байта скан-кода.
Если промежуточное значение меньше 0x80, это значит, что оно просто соответствует обычному однобайтовому PS/2 скан-коду. А если говорить о других значениях, то они, по уже рассмотренной нами схеме, используются в роли индексов в поисковой таблице. Результирующее значение определяет функцию, которая используется для обработки скан-кода. Полученные скан-коды затем помещают в 16-байтовый кольцевой буфер, байты, содержащиеся в котором, если это возможно, потом отправляют хосту.
Таинственный фрагмент кода
Зачем встроенному контроллеру SHA-1? Если посмотреть на то, что именно вызывает SHA1-код, то окажется, что он используется при взаимодействии с батареей по SMBus:
Где хранится код?
Во многих прошивках для 8051 обычно имеется код, реализующий возможности отладки, и мой — не исключение. Перед функциями, имеющими отношение к контроллеру клавиатуры и к EC, имеется множество функций, которые явно реализуют отладочные возможности. Одна из них — это команда контроллера клавиатуры, предназначенная для чтения из EC данных с адресов флеш-памяти с применением регистра.
Если сделать оттуда дамп прошивки, то получится образ, который отличается от оригинала. Изначально я предполагал, что EC использует образ из флеш-памяти BIOS, так как он хранится в этой памяти, и EC к этой памяти подключён. Но оказалось, что это, на самом деле, не так. К этой памяти напрямую подключены и CPU, и EC. В результате, в том случае, если и тот и другой одновременно попытаются прочесть из неё данные, на шине неизбежно возникнет конфликт. Прошивка, на самом деле, хранится в самом EC. В IT8502 этой возможности не было (это запутало меня ещё сильнее, так как я пользовался даташитом именно для такого контроллера).
Запуск моего собственного кода в EC
Вероятно, стоит сказать о том, что у 8051 имеется некоторое количество различных адресных пространств:
Я этого делать не собирался, так как подобные действия несут в себе риск «окирпичивания» устройства. EC можно перепрограммировать, используя входы/выходы клавиатурной матрицы в роли параллельного порта, но я не собирался заниматься и этим.
Ещё одна проблема, связанная с записью данных во флеш-память, заключается в том, что её содержимое проверяется с использованием контрольной суммы. В прошивке имеется сигнатура, которая указывает на то, где начинается контрольная сумма, и в ней имеются два байта, которые различаются в разных редакциях прошивки. Подобное характерно для контрольных сумм. Если дело обстоит именно так — то неясно, где именно начинается и заканчивается контрольная сумма, и то, как именно она вычисляется.
Правда, для выполнения собственного кода нет нужды выполнять запись данных во флеш-память. В EC для этого имеется другой механизм. А именно — адреса 0x0000-0x1000 в адресном пространстве XDATA — это обычная оперативная память, которую можно отобразить на произвольную область адресного пространства CODE, изменив содержимое кое-каких регистров.
Схема из даташита, на которой показано 5 областей, пронумерованных от 0 до 4, которые могут быть отображены на адресное пространство кода. А именно, речь идёт об областях 0x0000-0x0800, 0x0800-0x0c00, 0x0c00-0x0e00, 0x0e00-0x0f00 и 0x0f00-0x1000
В результате для выполнения собственного кода достаточно лишь выполнить отображение одного из этих фрагментов на память с кодом. Оперативная память в диапазоне 0x0000-0x0e00 используется самой прошивкой, в результате остаются блоки 3 и 4, размер каждого из которых составляет 256 байт.
Правда, чтобы осуществить отображение этой памяти на память с кодом, нужно выполнить запись в регистры и в оперативную память из пространства XDATA. Есть одна отладочная функция, позволяющая писать данные в XDATA, но она содержит ошибки и может писать данные только по адресам, где байт из верхней части адреса является таким же, как и байт из его нижней части. Тут имеется ещё и интерфейс I2C, который достаточно хорошо подходит для решения задачи записи данных в SRAM.
Я сомневался по поводу записи данных в порты ввода/вывода, так как было сказано, что это подходит лишь для триггерных регистров. Но в регистрах, используемых для отображения памяти, имеется ещё и бит для запуска DMA-транзакции (так как этот чип, конечно, поддерживает DMA). В любом случае, не было способа проверить то, что отображение памяти осуществляется именно так, как мне нужно, так как нет отладочной функции, позволяющей читать данные из адресного пространства CODE.
К счастью, был и другой путь: функционал отображения памяти используется для перезаписи флеш-памяти (так как никто не заинтересован в том, чтобы работа программы завершилась бы с ошибкой, когда будет достигнута область с кодом, выполняющим запись данных). Используя I2C можно отредактировать содержимое SRAM в адресном пространстве XDATA, поместив туда отладочный код, и подстроить механизм записи данных во флеш-память так, чтобы он обращался бы к этому отладочному коду.
В любом случае, эту проблему легко обойти, так как между адресами, всё равно, имеется взаимно однозначное соответствие, а значит — код можно просто записать в те места пространства XDATA, которые будут соответствовать нужным местам памяти. Оказалось, что I2C-запись в регистры, отвечающие за отображение памяти, тоже работает. В результате для выполнения отладочного кода с его последующей записью мне не нужно было бы прибегать к режиму перезаписи флеш-памяти.
Итоги
На сегодня это всё, а в следующий раз я расскажу об исследовании прошивки ноутбучного Wi-Fi-модуля (RTL8821AE) и о разработке небольшого кейлоггера, основанного исключительно на возможностях Intel 8051.
Занимались ли вы разработкой прошивок для контроллеров, основанных на Intel 8051?
Что такое Intel Optane? Часть 1. Optane Memory
Этим постом я хотел бы открыть небольшую серию статей, посвященных продуктам Intel Optane на базе технологии 3D XPoint. Мой беглый обзор русскоязычных источников показал, что хороших материалов по этому вопросу нет; кроме того, из комментариев к нашим анонсам я убедился, что существует глубокое непонимание того, зачем все это вообще нужно и почему реализовано именно таким образом.
Технология 3D XPoint
Начнем с краткой информации по самой технологии 3D XPoint (читается как «три-ди кросс-поинт»). Сразу прошу извинений — детальную информацию о технологии мы на данный момент не раскрываем. Кроме того, фокус обзоров будет именно на конечных продуктах, нежели чем на самой технологии.
Во-первых, хотя технология является совместной разработкой компаний Intel и Micron, реализация технологии в виде продуктов находится в раздельном ведении каждого из вендоров. Таким образом, всё, что я буду рассказывать о продуктах на базе 3D XPoint, имеет отношение только к продуктам Intel.
Во-вторых, 3D XPoint – это не NAND, это не NOR, это не DRAM, а совершенно другой зверь. Не раскрывая деталей физической реализации памяти, опишу ключевые характеристики, а также отличия 3D XPoint от NAND и от DRAM.
Intel Optane
На данный момент, официально анонсировано и выпущено на рынок 2 принципиально разных продукта: Intel Optane Memory – для клиентских моделей использования — и Intel® Optane SSD DC P4800X – для серверного использования. В данной статье мы подробнее разберем клиентский продукт, серверный же будет темой следующего обзора.
Итак, Intel Optane Memory. Первое, что стоит понять об этом продукте – несмотря на название, это не DRAM, а NVMe SSD в форм-факторе M.2 2280-S3-B-M.
Вид сверху – под наклейкой 1 чип 3D XPoint (это версия 16ГБ, на 32ГБ расположены 2 чипа 3D XPoint – площадки под второй чип видны):
Модуль односторонний, так что обратная сторона пустая:
Устройство соответствует спецификации NVM Express 1.1. На данный момент на рынок выпущены емкости 16ГБ (используется один чип памяти 3D XPoint емкостью 16ГБ) и 32ГБ (используются два чипа памяти 3D XPoint емкостью 16ГБ каждый). Из интересных деталей дизайна:
Тест производительности
Теперь о производительности
(производительность версии 32ГБ выше из-за того, что используются 2 чипа памяти 3D XPoint против одного чипа у версии 16ГБ)
Казалось бы, производительность в плане пропускной способности и IOPS не впечатляет – однако, собака зарыта совсем не тут. Вся штука в том, что эти данные производительности замерялись при глубине очереди (queue depth) равной 4 – в отличие от прочих SSD, которые обычно замеряются с глубиной очереди 32 и выше. Именно на неглубоких очередях более всего заметно превосходство Optane. Для наглядности, вот график производительности разных типов устройств на разной глубине очереди*:
При этом, как показывают наши внутренние тесты, подавляющее большинство задач, с которыми сталкивается обычный пользователь дома или в офисе, имеют глубину очереди от 1 до 4 (более подробно – см. ниже), а спецификации SSD пишутся с использованием нагрузок с глубиной очереди 32 (для SATA) и более (для NVMe). Разница весьма наглядна.
Однако, Intel не позиционирует использование Optane Memory в качестве обычного SSD по понятным причинам – емкости устройств не хватит для пользовательских задач (за исключением некоторых интересных вариантов, как, например, небольшой, но быстрый и надежный загрузочный накопитель для Linux, или scratch disk для Adobe Photoshop, или небольшой, но быстрый кэш вместе с Intel Cache Acceleration Software, или интересное решение, описанное вот тут). Вся сила маркетингового аппарата Intel направлена на продвижение новой технологии ускорения (грубо говоря – кэширования, но это не совсем точное определение) медленного SATA-накопителя (будь то жесткий диск, твердотельный накопитель или даже некоторые гибридные модели) быстрым модулем Optane Memory.
Эта модель использования накладывает ограничения на поддерживаемые железо и ОС:
И да, Intel провел громадную работу с производителями плат – все платы, которые поддерживают Optane Memory, имеют на коробке вот такой шильдик:
Принцип работы
Также немного поговорим о том, как это все работает.
Во-первых, в момент активации Optane Memory, RST драйвер перенесет файлы, необходимые для загрузки ОС, а также файловую таблицу на быстрый Optane Memory накопитель. Ключевое здесь – именно перенесет, а не скопирует. Механика работы RST драйвера такова, что не все данные, лежащие в кэше на быстром устройстве, будут в обязательном порядке скопированы на медленное устройство. Это увеличивает общее быстродействие системы и, кроме того, решает проблему синхронизации данных. Однако, как можно понять, физический сбой Optane Memory с большой вероятностью приведет к потере доступа к данным на SATA-диске. Из-за того, что перенос данных происходит сразу в момент активации Optane Memory, уже первая же загрузка системы будет быстрее, чем до Optane Memory (особенно это заметно, если ускорялся жесткий диск, нежели чем SATA SSD – однако, и в последнем случае стоит ожидать увеличения производительности системы хранения).
Во-вторых, во время работы системы RST драйвер будет непрерывно производить кэширование. И здесь существует одно важное различие между модулями Optane Memory разной емкости – на устройстве емкостью 16ГБ поддерживается только кэширование на уровне блоков, на устройстве емкостью 32ГБ – кэширование на уровне блоков и кжширование на уровне файлов (оба работают одновременно). В случае блочного кэширования, решение о кэшировании того или иного блока происходит мгновенно в момент запроса на ввод-вывод. В случае файлового кэширования, драйвер мониторит частоту доступа к файлам и кладет все это в специальную таблицу, которую затем (в момент простоя системы или по расписанию пользователя) использует для определения того, какие файлы остаются в кэше, какие удаляются, а какие добавляются.
Оба вида кэширования используют довольно умные, на мой взгляд, алгоритмы принятия решения о кэшировании – глубоко описывать я их здесь не могу, но для общего понимания отмечу, что, например, не кэшируются видеофайлы (да, драйвер смотрит на расширение файла), в расчет принимается размер файла, определяется вид нагрузки – предпочтение в кэшировании отдается случайному доступу нежели чем последовательному, что имеет смысл в силу крайне медленной работы жестких дисков на операциях случайного доступа, и т.п. В интернетах я встречал некоторые негативные комментарии на тему того, что «кэш моментально забьется данными», «емкости 16ГБ ни на что не хватит» и тому подобное – как правило, это отзывы от людей, которые никогда не тестировали Optane Memory. Я еще не слышал негативных отзывов о производительности такого решения ни от кого из наших партнеров, с которыми работаю.
Несколько очень важных моментов.
Зачем это нужно
Теперь пришло время подробнее поговорить про то, зачем все это вообще нужно. Начнем с более детального анализа нагрузок, которые испытывают системы обычных пользователей ПК. Еще до окончания разработки продукта Optane Memory, в рамках Intel Product Improvement Program мои коллеги провели исследование на предмет того, что обычные пользователи делают с компьютером дома и на работе. Результаты – количество действий разных типов, производимых пользователями (усредненные данные на 1 день пользования ПК):
Все эти события тесно связаны с производительностью системного диска, причем, как правило, они требуют случайного доступа к данным, с чем жесткие диски справляются крайне плохо. Таким образом, использование Optane Memory может значительно ускорить исполнение каждого из указанных выше действий.
Однако, спросите вы зачем мне покупать Optane Memory для ускорения жесткого диска, если я могу за те же деньги купить SATA SSD емкостью 128ГБ, положить на него ОС и ключевые приложения, а для прочих данных просто использовать жесткий диск? Здесь, с одной стороны, вопрос удобства – если вы имеете хоть какие-то базовые навыки, чтобы уметь выбирать, куда установить ОС/приложения (подозреваю, что все читатели GT попадают в эту категорию, однако, могу вас уверить, что, например, мои родители, как и большинство пользователей ПК, на это не способны), и при этом не будете лениться делать это каждого приложения (особенно проблематично для игр – при нынешних требованиях к дисковому пространству, 128ГБ забьются под ОС и 1-2 игры), то с этой точки зрения гибридная конфигурация SSD+HDD может быть для вас удобнее.
Однако, имейте в виду, что с Optane Memory никакого ручного переноса данных не требуется – как только вы перестаете пользоваться одним приложением и начинаете активнее пользоваться другим, необходимые данные буду довольно быстро добавлены в кэш. С другой стороны, вспомним график, который я привел выше – производительность в зависимости от глубины очереди. На небольших очередях задержки доступа к данным на Optane Memory гораздо ниже по сравнению с SATA SSD. Внутри Intel мы замерили, какая глубина очереди используется различными приложениями – вот результаты:
Глубина очереди при использовании приложений:
Глубина очереди при запуске приложений:
Распределение глубины очереди в течение типичного рабочего дня корпоративного пользователя (замерено на сотрудниках Intel, занимающих разные должности в компании):
Таким образом, распределение глубины очереди разных пользовательских нагрузок:
И мы уже видели, насколько лучше Optane Memory справляется в работой на неглубоких очередях.
Сравнение производительности системы с HDD против такой же системы с HDD + Optane Memory:
Еще одно интересное сравнение – тот же тест, но в системе без Optane Memory в 2 раза больше оперативной памяти:
И, на самом деле, это весьма валидное сравнение. Хотя некоторые виды нагрузок требуют большого количества оперативной памяти, львиная их доля требований к большим объемам памяти не имеет. Таким образом, для многих пользователей может иметь смысл поставить 4 ГБ памяти вместо 8 ГБ, а сэкономленные деньги вложить в ускорение системы хранения.
Заключение
Подводя итог, напомню, что Optane Memory может использоваться как самостоятельный SSD, но это не основная модель использования. Вся магия происходит при его использовании как ускорителя для медленного жесткого диска (или даже SATA SSD) – сравнительно небольшое вложение денег может ускорить быстродействие системы в несколько раз на большинстве пользовательских нагрузок. Это достигается за счет как аппаратной части (Optane Memory имеет ощутимо меньшие задержки доступа по сравнению с другими SSD на рынке, быстродействие на небольших очередях значительно выше альтернативных решений), так и программной – драйвер RST использует достаточно продвинутую логику для осуществления операций кэширования (и в этом отличие от предыдущей технологии – Intel Smart Response Technology). Это делает текущую реализацию отличной от всех тех решений по кэшированию/ускорению жестких дисков, что выспукались на рынок ранее, в том числе нами же.
Я очень заинтересован узнать мнение о продукте и решении в целом из комментариев – однако, хотелось бы избежать негатива во мнениях из-за непонимания работы решения или отсутствия опыта его использования. Если есть сомнения – лучше спросите, прежде чем пускаться в критику.
P.S. в следующей статье мы разберем серверный продукт на базе технологии 3D XPoint — Intel Optane SSD DC P4800X Series – вкупе с программным решением Intel Memory Drive Technology.
* Все тесты, указанные в этой статье, были проведены внутри Intel. Все тесты с Optane Memory были проведены на процессорах Intel Core 7-го поколения, тесты на глубину очереди с использованием процессора Intel Core 6-го поколения. Конфигурация системы, использованной для тестов: