Блогер протестировал самый быстрый SSD-накопитель Liqid Honey Badger с пропускной способностью до 27 ГБ/с Материал редакции

«Медоед» втрое быстрее теоретической максимальной скорости SSD PlayStation 5.

В закладки
Слушать

Техноблогер Лайнус Себастиан протестировал Liqid LQD4500 Honey Badger (англ. «медоед») — серверный накопитель, который состоит из восьми NVMe SSD, объединённых в RAID 0. При идеальном стечении обстоятельств накопитель достигает скорости чтения более 27 ГБ/с — в современном мире в подобных скоростях нуждаются разве что суперкомпьютеры для машинного обучения и сервера, обеспечивающие доступ к огромным базам данных.

Устройство подключается в PCIe-слот для видеокарты и задействует все 16 доступных линий PCIe 4.0 — вчетверо больше, чем получает диск, подключённый в любой другой слот на материнской плате. Соответственно, Honey Badger можно использовать только с компьютерами и серверами на AMD Ryzen 3000, Threadripper или EPYC — процессоры Intel пока не поддерживают этот стандарт.

Использованные накопители имеют интерфейс PCIe 3.0 и индивидуальную пропускную способность чуть ниже 3,5 ГБ/с. В RAID 0 объём и скорость всех накопителей суммируется, что позволяет достичь максимальной пропускной способности свыше 27 ГБ/с — это значение практически упирается в порог возможностей PCIe 4.0 x16.

В Windows 10 максимальная скорость в тесте составила 15,38 ГБ/с на чтение и более 20 ГБ/с на запись. Для сравнения, один флагманский NVMe 4.0 SSD может достигать порядка 5 ГБ/с. Заявленная пропускная способность системы хранения PlayStation 5, по официальным данным, развивает скорость до 9 ГБ/с при помощи специального алгоритма сжатия и отдельного чипа, который отвечает за декомпрессию данных.

Ни одна программа или игра для персонального компьютера не нуждается в подобных скоростях. Чтобы хоть как-то нагрузить «медоеда», блогер открыл 16 видеофайлов в 4К в Adobe Premiere — воспроизведение, перемотка, запуск и остановка происходили мгновенно.

Максимальную скорость 27,8 ГБ/с при чтении удалось развить под Linux — эта система намного меньше ограничивает возможности оборудования.

Liqid LQD4500 Honey Badger недоступен для обычных покупателей — корпоративные клиенты могут обратиться к производителю напрямую, чтобы получить индивидуальное предложение.

Сначала эта технология будет инструментом для профессионалов и учёных, но я жду не дождусь, когда она доберётся до персональных компьютеров. А потом, лет через десять, может быть появится и в игровых консолях.

Лайнус Себастиан

Подробнее о характеристиках SSD и советы по выбору читайте в гайде DTF.

Редактор подсайта «Железо», иногда пишу про аниме и бесконечно обновляю домашний ПК, хотя играю в основном на Switch
{ "author_name": "Никита Богуславский", "author_type": "editor", "tags": ["\u043d\u043e\u0432\u043e\u0441\u0442\u0438","ssd"], "comments": 396, "likes": 113, "favorites": 36, "is_advertisement": false, "subsite_label": "hard", "id": 142314, "is_wide": false, "is_ugc": false, "date": "Tue, 02 Jun 2020 14:47:48 +0300", "is_special": false }
Объявление на DTF
0
396 комментариев
Популярные
По порядку
Написать комментарий...

Убежденный Илья

17

Скорости скоростями, но уже сто раз говорили что в играх разница между ссд сата накопителем и pcie-nvme накопителем в циферках хоть и огромная, но на практике в задачах она укладывается в единичные проценты и прочувствовать ее невозможно.
Весь этот бздежь про соневские быстрые ссд просто маркетинг или полное непонимание что 99.9% разработчиков делают игры под мультиплатформу и если этот сони-ссд раскроет свой невероятный потанцивал, то только в ее личных играх которых выходит 1-2 в год. 

Разумеется быстрые ссд нужны, но только на пк и только для узких профессиональных задач.

Ответить
0

Не совсем так, упрощается менеджмент с оперативной памятью, появятся новые инструменты динамической подгрузки типо таких как в опенворлдах.
Точнее нам уже показали такие инструменты, нанит один из них.
Что это всё значит ? Корректная физика, повышенная детализация, текстурки.
Для примеров это позволит создавать крос жанровые игры без ограничений на размер движка, т.е. шутан действительно будет игратся как полноценный шутан со своей механикой и физикой, а рядом будет лететь человек на космическом корабле в котором идет бой и в который ты можешь запрыгнуть для боя сразу, сам корабль управляется другим икроком в ртс режиме и он тоже тут же может начать играть в шутан и т.д. и повреждения тут же отразятся на левеле, а под низом полноценный город с полноценными квартирами и корректной физикой. Причем и еще с полноценной разрушаемостью, каждый дом каждый корабль можно уничтожить, можно изменить ландшафт и т.д.
Надо понимать конечно что это нунжы новые инструменты, хорошо UE позаботился и создал подобные инструменты заранее, другие думаю вряд-ли и в любом случае до первых плодов настоящего использования это полноценные обновления движков т.е. 3-5 лет.

