Можно ли обрабатывать миллионы дейтаграмм в секунду в Windows?


11

Я исследую, могу ли я реализовать приложение HPC в Windows, которое получает небольшие многоадресные дейтаграммы UDP (в основном, 100-400 байт) с высокой скоростью, используя дюжину или до 200 групп многоадресной рассылки (т.е. используя MSI-X и RSS, я могу масштабируется до нескольких ядер), выполняет некоторую обработку для каждого пакета и затем отправляет его. При отправке через TCP мне удалось подняться до необходимого уровня (6,4 Гбит / с), не ударившись о стену, но получение дейтаграмм с высокой скоростью передачи в секунду оказалось проблемой.

В недавнем тесте на высокопроизводительной машине NUMA с сетевым адаптером Ethernet с 2 портами 10 Гбит / с в Windows 2012 R2 мне удалось получить только сотни тысяч дейтаграмм UDP в секунду (раннее удаление, то есть без фактической обработки данных, до удалите издержки обработки моего приложения из уравнения, чтобы увидеть, как быстро оно работает) с использованием ядер 2x12, и часть ядра из 12 протестированных групп многоадресной рассылки, казалось, распределялась по 8 или 10 ядрам одного узла NUMA ( было установлено максимальное количество очередей RSS) до 16) - хотя и с приложением .net, поэтому нативные приложения должны работать быстрее.

Но даже Лен Холгейт только смог получить пакеты UDP со скоростью 500 кбит / с в своих высокопроизводительных тестах Windows RIO , используя полезную нагрузку UDP 1024 байта.

В официальном документе QLogic (тестируемая ОС не упоминается) пределы для «многопоточной маршрутизации сверхмалых пакетов» (что включает как получение, так и последующую отправку?) Установлены в 5,7 Мбит / с . В статьях, посвященных сетям Linux , ограничения установлены в 1Mpps на 2Mpps на ядро ​​(как сообщается, более или менее линейно увеличиваются) или даже 15Mpps с помощью специальных решений, которые обходят ядро.

Например, карта сети

может генерировать трафик на скорости линии ( 14,88 Мбит / с ) по каналу 10GigE с одним ядром, работающим на частоте 900 МГц. Это равняется примерно 60-65 тактам на пакет и хорошо масштабируется с ядрами и тактовой частотой (при 4 ядрах скорость линии достигается на частоте менее 450 МГц). Подобные ставки достигаются на стороне получения .

Итак, как далеко я могу зайти (последние версии) Windows / Windows Server, в частности, получить многоадресную UDP-рассылку, как описано в главном параграфе?

Редактировать В блоге Cloudflare есть интересный раздел с комментариями о том, как это сделать в Linux: как получать миллион пакетов в секунду , и есть соответствующая страница с комментариями хакерских новостей .


@Ramhound Теоретически, это возможно в Windows. Но как это возможно на практике? К настоящему времени я встречал довольно много сообщений от людей, достигших этих уровней в Linux на стандартном оборудовании, но ни одного из них не было близко к Windows. И как вы думаете, я мог бы уменьшить объем вопроса? Это просто так: «Каковы самые высокие скорости многоадресного приема UDP в Windows?». Основная часть текста в моем вопросе - только примеры, которые должны показать, что это возможно с Linux - и что я сделал свою домашнюю работу.
Евгений Бересовский

@Ramhound «Если это возможно в Linux, то возможно в Windows». Я соответственно не согласен .. одна система, которая сразу приходит на ум, это iptables .. да, удачи, имитирующей эту систему на windows. ^ _ ^
NiCk Ньюман

На самом деле я не пытался так усердно, так что вы всегда могли взять весь код, который у меня есть, для тестирования RIO, которое я делал, и продолжить работу.
Лен Холгейт

Ответы:


5

По словам Microsoft, тесты в их лаборатории показали, что «на определенном сервере в начале тестирования» RIO , они были в состоянии справиться

  • 2Mpps без потерь в Windows Server 2008R2, т.е. без RIO
  • 4Mpps (предварительная версия) Windows Server 8 с использованием RIO

Скриншот из этого видео (44:33):

введите описание изображения здесь

Таким образом, ответ на мой вопрос Is it possible to process millions of datagrams per second with Windows?будет: Да , и, видимо, это было еще до RIO, в Windows Server 2008R2.

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

  1. Есть ли цифры для отправки? Прием? Или, может быть, для маршрутизации (т.е. получить + отправить)?
  2. Какой размер пакета? -> Вероятно, самый низкий из возможных, как это обычно делается при попытке заставить цифры pps хвастаться
  3. Сколько соединений (если TCP) / потоков пакетов (если UDP) ? -> Вероятно, столько, сколько необходимо для распределения рабочей нагрузки, чтобы можно было использовать все имеющиеся ядра.
  4. Какие настройки теста? Характеристики машины и сетевого адаптера и проводка

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


Редактировать Я просто наткнулся на документ Intel на высокопроизводительных пакетов обработки на Linux, и по этому, (Linux)

Платформа может поддерживать скорость транзакций около 2 миллионов транзакций в секунду.

используя стандартный сетевой стек Linux (на физическом хосте с ядрами 2x8). Транзакция в этом тесте запроса / ответа включает в себя как

  1. прием UDP-пакета
  2. последующая пересылка этого пакета

(используя сетевой сервер netperf). Тест выполнял 100 транзакций параллельно. Есть много подробностей в статье, для тех, кто заинтересован. Хотелось бы, чтобы у нас было что-то подобное для сравнения Windows ... В любом случае, вот наиболее подходящая диаграмма для этого теста запрос / ответ:

введите описание изображения здесь


