Has elegido la edición de . Verás las noticias de esta portada en el módulo de ediciones locales de la home de elDiario.es.

Un segundo extra no amenaza a Internet en 2015

El 30 de junio tendrá 1 segundo más de duración, una singularidad que ya provocó problemas en servidores de todo el mundo cuando se aplicó este ajuste en 2012

Juan Jesús Velasco

Todos los años realizamos dos ajustes en nuestros relojes para adaptarnos a los horarios de verano e invierno y, cada cuatro años, el calendario pasa de tener 365 días a tener 366 (año bisiesto). Todos estos cambios y ajustes son algo que hemos asumido como cotidiano y los sistemas que usamos a diario (smartphones, ordenadores personales, servidores, etc.) están adaptados perfectamente para que se apliquen estos ajustes automáticamente, sin incidencias.

Sin embargo, a estos cambios cotidianos, hay que sumar un ajuste horario adicional que no es muy conocido. El Leap Second, también conocido como segundo intercalado provoca una singularidad bastante peculiar: un día que dura 24 horas y 1 segundo.

El Leap Second choca con la definición de tiempo de un sistema informático. Un día es, por definición, 24 horas. Traducido a segundos, 86.400 segundos. Esta es la cifra que el contador interno de un sistema toma como referencia. Así que pasar un día concreto a 86.401 segundos no es algo que cuadre con la manera de medir el tiempo en una computadora.

Precisamente, en este año 2015 hay que realizar el ajuste del Leap Second y, tomando como referencia algún incidente acontecido durante el último ajuste (que ocurrió en 2012), algunos medios se atreven a anunciar un colapso de internet cuando tanta alarma no es necesaria.

El origen del Leap Second

¿Por qué es necesario el ajuste del Leap Second?Leap Second? Para entenderlo hay que tomar como referencia la definición de lo que es un segundo. El segundo se definió originalmente como la 1/86400 parte de un día solar medido medido entre 1750 y 1890. Sin embargo, el Sistema Internacional de Unidades cambió la deinfición en 1967 para tomar como referencia los relojes atómicos (que son mucho más precisos) y fijó el segundo como “la duración de 9.192.631.770 oscilaciones de la radiación emitida en la transición entre los dos niveles hiperfinos del estado fundamental del isótopo 133 del átomo de cesio, a una temperatura de 0 K”.

Si bien la nueva definición permitía medir el tiempo de una manera muy precisa, los relojes atómicos son mucho más estables que la rotación de la Tierra (que presenta desfases). Por tanto, el tiempo UTC (Tiempo Universal Coordinado) que se mide con los relojes atómicos puede no coincidir con el tiempo solar medio dado que los efectos gravitatorios de la Luna afectan al movimiento rotatorio del planeta.

Cuando el desfase acumulado se aproxima a 1 segundo, el Servicio Internacional de Rotación de la Tierra y Sistemas de Referencia (International Earth Rotation and Reference Systems Service o IERS), que es el encargado de controlar la discrepancia entre el tiempo solar medio y la hora UTC, toma de la decisión de añadir o quitarle un segundo a la duración del año para así sincronizar ambas medidas de tiempo.

Dado que la velocidad de rotación de la Tierra no es predecible a largo plazo, el IERS realiza los controles para poder anunciar con 6 meses de antelación la fecha de un ajuste de “segundo intercalado”. Los ajustes solamente se pueden realizar al finalizar meses UTC, es decir, a mitad o finales de año (30 de junio y 31 de diciembre) y en este año 2015 tocará realizar el ajuste el próximo 30 de junio (la última vez fue el 30 de junio de 2012).

La periodicidad de estos ajustes no es fija. Entre 1972 y 1998 se realizaron 22 ajustes y entre 1998 y 2005 no se realizó ajuste alguno. Tras el ajuste de 2005, el siguiente se realizó en el año 2008 para pasar después al que se realizó en el año 2012.

El Leap Second y los sistemas informáticos

En la práctica, el Leap Second se traduce en la siguiente secuencia temporal: 23:59:59 → 23:59:60 → 00:00:00. Básicamente, esto es lo que viviremos el próximo 30 de junio y también es lo que vivirán nuestros ordenadores personales, nuestros smartphones y los servidores que soportan el buscador de Google, nuestro correo electrónico o nuestro servidor de archivos.

