¿Es posible procesar millones de datagramas por segundo con Windows?

Estoy investigando si puedo implementar una aplicación HPC en Windows que reciba pequeños datagramas UDP de multidifusión (en su mayoría de 100 a 400 bytes) a una velocidad alta, usando una docena o hasta quizás 200 grupos de multidifusión (es decir, usando MSI-X y RSS, puedo escala a múltiples núcleos), realiza un procesamiento por paquete y luego lo envía. Al enviar a través de TCP, logré subir todo lo que necesitaba (6,4 Gb / s) sin golpear una pared, pero recibir datagramas a altas velocidades de pps resultó ser un problema.

En una prueba reciente en una máquina NUMA de alta especificación con una NIC Ethernet de 10 Gb de 2 puertos en Windows 2012 R2, solo pude recibir cientos de miles de datagramas UDP por segundo (caída temprana, es decir, sin procesar realmente los datos, para eliminar la sobrecarga de procesamiento de mi aplicación de la ecuación para ver qué tan rápido se vuelve) usando 2x12 núcleos, y la parte del kernel de los 12 grupos de multidifusión probados parecía distribuirse en 8 o 10 núcleos de un nodo NUMA ( se configuraron las colas RSS máximas) a 16), aunque con una aplicación .net, por lo que las aplicaciones nativas deberían poder ir más rápido.

Pero incluso Len Holgate solo logró recibir paquetes UDP a 500kpps en sus pruebas RIO de Windows de alto rendimiento , utilizando una carga útil UDP de 1024 bytes.

En el documento técnico de QLogic (no se menciona el SO bajo prueba), los límites para el "enrutamiento de paquetes superpequeños de subprocesos múltiples" (de modo que incluye tanto la recepción como el envío posterior?) Se establecen en 5.7Mpps . En los artículos sobre redes Linux , los límites se establecen en 1Mpps a 2Mpps por núcleo (según informes, aumentando más o menos linealmente), o incluso 15Mpps con soluciones especiales que omiten el núcleo.

Por ejemplo, netmap

puede generar tráfico a velocidad de línea ( 14.88Mpps ) en un enlace 10GigE con un solo núcleo funcionando a 900Mhz. Esto equivale a aproximadamente 60-65 ciclos de reloj por paquete, y se escala bien con núcleos y frecuencia de reloj (con 4 núcleos, la velocidad de línea se logra a menos de 450 MHz). Se alcanzan tasas similares en el lado de recepción .

Entonces, ¿hasta dónde puedo llegar (las últimas versiones de) Windows / Windows Server, en particular, recibir la multidifusión UDP como se describe en el párrafo anterior?

Editar Hay una publicación en el blog de Cloudflare, y una interesante sección de comentarios, sobre cómo hacerlo en Linux: cómo recibir un millón de paquetes por segundo , y está la página de comentarios de noticias de piratas informáticos correspondiente .

Según Microsoft, las pruebas en su laboratorio mostraron que "en un servidor en particular en las primeras pruebas" de RIO , podían manejar

• 2Mpps sin pérdida en Windows Server 2008R2, es decir, sin RIO
• 4Mpps en (pre-lanzamiento) Windows Server 8 usando RIO

Captura de pantalla de ese video (44:33):

Entonces, la respuesta a mi pregunta Is it possible to process millions of datagrams per second with Windows?sería: Sí , y aparentemente fue incluso antes de RIO, en Windows Server 2008R2.

Pero además de las cifras oficiales, especialmente en software inédito, deben tomarse con una pizca de sal, con solo la información escasa dada en esta presentación, quedan muchas preguntas sobre la prueba y, por lo tanto, cómo interpretar adecuadamente los resultados. Los más relevantes son:

1. ¿Son las cifras de envío? ¿Recepción? ¿O tal vez para el enrutamiento (es decir, recibir + enviar)?
2. ¿Qué tamaño de paquete? -> Probablemente el más bajo posible, como generalmente se hace cuando se trata de obtener cifras de pps para presumir
3. ¿Cuántas conexiones (si TCP) / flujos de paquetes (si UDP) ? -> Probablemente tantos como sea necesario para distribuir la carga de trabajo para que se puedan usar todos los núcleos presentes
4. ¿Qué configuración de prueba? Especificaciones y cableado de la máquina y NIC

El primero es crucial, porque los envíos y las recepciones requieren diferentes pasos y pueden mostrar diferencias sustanciales en el rendimiento. Para las otras figuras, probablemente podemos suponer que el tamaño de paquete más bajo, con al menos una conexión / flujo de paquetes por núcleo se estaba utilizando en una máquina de alta especificación para obtener las máximas cifras posibles de Mpps.

Editar Acabo de encontrar un documento de Intel sobre el procesamiento de paquetes de alto rendimiento en Linux, y de acuerdo con eso, el (Linux)

la plataforma puede mantener una tasa de transacción de aproximadamente 2 millones de transacciones por segundo

utilizando la pila de red Linux estándar (en un host físico con núcleos 2x8). Una transacción en esta prueba de solicitud / respuesta incluye ambos

1. recepción de un paquete UDP
2. reenvío posterior de ese paquete

(utilizando el servidor de red de netperf). La prueba estaba ejecutando 100 transacciones en paralelo. Hay muchos más detalles en el documento, para aquellos interesados. Desearía tener algo como esto para que Windows lo compare ... De todos modos, aquí está el cuadro más relevante para esa prueba de solicitud / respuesta:

tl; dr

