ТЛ; др
Чтобы дать определенный ответ, дополнительные тесты кажутся необходимыми. Но косвенные данные свидетельствуют о том, что 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.
