Я изучаю, смогу ли я реализовать приложение HPC на Windows, котороеполучает небольшие многоадресные датаграммы UDP (в основном 100-400 байт) с высокой скоростью, используя от дюжины до 200 многоадресных групп(т. е. с помощью MSI-X и RSS я могу масштабироваться на несколько ядер), выполняет некоторую обработку каждого пакета, а затем отправляет его. Отправляя через TCP, мне удалось подняться настолько, насколько мне было нужно (6,4 Гбит/с), не упершись в стену, но получение датаграмм на высоких скоростях pps оказалось проблемой.
Внедавний тестна высокопроизводительной машине NUMA с 2-портовой сетевой картой Ethernet 10 Гбит/с на Windows 2012 R2 мне удалось толькополучать сотни тысяч UDP-дейтаграмм в секунду(раннее отключение, т.е. без фактической обработки данных, чтобы исключить из уравнения накладные расходы на обработку моего приложения и посмотреть, насколько быстро оно работает) с использованием 2x12 ядер, а часть ядра 12 протестированных групп многоадресной рассылки, по-видимому, распределялась по 8 или 10 ядрам одного узла NUMA (Макс. количество очередей RSSбыло установлено значение 16) — хотя и с приложением .net, поэтому собственные приложения должны работать быстрее.
Но дажеЛен Холгейт удалось получить только UDP-пакеты со скоростью 500kppsвего высокопроизводительные тесты Windows RIO, используя полезную нагрузку UDP размером 1024 байта.
ВБелая книга QLogic(тестируемая ОС не упоминается) ограничения для «многопоточной маршрутизации сверхмалых пакетов» (то есть, включающей как прием, так и последующую отправку?) установлены на уровне5.7Mpps. ВстатьинаLinux-сети, пределы установлены на уровне1Mpps до 2Mppsна ядро (по сообщениям, масштабируется более или менее линейно), или даже15Mppsсо специальными решениями, обходящим ядро.
Напримерсетевая карта
может генерировать трафик на скорости линии (14.88Mpps) на канале 10GigE с одним ядром, работающим на частоте 900 МГц. Это соответствует примерно 60-65 тактовым циклам на пакет и хорошо масштабируется с ядрами и тактовой частотой (при 4 ядрах скорость линии достигается при частоте менее 450 МГц).Аналогичные показатели достигаются на принимающей стороне..
Итак, насколько далеко я могу зайти с (последними версиями) Windows / Windows Server, в частности, при приеме многоадресной рассылки UDP, как описано в первом абзаце?
РедактироватьО том, как это сделать в Linux, есть запись в блоге Cloudflare и интересный раздел комментариев:Как получить миллион пакетов в секунду, и есть соответствующийстраница комментариев новостей хакеров.
решение1
По данным Microsoft, тесты в их лабораториипоказалчто «на определенном сервере в раннем тестировании»РИО, они смогли справиться
- 2Mpps без потерьв Windows Server 2008R2, т.е. без RIO
- 4 млн пакетов в секунду на (предварительном) Windows Server 8 с использованием RIO
Скриншот из этого видео (44:33):
Итак, ответ на мой вопросIs it possible to process millions of datagrams per second with Windows?было бы:Да, и, судя по всему, это было еще до RIO, в Windows Server 2008R2.
Но в дополнение к официальным данным, особенно по невыпущенному программному обеспечению, которые следует воспринимать с долей скепсиса, поскольку в этой презентации представлена лишь скудная информация, остается много вопросов о тесте, а следовательно, и о том, как правильно интерпретировать результаты. Наиболее важными из них являются:
- Цифры относятся к отправке?Или, может быть, для маршрутизации (т.е. получения + отправки)?
- Какой размер пакета?-> Вероятно, это самый низкий возможный показатель, как это обычно и делается, когда пытаешься похвастаться цифрами pps
- Сколько соединений (если TCP) / потоков пакетов (если UDP)? -> Вероятно, столько, сколько необходимо для распределения рабочей нагрузки, чтобы можно было использовать все имеющиеся ядра
- Какая тестовая установка?Технические характеристики машины и сетевой карты, а также проводка
Первый из них имеет решающее значение, поскольку Sends и Receives требуют разных шагов и могут показывать существенные различия в производительности. Что касается других цифр, мы, вероятно, можем предположить, что наименьший размер пакета, с по крайней мере одним потоком соединений/пакетов на ядро, использовался на высокопроизводительной машине для получения максимально возможных показателей Mpps.
РедактироватьЯ только что наткнулся на документ Intel оВысокопроизводительная обработка пакетовна Linux, и в соответствии с этим (Linux)
Платформа может поддерживать скорость транзакций около 2 млн транзакций в секунду
с использованием стандартного сетевого стека Linux (на физическом хосте с 2x8 ядрами). Транзакция в этом тесте запроса/ответа включает в себя как
- прием UDP-пакета
- последующая пересылка этого пакета
(используя netserver от netperf). Тест выполнял 100 транзакций параллельно. В статье есть много других подробностей, для тех, кому интересно. Хотелось бы, чтобы у нас было что-то подобное для Windows, чтобы сравнить... В любом случае, вот наиболее релевантная диаграмма для этого теста запроса/ответа:
решение2
вкратце
Чтобы дать определенный ответ, по-видимому, необходимо больше тестов. Но косвенные доказательства говорят о том, что Linux — это ОС, используемая практически исключительно в сообществе с ультранизкой задержкой, которое также регулярно обрабатывает рабочие нагрузки Mpps. Это не значит, что это невозможно с Windows, но Windows, вероятно, будет сильно отставать, хотя и может быть возможно достичь показателей Mpps. Но это требует тестирования, чтобы убедиться, и, например, выяснить, при каких затратах (ЦП) эти показатели могут быть достигнуты.
NB Это не ответ, который я намерен принять. Он призван дать любому, кто заинтересован в ответе на вопрос, некоторые подсказки о том, где мы находимся и где исследовать дальше.
Лен Холгейт, который, по данным Google, единственный, кто протестировал RIO для повышения производительности сетей Windows (и опубликовал результаты), только что пояснил вкомментарий в его блогечто он использовал одну комбинацию IP/порта для отправки UDP-пакетов.
Другими словами, егорезультаты должны быть в некоторой степени сопоставимы с показателями одного ядра в тестах на Linux(хотя он использует 8 потоков, что, если не проверять его код, кажется вредным для производительности при обработке только одного потока пакетов UDP и отсутствии какой-либо интенсивной обработки пакетов, и он упоминает, что фактически используется только несколько потоков, что имело бы смысл). И это несмотря на то, что он говорит:
Я не особо старался добиться максимальной производительности, а просто сравнивал относительную производительность старых и новых API, поэтому не был столь тщательным в своем тестировании.
Но что такоеотказ от (относительной) зоны комфорта стандартного IOCP в пользу более сурового мира RIOкроме как "стараться изо всех сил"? По крайней мере, что касается одного потока пакетов UDP.
Я думаю, что он имеет в виду - поскольку он пробовал различные подходы к проектированию в нескольких тестах RIO - то, что он, например, не настраивал параметры сетевой карты, чтобы выжать последний кусочек производительности. Что, например, в случаеРазмер буфера приемаможет потенциально оказать огромное положительное влияние на производительность приема UDP и показатели потери пакетов.
Однако проблема при попытке напрямую сравнить его результаты с результатами других тестов Linux/Unix/BSD заключается в следующем: большинство тестов, пытаясь расширить границу "пакетов в секунду", используют наименьший возможный размер пакета/фрейма, т. е. фрейм Ethernet в 64 байта. Лен тестировал пакеты размером 1024 байта (-> фрейм размером 1070 байт), которые (особенно для No-Nagle UDP) могут дать вам гораздо более высокие показатели "бит в секунду", но могут не расширить границу pps так далеко, как это было бы возможно с меньшими пакетами. Поэтому было бы несправедливо сравнивать эти цифры как есть.
Подводя итоги моих поисков производительности приема UDP-сообщений в Windows на данный момент:
- На самом деле никто не использует Windows, когда пытается разработать приложения с ультранизкой задержкой и/или высокой пропускной способностью. В наши дни все используют Linux.
- Практически все тесты производительности и отчеты с реальными результатами (т. е. не просто реклама продукта) в наши дни проводятся на Linux или BSD (спасибо Лену за то, что он был первопроходцем и дал нам хотя бы одну точку отсчета!)
- UDP (стандартные сокеты) в Windows быстрее/медленнее, чем в Linux? Пока не могу сказать, придется провести собственное тестирование
- Является ли высокопроизводительный UDP (RIO против netmap) в Windows более быстрым/медленным, чем в Linux? Linuxлегкообрабатывает полную скорость линии 10 Гбит с одним ядром на частоте 900 МГц, Windows, влучший случай опубликованможет достигать 43% или 492kpps для большого размера пакета UDP 1024, т.е. показатели bps для меньших размеров, вероятно, будут значительно хуже, хотя показатели pps, вероятно, возрастут (если только ограничивающим фактором не является обработка прерываний или какие-либо другие накладные расходы на пространство ядра).
Что касается того, почему они используют Linux, то это, должно быть, потому, что разработка решений, включающих изменения ядра, такие как netmap или RIO, необходимые при достижении пределов производительности, практически невозможна в закрытой системе, такой как Windows, если только ваши зарплаты не приходят из Редмонда или у вас нет особого контракта с Microsoft. Вот почему RIO — это продукт MS.
Наконец, приведу несколько экстремальных примеров того, что, как я обнаружил, происходило и происходит в мире Linux:
Уже 15 лет назад некоторые получали 680 тыс. пакетов в секунду, используяПроцессор Pentium III 800 МГц, системная шина 133 МГцна сетевом адаптере 1GbE. Редактировать: Они использовалиНажмите, маршрутизатор режима ядра, который обходит большую часть стандартного сетевого стека, т.е. они «схитрили».
В 2013 году Аргон Дизайнудалосьполучить
отметьте задержки в торговле всего в 35 нс [наносекунд]
Кстати, они также утверждают, что
и Аргон используютПереключатель Arista 7124FX, который (в дополнение к ПЛИС) имеет ОС
построен на основе стандартного ядра Linux.
решение3
Вам наверняка понадобится "измерение" различных конфигураций и сценариев. Насколько мне известно, это можно сделать с помощью двух снаряжений, предоставленных двумя компаниями.IXIAиСпирент. Они предлагают аппаратные генераторы трафика, способные качать трафик на скорости линии. Они предлагают тест на рампу, где вы можете определить скорость, при которой ваша конкретная система может выйти из строя. Устройства дорогие, но вы можете арендовать их.