2

ТЛ; др

Чтобы дать определенный ответ, дополнительные тесты кажутся необходимыми. Но косвенные данные свидетельствуют о том, что Linux - это ОС, используемая практически исключительно в сообществе с ультранизкими задержками, которое также регулярно обрабатывает рабочие нагрузки Mpps. Это не означает, что это невозможно с Windows, но Windows, вероятно, немного отстанет, хотя может быть возможно достичь числа Mpps. Но это требует тестирования, чтобы убедиться, и, например, чтобы выяснить, какой ценой (ЦП) эти цифры могут быть достигнуты.

NB. Это не тот ответ, который я намерен принять. Он предназначен для того, чтобы дать всем, кто заинтересован в ответе на вопрос, несколько советов о том, где мы находимся и где проводить дальнейшие исследования.


Лен Холгейт, который, по словам Google, кажется, единственный, кто протестировал RIO, чтобы повысить производительность сети Windows (и опубликовал результаты), только что пояснил в комментарии в своем блоге, что он использует одну комбинацию IP / Port для отправки пакетов UDP.

Другими словами, его результаты должны быть несколько сопоставимы с одноядерными показателями в тестах на Linux (хотя он использует 8 потоков - что, еще не проверив его код, кажется вредным для производительности при обработке только одного потока пакетов UDP, а не выполняя любую тяжелую обработку пакетов, и он упоминает, что фактически используется только несколько потоков, что имело бы смысл). Это несмотря на то, что он сказал:

Я не очень старался получить максимальную производительность, просто сравнивая относительную производительность между старыми и новыми API, и поэтому я не был настолько тщательным в своем тестировании.

Но что означает отказ от (относительной) зоны комфорта стандартного IOCP для более грубого мира RIO, кроме «упорных усилий »? По крайней мере, в отношении одного потока пакетов UDP.

Я предполагаю, что он имеет в виду - поскольку он пробовал различные подходы к проектированию в нескольких тестах RIO - то, что он, например, не настраивал параметры NIC, чтобы выжать последний бит производительности. Что, например, в случае размера буфера приема может потенциально оказать огромное положительное влияние на производительность приема UDP и показатели потери пакетов.

Проблема, однако, при попытке напрямую сравнить его результаты с результатами других тестов Linux / Unix / BSD заключается в следующем: большинство тестов, когда пытаются раздвинуть границу «пакетов в секунду», используют наименьший возможный размер пакета / кадра, то есть Ethernet кадр 64 байта. Лен проверил 1024-байтовые пакеты (-> 1070-байтовый кадр), которые (особенно для UDP без Nagle) могут принести вам гораздо более высокие значения «бит в секунду», но не могут раздвинуть границу pps, как это возможно для меньших пакетов , Поэтому было бы несправедливо сравнивать эти цифры как есть.

Подводя итоги моего квеста в Windows UDP, вы получите производительность:

  • Никто на самом деле не использует Windows, когда пытается развить приложения с очень низкой задержкой и / или высокой пропускной способностью, в наши дни они используют Linux
  • Практически все тесты производительности и отчеты с реальными результатами (т.е. не просто рекламой продукта) в наши дни проводятся на Linux или BSD (спасибо Лен за то, что он был пионером и дал нам хотя бы одну точку отсчета!)
  • UDP (стандартные сокеты) в Windows быстрее / медленнее, чем в Linux? Я пока не могу сказать, пришлось бы провести собственное тестирование
  • Высокопроизводительный UDP (RIO против netmap) в Windows быстрее / медленнее, чем в Linux? Linux легко справляется с полной линейной скоростью 10 Гбит с одним ядром на частоте 900 МГц, Windows в лучшем случае публикуется с возможностью увеличить скорость до 43% или 492 кбит / с при большом размере UDP-пакета 1024, то есть цифры bps для меньших размеров, вероятно, будут значительно хуже, хотя цифры pps, вероятно, будут расти (если только обработка прерываний или некоторые другие затраты пространства ядра не являются ограничивающим фактором).

Что касается того, почему они используют Linux, то это должно быть потому, что разработка решений, которые включают изменения ядра, такие как netmap или RIO, - необходимые при повышении производительности до предела - почти невозможна с закрытой системой, такой как Windows, если только ваши зарплаты не происходят из Redmond, или у вас есть специальный контракт с Microsoft. Именно поэтому RIO является продуктом MS.

Наконец, просто приведу несколько крайних примеров того, что я обнаружил, и происходит на земле Linux:

Уже 15 лет назад некоторые получали 680 кбит / с, используя процессор Pentium III с тактовой частотой 800 МГц и шину с частотой 133 МГц на сетевой карте 1GbE. Изменить : они использовали Click , маршрутизатор в режиме ядра, который обходит большую часть стандартного сетевого стека, то есть они "обманули".

В 2013 году Argon Design удалось получить

тик для торговли с задержками до 35 нс [нано секунд]

Кстати, они также утверждают, что

Подавляющее большинство существующего компьютерного кода для торговли сегодня написано для Linux на процессорных архитектурах x86.

и Argon используют переключатель Arista 7124FX , который (в дополнение к FPGA) имеет ОС

построен на основе стандартного ядра Linux.


0

Вам наверняка понадобится «измерить» различные конфигурации и сценарии. Это может быть сделано AFAIK с двумя передачами, предоставленными 2 компаниями. IXIA и Spirent . Они предлагают аппаратные генераторы трафика, способные качать трафик на скорости линии. Они предлагают тестирование рампы, где вы можете определить скорость, с которой ваша конкретная система может рухнуть. Устройства дороги, но вы можете взять их напрокат.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.