Estoy investigando si puedo implementar una aplicación HPC en Windows querecibe pequeños datagramas de multidifusión UDP (principalmente de 100 a 400 bytes) a una velocidad elevada, utilizando una docena o hasta quizás 200 grupos de multidifusión(es decir, usando MSI-X y RSS puedo escalar a múltiples núcleos), realiza algún procesamiento por paquete y luego lo envía. Al enviar a través de TCP logré llegar tan lejos como necesitaba (6,4 Gb/seg) sin chocar contra una pared, pero recibir datagramas a altas velocidades de pps resultó ser un problema.
en unprueba recienteen una máquina NUMA de alta especificación con una NIC Ethernet de 10 Gb y 2 puertos en Windows 2012 R2, solo puderecibir cientos de miles de datagramas UDP por segundo(caída anticipada, 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 núcleo de los 12 grupos de multidifusión probados parecía distribuirse en 8 o 10 núcleos de un nodo NUMA (Colas RSS máximasse configuró en 16), aunque con una aplicación .net, por lo que las aplicaciones nativas deberían poder funcionar más rápido.
Pero inclusoLen Holgate Solo logré recibir paquetes UDP a 500 kpps.ensus pruebas de alto rendimiento de Windows RIO, utilizando una carga útil UDP de 1024 bytes.
EnDocumento técnico de QLogic(No se menciona el sistema operativo bajo prueba) los límites para el "enrutamiento de paquetes súper pequeños de subprocesos múltiples" (¿eso incluye tanto la recepción como el envío posterior?) se establecen en5,7Mpps. Enartículosenredes linux, los límites se establecen en1Mpps a 2Mppspor núcleo (según se informa, aumentando más o menos linealmente), o incluso15Mppscon soluciones especiales que evitan el kernel.
P.ejmapa de red
puede generar tráfico a velocidad de línea (14,88Mpps) en un enlace de 10GigE con un solo núcleo funcionando a 900Mhz. Esto equivale a aproximadamente 60-65 ciclos de reloj por paquete y se adapta bien a los núcleos y la 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 llevar (las últimas versiones de) Windows/Windows Server, en particular recibir multidifusión UDP como se describe en el párrafo principal?
EditarHay una publicación de blog de Cloudflare (y una sección de comentarios interesante) sobre cómo hacerlo en Linux:Cómo recibir un millón de paquetes por segundo, y ahí está el correspondientepágina de comentarios de noticias de hackers.
Respuesta1
Según Microsoft, pruebas en su laboratorio.presentadoque "en un servidor particular en las primeras pruebas" deRÍO, fueron capaces de manejar
- 2Mpps sin pérdidaen Windows Server 2008R2, es decir, sin RIO
- 4Mpps en Windows Server 8 (prelanzamiento) 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 sobre software inédito, que deben tomarse con cautela, con sólo la escasa información proporcionada en esta presentación, quedan muchas preguntas sobre la prueba y, por lo tanto, sobre cómo interpretar adecuadamente los resultados. Los más relevantes son:
- ¿Las cifras son para el envío? ¿Recepción?¿O tal vez para enrutamiento (es decir, recibir + enviar)?
- ¿Qué tamaño de paquete?-> Probablemente el más bajo posible, como se suele hacer cuando se intenta conseguir cifras de pps de las que presumir
- ¿Cuántas conexiones (si es TCP)/flujos de paquetes (si es UDP)?? -> Probablemente tantos como sean necesarios para distribuir la carga de trabajo de modo que se puedan utilizar todos los núcleos presentes
- ¿Qué configuración de prueba?Especificaciones y cableado de la máquina y la NIC
El primero es crucial, porque los envíos y las recepciones requieren pasos diferentes y pueden mostrar diferencias sustanciales en el rendimiento. Para las otras cifras, probablemente podamos 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 de Mpps posibles.
EditarMe acabo de topar con un documento de Intel sobreProcesamiento de paquetes de alto rendimientoen Linux, y según eso, el (Linux)
La plataforma puede mantener una tasa de transacciones de aproximadamente 2 millones de transacciones por segundo.
utilizando la pila de red estándar de Linux (en un host físico con 2x8 núcleos). Una transacción en esta prueba de solicitud/respuesta incluye tanto
- recepción de un paquete UDP
- reenvío posterior de ese paquete
(usando el servidor de red de netperf). La prueba consistió en ejecutar 100 transacciones en paralelo. Hay muchos más detalles en el artículo, para aquellos interesados. Ojalá tuviéramos algo como esto para que Windows lo comparara... De todos modos, aquí está el gráfico más relevante para esa prueba de solicitud/respuesta:
Respuesta2
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 ultrabaja, que también procesa rutinariamente cargas de trabajo Mpps. Eso no significa que sea imposible con Windows, pero Windows probablemente se quedará un poco atrás, aunque sea posible alcanzar cifras de Mpps. Pero es necesario realizar pruebas para comprobarlo y, por ejemplo, determinar a qué coste (CPU) se pueden alcanzar esas cifras.
NB Esta no es una respuesta que pretendo aceptar. Su objetivo es dar a cualquiera interesado en una respuesta a la pregunta algunas pistas sobre dónde nos encontramos y dónde investigar más a fondo.
Len Holgate, que según google parece ser el único que ha probado RIO para sacar más rendimiento de las redes Windows (y publicó los resultados), acaba de aclarar en uncomenta en su blogque estaba usando un único combo IP/Puerto para enviar los paquetes UDP.
En otras palabras, suLos resultados deberían ser algo comparables a las cifras de un solo núcleo en las pruebas en Linux.(aunque está usando 8 subprocesos, lo cual, sin haber verificado su código todavía, parece perjudicial para el rendimiento cuando se maneja solo un flujo de paquetes UDP y no se realiza ningún procesamiento pesado de los paquetes, y menciona que en realidad solo se usan unos pocos subprocesos, lo cual tendría sentido). Eso a pesar de que él dijo:
No me esforcé tanto en obtener el máximo rendimiento solo para comparar el rendimiento relativo entre las API nuevas y antiguas, por lo que no fui tan exhaustivo en mis pruebas.
Pero que esRenunciar a la (relativa) zona de confort del IOCP estándar por el mundo RIO más complicado.¿Aparte de "esforzarse mucho"? Al menos en lo que respecta a un único flujo de paquetes UDP.
Supongo que lo que quiere decir, ya que probó varios enfoques de diseño en varias pruebas de RIO, es que no ajustó, por ejemplo, la configuración de la NIC para exprimir el último bit de rendimiento. Que, por ejemplo en el caso deTamaño del búfer de recepciónpotencialmente podría tener un enorme impacto positivo en el rendimiento de recepción UDP y en las cifras de pérdida de paquetes.
Sin embargo, el problema al intentar comparar directamente sus resultados con los de otras pruebas de Linux/Unix/BSD es el siguiente: la mayoría de las pruebas, cuando intentan superar el límite de los "paquetes por segundo", utilizan el tamaño de paquete/trama más pequeño posible, es decir, un Ethernet. trama de 64 bytes. Len probó paquetes de 1024 bytes (-> una trama de 1070 bytes), lo que (especialmente para No-Nagle UDP) puede brindarle cifras de "bits por segundo" mucho más altas, pero es posible que no supere el límite de pps tanto como sea 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 rendimiento de recepción UDP de Windows hasta el momento:
- En realidad, nadie usa Windows cuando intenta desarrollar aplicaciones de latencia ultrabaja y/o de alto rendimiento; hoy en día, usan Linux.
- Prácticamente todas las pruebas de rendimiento e informes con resultados reales (es decir, no simples anuncios de productos) hoy en día están en Linux o BSD (¡gracias Len por ser un pionero y darnos al menos un punto de referencia!)
- ¿UDP (sockets estándar) en Windows es más rápido/lento que en Linux? No lo sé todavía, 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? linuxfácilmentemaneja una velocidad de línea completa de 10 Gb con un solo núcleo a 900 MHz, Windows, en elmejor caso publicadoes capaz de alcanzar hasta el 43% o 492 kpps para un tamaño de paquete UDP grande de 1024, es decir, las cifras de bps para tamaños más pequeños probablemente serán significativamente peores, aunque las cifras de pps probablemente aumentarán (a menos que el manejo de interrupciones o alguna otra sobrecarga de espacio del núcleo sea la limitación). factor).
En cuanto a por qué usan Linux, debe ser porque desarrollar soluciones que involucran cambios en el kernel como netmap o RIO (necesarios para llevar el rendimiento al límite) es casi imposible con un sistema cerrado como Windows, a menos que sus cheques de pago provengan de Redmond. o tienes algún contrato especial con Microsoft. Por eso RIO es un producto de MS.
Finalmente, solo para dar algunos ejemplos extremos de lo que descubrí que estaba sucediendo y está sucediendo en el mundo de Linux:
Hace ya 15 años, algunos recibían 680 kpps usando unCPU Pentium III de 800 mHz, bus frontal de 133 mHzen una NIC de 1 GbE. Editar: Estaban usandoHacer clic, un enrutador en modo kernel que pasa por alto gran parte de la pila de red estándar, es decir, hicieron "trampa".
En 2013, Diseño ArgónadministradoLlegar
marque para intercambiar latencias tan bajas como 35 ns [nano segundos]
Por cierto, también afirman que
y argón utilizan elConmutador Arista 7124FX, que (además de una FPGA) tiene un sistema operativo
construido sobre un kernel de Linux estándar.
Respuesta3
Seguramente necesitarás "medir" diferentes configuraciones y escenarios. Esto se puede hacer AFAIK con dos equipos proporcionados por 2 empresas.IXIAyEspíritu. Ofrecen generadores de tráfico basados en hardware capaces de bombear tráfico a la velocidad de la línea. Ofrecen una prueba de rampa en la que puedes detectar la velocidad a la que tu sistema particular podría colapsar. Los dispositivos son caros pero puedes alquilarlos.