тл; д-р
Щоб дати чітку відповідь, здається, що потрібно більше тестів. Але непрямі дані свідчать про те, що Linux використовується ОС практично виключно у спільноті надмірних затримок, яка також регулярно обробляє завантаження Mpps. Це не означає, що це неможливо з Windows, але Windows, ймовірно, відставатиме зовсім небагато, навіть якщо можливо досягти числа Mpps. Але для цього потрібно встановити тестування і, наприклад, розібратися, за яку вартість (ЦП) ці цифри можна досягти.
NB: Це не відповідь, яку я маю намір прийняти. Він покликаний дати кожному, хто зацікавлений у відповіді на запитання, деякі підказки про те, де ми стоїмо та де далі розслідувати.
Лен Холгейт, який, за словами google, здається, єдиний, хто перевірив RIO для отримання більшої продуктивності в мережі Windows (і опублікував результати), просто пояснив у коментарі до свого блогу, що він використовує єдину комбо IP / Port для надсилання пакетів UDP.
Іншими словами, його результати повинні бути дещо порівняними з показниками однієї основної в тестах на Linux (хоча він використовує 8 потоків - що, ще не перевіривши його код, здається шкідливим для продуктивності під час обробки лише одного потоку пакетів UDP, а не роблячи будь-яку важку обробку пакетів, і він зазначає, що фактично використовуються лише декілька потоків, що мало б сенс). Це незважаючи на те, що він сказав:
Я не дуже намагався досягти максимальної продуктивності просто для порівняння відносної продуктивності між старими та новими API, тому я не був таким ретельним у своєму тестуванні.
Але що відмовляється від (відносної) зони комфорту стандартного IOCP для більш грубого світу RIO, окрім як «дуже старатися»? Принаймні, що стосується одного потоку пакетів UDP.
Я здогадуюсь, що він має на увазі - як він намагався виконати різні підходи до дизайну в декількох тестах RIO - це те, що він, наприклад, не налаштовував налаштування NIC, щоб видалити останній шматочок продуктивності. Що, наприклад, у випадку розміру буфера отримання, потенційно може мати величезний позитивний вплив на показники продуктивності прийому та втрати пакетів.
Проблема, проте, намагаючись безпосередньо порівняти його результати з результатами інших тестів Linux / Unix / BSD, полягає в наступному: Більшість тестів, намагаючись просунути межу "пакетів на секунду", використовують найменший можливий розмір пакета / кадру, тобто Ethernet кадр з 64 байт. Лен перевірив 1024 байт-пакети (-> кадр 1070 байт), який (особливо для UDP No-Nagle) може отримати вам набагато більші цифри "біт на секунду", але може не підштовхувати межу pps, наскільки це можливо з меншими пакетами . Тож було б справедливо порівнювати ці цифри як є.
Підбиваючи підсумки моїх пошуків роботи з UDP Windows, отримані результати:
- Ніхто насправді не використовує Windows, намагаючись розробити наднизькі затримки та / або додатки з високою пропускною спроможністю, в наші дні вони використовують Linux
- Практично всі тести та звіти про ефективність з фактичними результатами (тобто не просто рекламою товару) в наші дні працюють на Linux або BSD (дякую Лену за те, що він був першопрохідцем і що дав нам хоча б одну точку відліку!)
- Чи UDP (стандартні сокети) в Windows швидше / повільніше, ніж у Linux? Я ще не можу сказати, мені доведеться робити власне тестування
- Чи високопродуктивний UDP (RIO проти netmap) у Windows швидше / повільніше, ніж у Linux? Linux легко обробляє повну швидкість 10Gb з одноядерним процесором на 900 МГц, Windows, в кращому випадку опублікований , може отримати до 43% або 492kpps для великого розміру пакету UDP 1024, тобто цифри в секунду для менших розмірів, ймовірно, будуть значно гірше, хоча цифри pps, ймовірно, зростуть (якщо обмежуючий фактор не буде переривати обробку чи якийсь інший простір ядра).
Що стосується того, чому вони використовують Linux, це повинно бути, тому що розробка рішень, що передбачають зміни ядра, такі як netmap або RIO - необхідні, коли наповнюють продуктивність до меж - майже неможлива при закритій системі, як Windows, якщо ви не отримаєте ваші зарплати з Редмонда, або у вас є спеціальний контракт з Microsoft. Ось чому RIO - продукт MS.
Нарешті, лише для наведення декількох крайніх прикладів того, що я виявив, що відбувається і відбувається в Linux Linux:
Вже 15 років тому деякі отримували 680 кп / с, використовуючи процесор Pentium III з частотою 800 мГц, шиною 133 МГц на лицьовій стороні на 1GbE NIC. Редагувати : Вони використовували Click , маршрутизатор у режимі ядра, який обходить більшу частину стандартного мережевого стеку, тобто вони "обманювали".
У 2013 році Argon Design вдалося отримати
позначте затримки в торгівлі лише 35 секунд [наносекунд]
До того ж вони це стверджують
Переважна більшість існуючих сьогодні обчислювальних кодів для торгівлі написана для Linux на архітектурах процесорів x86.
та Аргон використовують перемикач Arista 7124FX , який (крім FPGA) має ОС
побудований поверх стандартного ядра Linux.