Para dar una respuesta definitiva, parecen necesarias más pruebas. Pero la evidencia circunstancial sugiere que Linux es el sistema operativo utilizado prácticamente exclusivamente en la comunidad de latencia ultra baja, que también procesa rutinariamente cargas de trabajo de Mpps. Eso no significa que sea imposible con Windows, pero Windows probablemente se retrasará bastante, a pesar de que sea posible lograr números de Mpps. Pero eso debe probarse para determinarlo y, por ejemplo, para determinar a qué costo (CPU) se pueden lograr esos números.

Nota: Esta no es una respuesta que pretendo aceptar. Está destinado a dar a cualquier persona interesada en una respuesta a la pregunta algunas pistas sobre dónde estamos parados y dónde investigar más a fondo.

Len Holgate, quien según Google parece ser el único que probó RIO para obtener un mayor rendimiento de las redes de Windows (y publicó los resultados), solo aclaró en un comentario en su blog que estaba usando un solo combo de IP / Puerto para enviar los paquetes UDP.

En otras palabras, sus resultados deberían ser algo comparables con las cifras de un solo núcleo en las pruebas en Linux (aunque está usando 8 subprocesos, lo que, sin haber comprobado aún su código, parece perjudicial para el rendimiento cuando se maneja solo un flujo de paquetes UDP y no haciendo cualquier procesamiento pesado de los paquetes, y menciona que solo se usan pocos hilos, lo que tendría sentido). Eso a pesar de que él dice:

No estaba tratando de obtener el máximo rendimiento solo para comparar el rendimiento relativo entre las API antiguas y las nuevas, por lo que no fui tan exhaustivo en mis pruebas.

Pero, ¿qué es renunciar a la zona de confort (relativa) del IOCP estándar para el mundo RIO más duro además de "esforzarse"? Al menos en lo que respecta a una sola secuencia de paquetes UDP.

Supongo que lo que quiere decir, ya que intentó varios enfoques de diseño en varias pruebas de RIO, es que, por ejemplo, no ajustó la configuración de NIC para exprimir el último bit de rendimiento. Lo que, por ejemplo, en el caso del tamaño del búfer de recepción, podría tener un gran impacto positivo en el rendimiento de recepción UDP y las cifras de pérdida de paquetes.

Sin embargo, el problema cuando se trata de comparar directamente sus resultados con los de otras pruebas de Linux / Unix / BSD es el siguiente: la mayoría de las pruebas, cuando se intenta impulsar el límite de "paquetes por segundo", utilizan el tamaño de paquete / trama más pequeño posible, es decir, un Ethernet marco de 64 bytes. Len probó paquetes de 1024 bytes (-> un marco de 1070 bytes), que (especialmente para UDP sin Nagle) puede obtener cifras mucho más altas de "bits por segundo", pero puede no empujar el límite de pps hasta donde es posible con paquetes más pequeños . Por lo tanto, no sería justo comparar estas cifras tal como están.

Resumiendo los resultados de mi búsqueda en el UDP de Windows, recibo rendimiento hasta ahora:

• En realidad, nadie está usando Windows cuando intenta desarrollar aplicaciones de latencia ultra baja y / o alto rendimiento, actualmente están usando Linux
• Prácticamente todas las pruebas de rendimiento e informes con resultados reales (es decir, no solo publicidad de productos) en estos días están en Linux o BSD (¡gracias Len por ser pionero y darnos al menos un punto de referencia!)
• ¿UDP (sockets estándar) en Windows es más rápido / lento que en Linux? Todavía no puedo decirlo, tendría que hacer mis propias pruebas
• ¿El UDP de alto rendimiento (RIO vs netmap) en Windows es más rápido / lento que en Linux? Linux maneja fácilmente la velocidad de línea completa de 10 Gb con un solo núcleo a 900 MHz, Windows, en el mejor de los casos publicado, puede subir hasta el 43% o 492kpps para un gran tamaño de paquete UDP de 1024, es decir, las cifras de bps para tamaños más pequeños probablemente serán significativamente peor, aunque las cifras de pps probablemente aumentarán (a menos que la interrupción del manejo o alguna otra sobrecarga del espacio del núcleo sea el factor limitante).

En cuanto a por qué usan Linux, eso debe ser porque desarrollar soluciones que involucren cambios en el kernel como netmap o RIO, necesarias para llevar el rendimiento al límite, es casi imposible con un sistema cerrado como Windows, a menos que sus cheques salgan de Redmond, o tienes un contrato especial con Microsoft. Por eso RIO es un producto de MS.

Finalmente, solo para dar algunos ejemplos extremos de lo que descubrí fue y está sucediendo en la tierra de Linux:

Hace ya 15 años, algunos recibían 680kpps usando una CPU Pentium III de 800 mHz, un bus frontal de 133 mHz en una NIC de 1GbE. Editar : estaban usando Click , un enrutador en modo kernel que omite gran parte de la pila de red estándar, es decir, "engañaron".

En 2013, Argon Design logró obtener

marque para intercambiar latencias tan bajas como 35ns [nano segundos]

Por cierto, también afirman que

La gran mayoría del código informático existente para el comercio actual está escrito para Linux en arquitecturas de procesador x86.

y Argon usa el interruptor Arista 7124FX , que (además de un FPGA) tiene un sistema operativo

construido sobre un núcleo Linux estándar.

Seguramente necesitará "medir" diferentes configuraciones y escenarios. Esto se puede hacer AFAIK con dos equipos proporcionados por 2 empresas. IXIA y Spirent . Ofrecen generadores de tráfico basados ​​en hardware capaces de bombear el tráfico a la velocidad de la línea. Ofrecen una prueba de rampa donde puede detectar la velocidad a la cual su sistema particular podría colapsar. Los dispositivos son caros pero puedes alquilarlos.