Prueba de comparación de RTPS rápido con Cyclone DDS y OpenSplice DDS
En todos los casos de prueba, Fast RTPS proporcionó una latencia más corta y un mayor rendimiento.
Entorno de prueba
El sistema es Ubuntu 18.04.2 LTS Bionic.
El kernel es el kernel universal Linux 4.15.0-64.
Las especificaciones de la máquina son las siguientes:
Arquitectura: x86_64
Procesadores: 8
Número de hilos por núcleo: 2 p>
Nombre del modelo: Procesador Intel Xeon E3-1230V6 @ 3.50GHz
Versión de middleware DDS: 2065 438 La última versión del almacén principal el 9 de septiembre de 2017.
Fast RTPS 1.9.x: 010ac53
Cyclone DDS: 801c4b1
OpenSplice DDS: v6.9
Proyecto de prueba comparativa (Latencia , rendimiento)
Prueba de latencia
Medición de la latencia:
En informática de red, la latencia se define como el tiempo que pasa un mensaje en la medida del sistema. Es decir, mide el tiempo que transcurre desde que el remitente envía un mensaje hasta que lo recibe el receptor. Para evitar problemas de sincronización del reloj entre editores y suscriptores, una forma de aproximar la latencia es mediante el tiempo de ida y vuelta. En este caso, el editor envía un mensaje y espera a que el suscriptor le devuelva el mensaje (similar al patrón de ping-pong), midiendo así el tiempo transcurrido entre la operación de envío del editor y la operación de recepción del editor. Para obtener una aproximación del tiempo de espera, divida el tiempo de ida y vuelta medido por 2.
Entorno y configuración de pruebas uniforme:
Para realizar las pruebas se envían 10.000 mensajes por cada tamaño de mensaje y se extraen las medidas mínima y media.
La configuración de DDS QoS es la siguiente:
Confiabilidad): confiable
Clase de historial: keep_last.
Profundidad del historial: 1
Durabilidad): volátil
- Comparación de localhost en progreso:
Conclusión: Localhost y el host dual La comparación muestra las claras diferencias entre Fast-RTPS y las otras dos implementaciones. Se puede ver que la latencia promedio de RPTS rápidos es siempre menor que el mínimo de otras implementaciones. Es importante tener en cuenta que la latencia Fast RTPS es estable con cargas útiles más grandes y aumenta a una tasa de crecimiento menor con cargas útiles más grandes en comparación con CycloneDDS u OpenSplice. En este caso, también vale la pena señalar que, especialmente en el caso de hosts duales, la media RTPS rápida sigue de cerca el mínimo, lo que significa que la diferencia entre el mínimo y el máximo es siempre pequeña (la distribución alrededor de la media es muy estrecha ).
Prueba de rendimiento
Medición del rendimiento:
En informática de red, el rendimiento se define como la cantidad de datos que se pueden enviar/recibir a través del sistema por unidad tiempo Medida de la cantidad de información, es decir, cuántos bits pasan por el sistema por segundo. La operación de medición normal consiste en que el editor envíe una gran cantidad de mensajes dentro de un intervalo de ráfaga. Después del envío, si la operación tarda menos que el intervalo de ráfaga, el Publisher descansará hasta que el intervalo haya transcurrido por completo (de lo contrario, el Publisher no podrá descansar). Haga esto hasta el momento de la prueba. Del lado del receptor, se reciben los mensajes, se registra la hora en que se recibió el primer mensaje y se cuenta cada mensaje que llega. Una vez completada la prueba, el receptor puede calcular la frecuencia de muestreo de recepción. Conociendo el tamaño de cada mensaje en bits, el rendimiento es simplemente el producto de la frecuencia de muestreo por el tamaño del mensaje. La siguiente imagen ilustra este proceso.
Entorno y configuración de prueba uniformes:
Utilice las siguientes herramientas para probar y comparar:
Para el experimento, 100, 200, 500, 1000, 10000, Requisitos de 20.000, 30.000, 40.000 y 50.000 mensajes.
Para los experimentos se utilizaron intervalos de pulso de 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 y 100 ms.
Algunos buffers del kernel están configurados para maximizar el flujo de información,
net core rmem _ default = 21299200
net rmem _ max = 21299200<. /p>
net .IP v4 .UDP _ mem = 102400 873800 21299200
net core . net dev _ max _ backlog = 30000
Utilice las siguientes versiones de software. prueba:
Compromiso RTPS rápido: 0 bcafbde 1 c6fa 3 ef 7285819980 f 932 df 910 DBA 61
Compromiso CycloneDDS: aa 5236 dea46 b 82 e 6 db 26 A0 c 87 b 90 cedeca 465524
Versión de OpenSplice: v6.9
La configuración de DDS QoS es la siguiente:
Fiabilidad): Confiable
Historial categoría: mantener_todo.
Durabilidad): Volátil
Conclusión: La comparación de localhost muestra una clara diferencia entre Fast-RTPS y las otras dos implementaciones. Se puede ver que Fast-RPTS tiene el mayor rendimiento por carga útil. En cuanto a la comparación entre los dos hosts, tanto Fast-RTPS como CycloneDDS muestran un rendimiento casi igual con una carga útil máxima de 256 bytes, pero después de 256 bytes la diferencia entre ellos se vuelve grande, lo que muestra que Fast-RTPS es mejor. (? ¿Pero en 2048 -> 4096 -> 8192 caerá?)
Finalmente: esto muestra que Fast RTPS es la implementación de mensajería más rápida en todos los casos de prueba. Además, Fast RTPS es el más consistente cuando se trata de retrasos en la entrega de mensajes. Todo esto significa que con Fast-RTPS, la latencia experimentada es mínima y siempre permanece casi igual.
Traducido de: /index.PHP/resources-all/performance/fast-rtps-vs-cyclone-DDS.