Ответить
9

это прекрасные фантазии, но от того что ты в память запихнёшь не 16Гб а 16Гб+своп на SSD у тебя производительность просто упрётся в цпу/гпу. Объём памяти никак не влияет на количество треугольников, которые может отрисовать видеочип. По итогу это просто костыль чтоб не пихать больше дорогой оперативную памяти в консоль, ведь в 2020 любая нормальная сборка ПК уже будет иметь 16+8Гб.

Ответить
–2

Что касается консоли конечно может оно и так, насчет производительности то пока нормально утилизировать не могут и 4 ядра, если только за уши не пытаются притянуть конечно.
И нет память памятью, но скорость очень круто роляет, сейчас просто происходит менеджмент памяти так что-бы как можно реже к ней обращатся, с SSD же менеджмент больше похож на беговую дорожку где можно пилить туда сюда навесив этот процесс на дополнительные ядра. За этим будущее т.к. это нехило сократит работы разработчиком в плане оптимизации.

Ответить
4

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

Поиграй на 4 ядрах без HT в Watch Dogs 2 или в Battlefield 5, сразу разницу заметишь. Игры последних лет хорошо распределяют до 12 потоков, не зря в PS5 и SeX новые процессоры именно такие

Ответить
–2

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

-Поиграй на 4 ядрах без HT в Watch Dogs 2 или в Battlefield 5
Это как раз пример притянутых за уши, то что там распаралели вопросов больше чем ответов, просто там не заботятся сбережением дополнительных ядер.
Выберите любой старый космосим где миллионы систем и везде идет деятельность, и да такая игра сожрет любое количество ядер и современных систем а работают старые космосимы на железе 25 летней давности.

Ответить
3

 Это как раз пример притянутых за уши

Тогда бы я привёл максимально процессорозависимые RTS типа ashes of the singularity, которые и больше потоков переварят. Не стоит путать причину и следствие. Таких игр мало не потому что распараллеливать игры не умеют, а потому что их отпимизируют в первую очередь под слабый каррентген.
Выберите любой старый космосим где миллионы систем и везде идет деятельность

это классические игровые уловки и хитрости, когда реально своей жизнью живёт только макромир, а микромир проявляется только в присутствии игрока. Могу привести так же кучу стратегий где для массовости копипастят по тысяче одинаковых юнитов. 
 но вышло нанит и есил он действительно функционирует заявленному, то уже это не так.

А ещё есть Mesh sahding от Nvidia, да. Но эти технологии никакого отношения к SSD не имеют, условно с ними та же система сможет отображать более высокополигональные модели без потери производительности. Повторюсь, несмотря на кучу рекламных заявлений, на деле быстрый SSD позволит убрать подгрузки и/или улучшить качество текстур. Остальные технологии не зависят от скорости загрузки данных с диска в видеопамять

Ответить
0

-RTS типа ashes of the singularity
Странно что вы не привели в пример there are billions там тоже требования огого.
Неудачные решения в оптимизации сетки путей не являются эффективным способом утилизации ядер.
-это классические игровые уловки и хитрости, когда реально своей жизнью живёт только макромир
Я вас наверно удивлю но всё развитие графики и игровых движков идет только когда находят надежный и эффективный способ создать иллюзию чего либо. На этом буквально построено всё.
-А ещё есть Mesh sahding от Nvidia, да. Но эти технологии никакого отношения к SSD не имеют
Во первых Mesh shading несет функцию только оптимизации.
Во вторых это же NVIDIA она дохрена чего показывает толку с этого непонятно, их лабораторные решения остаются их они не разрабатывают игры, у них только лаборатория.
А нанит как раз способен по заявлениям подгружать меши в фул деталиед с корректной геометрией(не копией меша  из памяти !) и упрощать для гпу геометрию ровно на столько, сколько пикселей на экране !  И самое главное эпики по их заверениям смогли добится корректного меша для отображения, так как будто это исходный меш ! Если последнее действительно. То это будет маст хэв технология для всего графена в ближайшее время, т.к. дейсвтительно способно без кординального увеличения мощности ГПУ, показывать на экране практически неограниченное количество полигонов(условных).

Ответить
0

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

Я с этим и не спорю, но при чём тут SSD? Если всё работает как заявлено то технология и на PS4 заработает
Неудачные решения в оптимизации сетки путей не являются эффективным способом утилизации ядер.

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

Да, но есть объективные бутылочные горлышки индустрии, а есть смешные попытки продавить SSD как киллер-фичу

