En general, ¿el "ping" de Linux debería ser más rápido que el "hrping" de Windows?

Question

Estoy usando HP DL360p Gen8. Instalé Windows Server 2008 R2 y RHEL7 de arranque dual. En ambos sistemas configuré LACP y VLAN. Entonces este es el mismo servidor, el mismo hardware, la misma red, las mismas tablas de rutas, etc.

Me preocupa la latencia, incluida la latencia de la red, porque estoy usando este servidor para operaciones HFT.

Ahora esperaba que si hago ping al mismo host desde Windows y Linux, entonces Linux debería ser un poco mejor. Sorprendentemente no es nada mejor. En realidad, es incluso entre 5 y 10 microsegundos peor que Windows cuando hago ping al mismo host.

• Estoy usando hrpingen Windows y pingen Linux.
• en Windows he usado la utilidad HP para crear equipos, en RHEL 7 he usado "equipamiento" integrado (no vinculación)

Esperaba que Linux fuera mejor porque:

• Supongo que la implementación de red de RHEL 7 es más rápida que Windows Server 2008 R2
• Supongo que la implementación de equipos RHEL 7/LACP/VLAN es más rápida que Windows Server 2008 R2/HP one

Mis preguntas:

1. si tal número existe: ¿cuántos microsegundos más rápido es el ping de RHEL 7 que de Windows Server 2008 R2?
2. ¿Si indica un problema potencial que Linux pinges de 5 a 10 microsegundos más lento o debería simplemente ignorar este hecho?
3. ¿Qué puedo hacer/diagnosticar/solucionar problemas para que Linux haga ping más rápido que Windows?

Por supuesto, en la vida real me preocupo más por la latencia del tráfico real, como TCP/UDP, pero lo estoy usando pingcomo primer paso. Probablemente pingmuestre los mismos números porque es "simple", pero en el tráfico TCP/UDP real, ¿Linux será mucho más rápido?

Answer 1

Hay una serie de factores. Primero está la máquina en la que estás ejecutando. Si Windows y Linux estuvieran en hardware diferente, la medición no tendría sentido.

Por supuesto, debe medir el ping promedio después de muchos intentos; los primeros pings pueden incluir otros retrasos.

Los paquetes tienen que pasar por el kernel (pila de IP y controlador de dispositivo de red) y luego ingresar nuevamente cuando se recibe la respuesta. En esta etapa, podrían haber muchos factores que influyan en la diferencia:

1. lo que realmente está cronometrado: dos implementaciones diferentes de ping podrían hacer un trabajo más o menos repetitivo entre iniciar el temporizador y enviar el objeto (y lo mismo en la ruta de recepción).
2. Existencia de filtros: firewalls y demás, pueden introducir pasos adicionales.
3. Granularidad del reloj: ¿con qué precisión el núcleo multiplexa los procesos? Incluso entre diferentes niveles de Linux, la longitud del tick puede variar mucho, o el kernel podría funcionar más o menos sin ticks (ejecutándose sin interrupciones si solo hay un proceso en ejecución).
4. Gestión de procesos: ¿con qué rapidez y de qué manera se activa el proceso cuando regresa el paquete? Windows y Linux hacen esto de maneras completamente diferentes.
5. ¿Qué está haciendo el resto del sistema? ¿Está ocurriendo una gran cantidad de E/S al mismo tiempo que haría que el kernel estuviera ocupado? ¿Hay algún cambio si haces niceping a una prioridad más alta?
6. Escalado de frecuencia: la gestión de la frecuencia de la CPU puede variar mucho: Linux tiene muchos "gobernadores" que hacen las cosas de manera diferente. Por lo tanto, es posible que Linux esté funcionando a una velocidad de reloj más baja cuando está inactivo; además, un momento de cambio de frecuencia tiene latencia adicional.
7. La implementación y compilación de pingla utilidad también podría tener algunos efectos menores (aunque la latencia interna del kernel es probablemente la principal contribución).

Se sabe que el kernel de Linux alcanza el límite de rendimiento de la red ennivel de 10 gigabits. Entonces... no debería hacer mucha diferencia a velocidades de microsegundos. Probablemente sea una cuestión de programación, latencias del sistema operativo, etc. Y la latencia del ping no representa el rendimiento real bajo carga. No debes tomar esta medida como un factor a la hora de decidir algo. Necesita muchos otros puntos de referencia, especialmente bajo cargas realistas.

Y, por último, la configuración del kernel de Linux puede influir en gran medida en el rendimiento: los proyectos en tiempo real necesitan un kernel dedicado para funcionar a un nivel óptimo. Encontrará más variaciones entre diferentes configuraciones (en ambas plataformas) que las que encontró en estos dos intentos.