Ráfagas de envío que desbordan búferes poco profundos Sender bursts overflow shallow buffers
ID de la causa rt-burst · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura)
Si el servidor envía de golpe en cada tick las actualizaciones de miles de jugadores, el pequeño búfer de un switch o el límite instantáneo de la nube se desborda en menos de 1 ms y parte de los paquetes se descarta.
Por qué Al empezar el tick se envían a la vez los paquetes para todos los jugadores → Efecto El búfer del puerto del switch donde confluye el tráfico de varios servidores (de cientos de KB a unos pocos MB por puerto) o el límite de la instancia en la nube se desborda por un instante (con una utilización media baja) → En pantalla Varios jugadores sufren a la vez teletransporte y tirones; las métricas medias no muestran la causa
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de red (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Repartir el envío de un tick a lo largo del propio tick (el pacing por conexión apenas resuelve que miles de conexiones envíen todas al inicio del tick), escalonar la hora de inicio del tick de cada servidor, limitar con SO_MAX_PACING_RATE la velocidad de las conexiones que envían datos grandes.
Tareas (Equipo de infraestructura)
Servidores/SO: limitar la velocidad total de envío del servidor (shaper del SO del servidor, tc de Linux), suavizar con pacing (cola fq de Linux, BBR) las ráfagas de una sola conexión. Red: usar switches con búferes grandes, revisar a intervalos cortos los contadores de descartes de salida de los puertos del switch (la utilización media no los muestra).
Cifras de referencia
Un puerto de 10 Gbps puede enviar unos 1.25 MB en 1 ms. Si los ticks de varios servidores coinciden y confluyen en un mismo puerto, el búfer se llena en un instante.
En el gráfico
Sube con la carga · Descartes de salida del puerto del switch, tasa de retransmisión
Dónde mirar
Recoger cada pocos segundos los descartes de salida (ifOutDiscards) del puerto del switch donde está el servidor y del puerto de nivel superior; en la nube, mirar bw_out_allowance_exceeded y pps_allowance_exceeded en ethtool -S. Recoger con bcc tcpretrans las retransmisiones del mismo momento y cruzarlas
Se confirma si
La utilización media por minuto es baja, pero suben los descartes de salida o los allowance superados, y crecen con los jugadores conectados a la vez y con la gente concentrada en un lugar. Las retransmisiones no se concentran en un rango de IP de jugadores (ISP, región) y se producen en el mismo instante en muchas conexiones de ese servidor
Se descarta si
Si en el mismo puerto también suben los errores CRC o de entrada, apunta a “Errores físicos (cables, transceptores ópticos o conectores defectuosos)”. Si suben los contadores de descartes de la NIC o el softnet dropped del servidor receptor, a “Descarte de paquetes en el host del servidor receptor”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
El pacing actúa en cada conexión por separado. Cuando miles de conexiones envían uno o dos paquetes cada una al inicio del tick, el pacing por conexión apenas suaviza la ráfaga, y es el servidor del juego el que tiene que repartir los momentos de envío. En cambio, cuando una conexión envía datos grandes, la NIC corta decenas de KB en paquetes y los envía seguidos (TSO), y ese tipo de ráfaga el pacing sí la reparte bien.
Fuentes
High-Resolution Measurement of Data Center MicroburstsMeta Más del 70% de las ráfagas en los switches de rack del centro de datos terminan en decenas de µs, y la relación entre la utilización media por minuto y los descartes es débil (IMC 2017)
tc-fq(8) — Linux manual pageiproute2 La cola fq aplica pacing por socket (conexión), y SO_MAX_PACING_RATE fija la velocidad máxima de cada conexión
net/ipv4/tcp_bbr.cLinux kernel BBR fija pacing_rate a partir del ancho de banda estimado del cuello de botella
IP SysctlLinux kernel TCP ajusta el tamaño de las tramas TSO a la velocidad del flujo (máximo 64 KB, tcp_min_tso_segs)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: paquetes que no se enviaron y se descartaron aunque no había errores, por ejemplo, para liberar espacio de búfer