Ответить
0

-Я с этим и не спорю, но при чём тут SSD?
Вы думаете десять тысяч загрузок мешей в секунде не требует гигабайтов хоть и сжатых ?
-это не отменяет того что в данной игре корректная работа с большим количеством юнитов без условностей вроде копипастных отрядов
Есть еще игра казаки, 15 лет назад там корректно обрабатывалось миллион юнитов с 8 игроками.
-Да, но есть объективные бутылочные горлышки индустрии, а есть смешные попытки продавить SSD как киллер-фичу
Гражданина снизу скопирую обзац, потому как он тут тоже актуален:
почему до сих пор организация памяти исходит из самодостаточности игры в памяти.
Это только потому как есть вероятность что информация на HDD будет фрагментирована и запрос ее займет милисекунд 300 а это значит что игра в это время будет в ожидании, а это значит что игрок просто слаттернет до 1фпс.

Ответить
2

Вы думаете десять тысяч загрузок мешей в секунде не требует гигабайтов хоть и сжатых ?

на фоне объёма текстур это копейки будут, и как тут подгрузки с SSD со скоростью в десятки раз ниже скорости видеопамяти помогут - непонятно. И уж тем более вопрос, почему просто не увеличить объём памяти до 32Гб?
там корректно обрабатывалось миллион юнитов с 8 игроками

там как раз копипаста и применяется
Это только потому как есть вероятность что информация на HDD будет фрагментирована и запрос ее займет милисекунд 300

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

Ответить
0

-на фоне объёма текстур это копейки будут, и как тут подгрузки с SSD со скоростью в десятки раз ниже скорости
А миллионы ? И это вопрос только к одному инструменту, их можно придумать кроме текстур десяток,  свет, ии, разрушения и т.д. и все это будет требовать запрос.
-И уж тем более вопрос, почему просто не увеличить объём памяти до 32Гб?
Потому как это не избавит от требования подгрузки текстур с SSD  хоть HDD, но вот при этом еще и потребует старый подход к организации памяти по выше приведенным причинам. По сути как раз ничего не поменяет для пользователя, но подкинет миллион проблем для разработчика. Вы покуда не обьяснили зачем нужны эти 32 гб в первую очередь разработчику который должен по старым лекалам выбирать что там хранить а что нет, потому как именно весь этот геморрой ложится на их руки.
-А на SSD 30мс, а потом ещё время на обработку. И мы ловим тот же статор.
Нет не ловим хоть и по другим причинам.
У вас всё смешалось и люди кони, провал фпс может быть только когда критическая нить (на данный момент) не может получить информацию  т.к. устройство занято считыванием блока с временем 300мс.
А сейчас с распараллеливанием это уже крайне маловероятно т.к. потоки избалвяют от ситуации когда они попадают в такую ситуацию, т.к. раньше вообще был один поток который обрабатывал.
Это был обьяснение почему используют ахритектуру менеджирования памяти дожившую до сегодняшних дней.

Ответить
0

  Вы покуда не обьяснили зачем нужны эти 32 гб в первую очередь разработчику который должен по старым лекалам выбирать что там хранить а что нет

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

Ответить
0

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

Ответить
0

Учитывая еще и сжатие. 

А разжимать он мгновенно чтоль будет?
Но ведь именно для этого и нужен быстрый ПЗУ оперативно подгружать на лету информацию

Поэтому я и конкретизировал что речь о сиюсекундных данных. Всё что не влезло в ОЗУ будут подгружать даже с очень быстрого SSD через "бутылочные горлышки" как в TLOU с заваливанием проходов или в демке UE5 с проходами через щели всякие

Ответить
0

-А разжимать он мгновенно чтоль будет?
Да может вы не в курсе но в составе ГПУ 20 лет используется аппаратное сжатие и его скорость хватает это делать на лету.

-Всё что не влезло в ОЗУ будут подгружать

В этом ничего страшного нет если это реализованое на параллельных нитях с быстрым SSD он же не запрашивает одни те же данные раз за разом как это делаются с данными в ОЗУ для процессора.
ПЗУ и ОЗУ это разные вселенные по менеджменту, тот факт что запросы в ПЗУ реже по определнию чем к ОЗУ раз в 1000, говорить о равных скоростях зачем ?

Ответить
0

Да и кстати насчет казаков
-там как раз копипаста и применяется
Там не используется копипаста, там хорошая оптимизация.

Ответить

Комментарии

{ "jsPath": "/static/build/dtf.ru/specials/DeliveryCheats/js/all.min.js?v=05.02.2020", "cssPath": "/static/build/dtf.ru/specials/DeliveryCheats/styles/all.min.css?v=05.02.2020", "fontsPath": "https://fonts.googleapis.com/css?family=Roboto+Mono:400,700,700i&subset=cyrillic" }