La mayoría de servidores y equipos de escritorio miden el tiempo usando el sistema POSIX. Con este sistema, el tiempo se mide como la cantidad de segundos transcurridos desde la medianoche UTC del 1 de enero de 1970; por tanto, cada día tiene, exactamente, 86.400 segundos. Con este sistema, los segundos de ajuste no son tenidos en cuenta y, dado que son algo que no es predecible, sí que es algo que los administradores de sistemas críticos deben controlar.

Hoy la mayoría de dispositivos se conectan a servidores para sincronizarse: nuestros smartphones toman como referencia horaria lo que marca la red del operador, los servidores utilizan servidores horarios (usando el protocolo NTP) y los equipos de escritorio también usan servicios de sincronización horaria (algo que podemos encontrar tanto en Windows como en Linux).

En principio, el servidor horario debería indicar al equipo cliente cuál es la hora y, por tanto, enviar la información del segundo de ajuste. Básicamente, el proceso debería ser transparente para el usuario y también para los sistemas cliente, sin embargo, en 2012, apareció algún que otro problema.

El 1 de julio 2012, servicios como Foursquare, LinkedIn, Reddit o Yelp, e incluso los sistemas de billetes de una compañía aérea dejaron de funcionar. ¿El motivo? Los servidores de estos servicios se quedaron “colgados” presentando un kernel panic; un error grave que paralizaba el sistema. El motivo de este problema fue la combinación del protocolo NTP (sincronización horaria) con distribuciones Linux que tenían el kernel 2.6.29 (o anteriores) aunque Linux no fue el único afectado, también aparecieron errores en Java.

Si bien el bug del Leap Second en Linux era algo que se conocía con cierta antelación, no todos los administradores de sistemas lo tenían controlado y algún que otro servicio terminó quedando caído.

Google fue una de las empresas que mejor se adaptó al Leap Second. Sus servicios no sufrieron ningún tipo de indisponibilidad gracias a que aplicaron una técnica denominada Leap Smear que consistió en “alargar el tiempo” de manera controlada. Concretamente, Google alteró la duración de los segundos previos al Leap Second para que estos durasen unos pocos milisegundos más de lo normal; de esta forma, fueron repartiendo este segundo extra para que, de manera casi imperceptible, el Leap Second quedase aplicado de manera gradual (y sin impacto en los sistemas).

Leap Second e Internet: no es el inicio del Apocalipsis

El Leap Second de 2012 nos enseñó mucho y, sin duda, fue un gran “campo de pruebas” para localizar errores y bugs en muchos sistemas (sobre todo si tenemos en cuenta que los ajustes anteriores se realizaron en 2008 y 2005). Que en 2012 se produjesen incidentes no es motivo para pensar que el Leap Second de 2015 vaya a provocar un colapso en Internet. Lo más probable es que no ocurra nada.

La mayoría de empresas de software desarrollaron parches para solventar estos bugs sobre la marcha y, dos años después, estas soluciones están integradas en las últimas versiones de sus productos. Técnicas como el Leap Smear que aplicó Google son una vía para minimizar posibles incidencias.

Linus Torvalds, el creador y responsable del desarrollo del kernel de Linux, ha intentado quitarle hierro al asunto del Leap Second y las supuestas amenazas a los servicios a los que accedemos a través de Internet. En una entrevista para la revista Wired, Torvalds deja claro que desde 2012 se han corregido los bugs que aparecieron y, por tanto, no es de esperar que ocurran incidentes de manera masiva. De hecho, siguiendo el pragmatismo que le caracteriza, Torvalds considera que no tiene mucho sentido que nos preocupemos por medir el tiempo de manera atómica o usando la rotación de la Tierra (salvo que seas un astrónomo). Desde su punto de vista, el Leap Second no es un asunto que preocupe a la mayoría de los usuarios.

Imágenes: Andrei Zmievski (Flickr), Dave Smith (Flickr), Alex Dawson (Flickr), Torkild Retvedt (Flickr) y CWCS Managed Hosting (Flickr)

Etiquetas
stats