¿Cuál es el retraso en TCP / UDP?

Question

¡AYUDA POR FAVOR! Tengo una aplicación que necesita un procesamiento lo más cercano posible al tiempo real y sigo encontrándome con este problema de retraso inusual con TCP y UDP. El retraso se produce como un reloj y siempre es el mismo período de tiempo (principalmente de 15 a 16 ms). Ocurre cuando se transmite a cualquier máquina (incluso local) y en cualquier red (tenemos dos).

Un resumen rápido del problema:

Siempre estoy usando winsock en C ++, compilado en VS 2008 Pro, pero he escrito varios programas para enviar y recibir de varias maneras usando TCP y UDP. Siempre uso un programa intermedio (que se ejecuta local o remotamente) escrito en varios idiomas (MATLAB, C #, C ++) para reenviar la información de un programa a otro. Ambos programas winsock se ejecutan en la misma máquina, por lo que muestran marcas de tiempo para Tx y Rx desde el mismo reloj. Sigo viendo surgir un patrón donde se transmitirá una ráfaga de paquetes y luego hay un retraso de alrededor de 15 a 16 milisegundos antes de la próxima ráfaga a pesar de que no se haya programado ningún retraso. A veces puede haber entre 15 y 16 ms entre cada paquete en lugar de Una explosión de paquetes. Otras veces (rara vez) tendré un retraso de longitud diferente, como ~ 47 ms. Parece que siempre recibo los paquetes dentro de un milisegundo de su transmisión, aunque con el mismo patrón de retraso que se exhibe entre las ráfagas transmitidas.

Tengo la sospecha de que winsock o la NIC está almacenando paquetes en el búfer antes de cada transmisión, pero no he encontrado ninguna prueba. Tengo una conexión Gigabit a una red que recibe varios niveles de tráfico, pero también experimento lo mismo cuando ejecuto el programa intermedio en un clúster que tiene una red privada sin tráfico (al menos de los usuarios) y una conexión de 2 Gigabits. Incluso experimentaré este retraso cuando ejecute el programa intermedio localmente con los programas de envío y recepción.

Answer 1

Descubrí el problema esta mañana mientras reescribía el servidor en Java. La resolución del reloj de mi sistema Windows es entre 15 y 16 milisegundos. Eso significa que cada paquete que muestra el mismo milisegundo que su tiempo de transmisión en realidad se envía a diferentes milisegundos en un intervalo de 16 milisegundos, pero mis marcas de tiempo solo aumentan cada 15 a 16 milisegundos para que parezcan iguales.

Vine aquí para responder mi pregunta y vi la respuesta sobre elevar la prioridad de mi programa. Así que comencé los tres programas, entré al administrador de tareas, subí los tres a "tiempo real". prioridad (que no tenía ningún otro proceso) y los ejecutó. Obtuve los mismos intervalos de 15 a 16 milisegundos.

Sin embargo, gracias por las respuestas.

Answer 2

Siempre hay un buffering involucrado y varía entre hardware / drivers / os, etc. Los programadores de paquetes también juegan un papel importante.

Si desea " tiempo real difícil " garantías, probablemente deberías mantenerte alejado de Windows ...

Answer 3

Lo que probablemente esté viendo es un retraso del planificador: su aplicación está esperando que otros procesos terminen su división de tiempo y abandonen la CPU. Los intervalos de tiempo estándar en Windows multiprocesador son de 15 ms a 180 ms.

Puede intentar aumentar la prioridad de su aplicación / hilo.

Answer 4

Oh sí, sé lo que quieres decir. Windows y sus buffers ... intente ajustar los valores de SO_SNDBUF en el remitente y SO_RCVBUF en el lado del receptor. Además, verifique el hardware de red involucrado (enrutadores, conmutadores, puertas de enlace de medios): elimine la mayor cantidad posible entre las máquinas para evitar la latencia.