Resumen

  • RIPE NCC reconoce en el firmware 5130 que 5120 entregaba como offset NTP la mitad del tiempo de ida y vuelta. El offset es incorrecto; el rtt no quedó afectado por esa regresión.
  • El 31 de agosto, a las 03:12 UTC, la API pública devolvía 2.721 registros Connected con 5120, 2.350 con 5130 y 14.680 conectados en total.
  • La cifra de 2.721 no equivale a mediciones NTP defectuosas. El dato bruto sí contiene fw, prb_id y tiempo, de modo que existe una clave para identificar y excluir filas 5120.
  • Falta convertir la nota de versión en una fe de erratas legible por máquinas, con campo afectado, límites temporales, acción autorizada y revisión. El recibo de despliegue del firmware debe mantenerse separado.

Dos fechas no delimitan el intervalo de cada sonda

El 29 de octubre de 2025 apareció el firmware 5120. Entre sus cambios figuraba una corrección del cálculo de offset NTP. La nota indicaba que aquel lanzamiento se aplicaba únicamente a sondas de software.

El 12 de agosto de 2026 llegó 5130 con una advertencia excepcionalmente concreta. El arreglo anterior había introducido una regresión: en lugar del desfase entre el reloj cliente y el servidor, 5120 informó la mitad del RTT. RIPE NCC remarca que los offsets de 5120 son incorrectos y que el RTT no está afectado.

Es tentador usar esas dos fechas como ventana de datos. Sería incorrecto. Publicar un paquete no instala el paquete en todas las sondas. Publicar su sustituto tampoco retira instantáneamente la versión anterior.

La API lo demuestra. En la instantánea sin caché del 31 de agosto había 2.721 registros de sonda con estado Connected y versión 5120. Había 2.350 en 5130 y 14.680 conectados en conjunto. Los 2.721 representaban aproximadamente el 18,5% del total conectado en ese instante.

No son 2.721 resultados erróneos, usuarios, operadores ni mediciones. La consulta no dice si cada sonda ejecutó NTP, cuándo actualizó, cuántas pertenecen a una misma organización ni por qué conserva una versión. El recuento puede variar al repetirlo. Su significado es más modesto: la migración continuaba después de publicarse el correctivo.

La primera corrección cambió la forma del fallo

El issue 130 conserva una secuencia que conviene no resumir como “un bug de NTP”.

Cuando se abrió, el 11 de julio de 2025, el problema descrito era de signo. Los cuatro tiempos del intercambio estaban bien, según el reporte, pero la fórmula los ordenaba al revés y calculaba un offset con signo contrario al definido en los RFC.

5120 se presentó como la solución. Un comentario del propio RIPE NCC del 29 de octubre dio el problema por corregido y señaló el commit. Nueve meses después, el 23 de julio de 2026, las pruebas de 5130 llevaron a reabrirlo: el mantenedor escribió que el cambio quizá no lo había arreglado y podía haberlo empeorado. Propuso aplicar las ecuaciones de RFC 5905 con cuatro marcas de tiempo de punto fijo de 64 bits.

5130 cerró el issue con el commit 197b599a7faa811d97ebd273078be176842264bb. La noticia no es que un error de signo duró quince meses. Es que un intento de corregirlo produjo una salida distinta, identificada después como medio RTT. Cualquier política de reprocesamiento debe saber cuál de esos estados generó cada fila.

El propio resultado ofrece una salida conservadora

El formato NTP de RIPE Atlas guarda fw, el firmware que produjo el resultado; prb_id, la sonda; y timestamp, el momento. Dentro de result separa offset de rtt y conserva origen, recepción, transmisión y llegada final.

Por eso el historial no es una caja negra. Quien conozca la advertencia puede filtrar fw: 5120. Tampoco tiene que descartar traceroutes, pings o DNS realizados por la misma sonda, porque la declaración se limita al offset NTP. Y no debe presentar el RTT como inválido: la fuente oficial hace la distinción contraria.

Esta posibilidad de selección no resuelve la gobernanza de la corrección. Una biblioteca automatizada necesita descubrir el aviso sin que su autor lea cada release. Un archivo necesita registrar qué versión de la fe de erratas aplicó. Un investigador necesita saber si debe excluir, recalcular o sustituir, y cuáles son los límites exactos por sonda.

La opción pública prudente hoy es excluir filas 5120 del análisis de offset. Duplicar o cambiar de signo todos los valores no está autorizado por las fuentes. Un método universal tendría que tratar errores, reintentos, arquitecturas y bordes temporales, además de publicar sus pruebas.

Tres registros para tres verbos

El primer registro es el de código: issue, commit y release que describen el defecto y su solución. Ya existe con bastante detalle.

El segundo es el de migración: cuántas sondas conectadas declaran cada versión a una hora concreta. La API permite construir una fotografía, pero un recibo publicado por RIPE NCC podría añadir cohortes seguras, hitos y una historia revisable.

El tercero es la fe de erratas de datos. Debe unir un identificador estable con el esquema NTP, firmware 5120, result[].offset, los campos no afectados, selector por versión/sonda/tiempo, primer y último resultado afectado, acción requerida, release 5130, commit corrector y revisiones.

Si esos tres registros se funden, un indicador verde de despliegue puede ocultar datos históricos sin marcar. Si se separan, una sonda aún en 5120 puede quedar visible como riesgo de producción mientras sus filas antiguas se excluyen correctamente; una sonda ya actualizada puede conservar un historial con calidad explícita.

Conservar antes de derivar

RIPE Atlas no debería borrar ni alterar silenciosamente la fila original. El dato bruto registra lo que emitió una versión concreta. La corrección debe producir una vista derivada que diga qué regla aplicó, con posibilidad de regresar al original.

Esa arquitectura reparte la autoridad. RIPE NCC define la semántica del resultado y el aviso canónico. El anfitrión controla la instalación. El propietario de la medición decide su finalidad. El consumidor decide si reanaliza su copia. La fe de erratas es el puente, no una transferencia de control.

La franqueza de 5130 y el campo fw ya reducen mucho la incertidumbre. El paso que falta es hacer que la decisión de calidad se pueda consultar, fijar y transportar con la misma facilidad que el resultado.

Fuentes