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.7Mpps. В статьях, посвященных сетям Linux, ограничения установлены в 1Mpps на 2Mpps на ядро (как сообщается, более или менее линейно увеличиваются) или даже 15Mpps с помощью специальных решений, которые обходят ядро.

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

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

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

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

3 ответа3

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, то есть цифры бит / с для меньших размеров, вероятно, будут значительно хуже, хотя цифры pps, вероятно, будут расти (если только обработка прерываний или какие-либо другие издержки пространства ядра не являются ограничивающим фактором).

Что касается того, почему они используют Linux, это должно быть потому, что разработка решений, которые включают изменения в ядре, такие как netmap или RIO - что необходимо для увеличения производительности до предела - почти невозможна в закрытой системе, такой как Windows, если только ваши зарплаты не происходят из Редмонда, или у вас есть специальный контракт с 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. Они предлагают аппаратные генераторы трафика, способные качать трафик на скорости линии. Они предлагают тестирование рампы, где вы можете определить скорость, с которой ваша конкретная система может рухнуть. Устройства дороги, но вы можете взять их напрокат.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .