NTP: El proyecto pool.ntp.org


El servicio de hora en Internet (NTP(1)Network Time Protocol(1)) es uno de los más usados, pero quizá también, uno de los menos conocidos.
Este desconocimiento hace que muchas veces se haga un mal uso de él.

El proyecto pool.ntp.org(2) llega para aportar su granito de arena en el remedio.

Una introducción a NTP
En este mundo cada vez más interconectado, se hace imprescindible sincronizar muchas de las acciones que realizamos.
Tener en hora nuestro sistema puede parecer una cosa sin importancia pero, cuando entran en juego nuestras interacciones con los demás, se hace imprescindible. Muchas veces no hace falta tener una alta precision, basta con que nuestro reloj esté cerca de la hora real, pero en otros casos, una precisión de segundos, o incluso menos, nos ayuda mucho.

¿Habéis tenido que analizar logs? ¿y los habéis tenido que casar con los de otras máquinas?, ¿no os molesta que la gente mande mensajes de correo en el futuro (o pasado) y os desordene los hilos de discusión?. ¿se os disparan las copias de seguridad cuando no toca?, ¿compartís ficheros entre máquinas? ¿cuál es la última versión de ese informe?…

Como veis, son muchas las situaciones en que tener el reloj en hora nos facilita las cosas (nos quita problemas).

Por suerte, tenemos herramientas muy útiles que se dedican a esta tarea y, además, son muy fáciles de configurar. Generalmente, se basan en la sincronización con los llamados servidores de hora (NTP); máquinas que, directa o indirectamente, están conectadas a relojes fiables, dando servicio a las demás.

Estoy preparando una introducción al funcionamiento de NTP, pero no estará lista hasta dentro de unos días. Mientras tanto, para los más interesados, aquí tenéis algunos enlaces que os pueden ser útiles:

Motivación
Todo lo explicado más arriba funciona muy bien… hasta que todo el mundo se empeña en tomar la hora de los mismos servidores, saturándolos.
El problema surge cuando los servidores más conocidos (normalmente de stratum 1) reciben tal avalancha de peticiones que saturan sus líneas de comunicación y degradan el servicio. ¿Os suenan nombres como time.nist.gov, chronos.cru.fr, swisstime.ethz.ch o los españoles hora.rediris.es y hora.roa.es?
Esta situación es especialmente grave al introducir muchos fabricantes de equipamiento de red sus direcciones de forma fija en el firmware de los dispositivos, no permitiendo el cambio y castigando sin sentido a unos pocos servidores.
También influye la creencia de muchos administradores (o no) que están convencidos de que obtendrán mejor sincronización si se conectan directamente con servidores de stratum 1 y siempre usan los mismos por no conocer otros.

Los ISP nos harían un gran favor si pusieran a disposición de sus clientes servidores públicos de hora. Es una cosa que no les cuesta nada, se configuran en unos minutos y no necesitan recursos adicionales… pero no está entre sus prioridades.

Debido a este problema, y a partir de una discusión(5) en el grupo de noticias comp.protocols.time.ntp(6), Adrian von Bidder(7) decidió ponerle solución mediante la creación de un grupo de servidores de hora (pool) asignados por round robin de DNS(8) en el dominio que él gestiona: time.fortytwo.ch(9)
Viendo que el proyecto era interesante y viable, el propio David Mills(10) se interesó por él y pasó a funcionar bajo el dominio pool.ntp.org.

Así, desde no hace mucho, son cada vez más las máquinas conectadas a Internet que se sincronizan con este grupo de servidores aligerando en la medida de sus posibilidades la carga de los más famosos, que se ven saturados continuamente.

Cómo funciona
El proyecto se nutre de servidores horarios de todo el mundo que se unen de forma voluntaria (unos 110 en el momento de escribir este artículo).

El sistema se basa en asignar el mismo nombre a varias máquinas en el DNS (round robin), con lo que cada vez que solicitamos una dirección, recibimos una contestación distinta. Este es un método sencillo pero muy útil para repartir la carga.

Esta asignación de direcciones se basa en una jerarquización por situación geográfica, añadiendo cada servidor a la zona DNS correspondiente a su país, a su continente y a la zona mundial que los engloba a todos, bajo el dominio pool.ntp.org.

Como ejemplo, un servidor de hora que esté situado en España, será añadido a las zonas es.pool.ntp.org, europe.pool.ntp.org y pool.ntp.org.

Otros ejemplos:

España
Canadá
Alemania
Nueva Zelanda

País
es.pool.ntp.org
ca.pool.ntp.org
de.pool.ntp.org
nz.pool.ntp.org

Continente
europe.pool.ntp.org
north-america.pool.ntp.org
europe.pool.ntp.org
oceania.pool.ntp.org

Global
pool.ntp.org
pool.ntp.org
pool.ntp.org
pool.ntp.org

Veamos un ejemplo de zona:

Si consultamos al DNS la dirección IP de es.pool.ntp.org veremos como no obtenemos una respuesta única.

xisco@lluna:~$ dig es.pool.ntp.org

; <<>> DiG 9.2.3 <<>> es.pool.ntp.org

[…] # Eliminamos parte de la respuesta que no interesa en este momento.

;; QUESTION SECTION:
;es.pool.ntp.org. IN A

;; ANSWER SECTION:
es.pool.ntp.org. 5400 IN A 80.34.215.206
es.pool.ntp.org. 5400 IN A 80.38.245.22
es.pool.ntp.org. 5400 IN A 130.206.130.95
es.pool.ntp.org. 5400 IN A 213.96.80.106
es.pool.ntp.org. 5400 IN A 217.125.14.244
es.pool.ntp.org. 5400 IN A 217.127.32.90
es.pool.ntp.org. 5400 IN A 217.127.249.18

[…] # Eliminamos parte de la respuesta que no interesa en este momento.

En este caso, hemos obtenido la dirección de siete de los ocho servidores españoles que están en el proyecto.

Veamos qué sucede con la zona europea:

xisco@lluna:~$ dig europe.pool.ntp.org

; <<>> DiG 9.2.3 <<>> europe.pool.ntp.org

[…] # Eliminamos parte de la respuesta que no interesa en este momento.

;; QUESTION SECTION:
;europe.pool.ntp.org. IN A

;; ANSWER SECTION:
europe.pool.ntp.org. 5400 IN A 130.60.7.44
europe.pool.ntp.org. 5400 IN A 130.60.75.58
europe.pool.ntp.org. 5400 IN A 131.211.80.155
europe.pool.ntp.org. 5400 IN A 193.2.10.117
europe.pool.ntp.org. 5400 IN A 193.45.254.143
europe.pool.ntp.org. 5400 IN A 193.170.141.4
europe.pool.ntp.org. 5400 IN A 195.185.228.210
europe.pool.ntp.org. 5400 IN A 212.204.230.141
europe.pool.ntp.org. 5400 IN A 217.114.97.98
europe.pool.ntp.org. 5400 IN A 217.127.249.18
europe.pool.ntp.org. 5400 IN A 217.204.76.170
europe.pool.ntp.org. 5400 IN A 62.245.244.34
europe.pool.ntp.org. 5400 IN A 80.237.234.15
europe.pool.ntp.org. 5400 IN A 80.254.168.209
europe.pool.ntp.org. 5400 IN A 81.31.113.153

[…] # Eliminamos parte de la respuesta que no interesa en este momento.

Hemos obtenido quince direcciones IP distintas.

Si lo hiciésemos con pool.ntp.org (la zona que los engloba a todos) obtendríamos una respuesta similar.

Curiosamente, el servidor con dirección IP 217.127.249.18 ha salido en ambas zonas (resaltado en cursiva), lo que nos confirma que cada servidor está incluido en la zona correspondiente a su país y en las superiores.

Pero si nos fijamos, veremos que hay algunas cosas que no cuadran:

  • Vemos que en la zona correspondiente a España (es.pool.ntp.org) sólo salen siete de los ocho servidores que están en ella.
  • La zona europea sólo nos ha devuelto quince servidores, cuando estamos seguros de que hay muchos más (hemos dicho que sólo en España ya hay ocho). ¿Dónde están los otros?
  • No se trata de ningún error, sino de un mecanismo que hace fiable y robusto el sistema.

    En el primer caso, el hecho de que no todos los servidores correspondientes a un país estén incluidos en la zona DNS, es debido a que, de forma periódica, se comprueba el estado y fiabilidad de los servidores implicados (recordemos que se trata de voluntarios sin ninguna garantía de operatividad).
    Para ello, las zonas DNS se actualizan aproximadamente cada hora a partir de los datos que dos servidores mantenidos por Adrian (uno en Suiza y otro en Nueva Zelanda) que velan por el correcto funcionamiento de todos los servidores monitorizando su estado mediante las herramientas que NTP proporciona. De esta forma, aquellos servidores que quedan desconectados o, sencillamente, no ofrecen una hora razonablemente buena, son eliminados temporalmente.

    El sitema se basa en la asignación de una puntuación entre dos extremos: si un servidor está funcionando bien, se le suman puntos, si no, se le restan. Cuando alguno de ellos tiene una puntuación por debajo del umbral establecido, se retira del DNS y se sigue vigilando para una futura reincorporación.
    El método hace que las puntuaciones bajen muy deprisa en caso de mal funcionamiento, pero tarden un poco más en subir, asegurando así que no existen servidores malos en el sistema.

    Cada día, como recordatorio, y sobretodo para que los distintos administradores estén al tanto del estado de sus máquinas, se manda un mensaje de correo a una lista creada a tal fin(11).

    He aquí un ejemplo:

    Servers with a score <= 5, currently not in the pool.ntp.org zone:

    IP score history
    ————————————————————————
    80.238.194.130 -11.0 #############x######################xxxxxxx#_xxxxx
    203.109.252.8 -15.3 x###xxxxxxx#xxxxxxxxxxxxx#xxxxx#xxx#xx#xx#xxxxxxxx
    137.208.7.4 -23.5 x########x#xxxxxxxxxxxxxxxxxx###xxxxxxxxxxxxxxxx##
    209.162.205.202 -34.7 ___x###xx##xx#xxxx##____________x_____xxx#########
    217.127.2.161 -88.8 ___x___x__xxx____x___xx____xx___xxxxxx__x_________
    132.248.81.101 -99.9 __________________________________________________
    204.17.42.197 -100.0 __________________________________________________
    ————————————————————————

    The history is one entry per hour (left is old values). Legend:
    #: monitoring server was synchronized to the server
    x: server was reported as falseticker
    _: server was reported unreachable

    En el segundo caso, en el que una zona sólo nos devuelve quince de los muchos servidores que tiene, se trata de una limitación del propio sistema DNS (que tiene que ver con el tamaño máximo de los datagramas UDP). Este sólo devuelve un máximo de quince registros, que escoge al hazar de todos los que tiene disponibles.
    Esto nos asegura que siempre obtendremos una respuesta distinta, que es lo que nos interesa. Bueno, esto no es cierto del todo, ya que si volvemos a hacer la misma petición, antes de alcanzar el TTL (en este caso 5400 segundos), obtendremos el mismo conjunto de servidores, eso sí, en distinto orden. Como los clientes suelen coger la primera de las respuestas, el sistema sigue siendo adecuado.

    En definitiva, el uso de la asignación por round robin de DNS es bueno, al menos, para lo que se pretende.

    El uso de este tipo de técnicas no debe extrañar en la asignación de servidores de hora. Mirad, si no, el ejemplo de Apple:

    xisco@lluna:~$ dig time.apple.com

    ; <<>> DiG 9.2.3 <<>> time.apple.com

    […] # Eliminamos parte de la respuesta que no interesa en este momento.

    ;; QUESTION SECTION:
    ;time.apple.com. IN A

    ;; ANSWER SECTION:
    time.apple.com. 3600 IN A 17.254.0.26
    time.apple.com. 3600 IN A 17.254.0.31

    […] # Eliminamos parte de la respuesta que no interesa en este momento.

    incluso en Europa

    xisco@lluna:~$ dig time.euro.apple.com

    ; <<>> DiG 9.2.3 <<>> time.euro.apple.com

    […] # Eliminamos parte de la respuesta que no interesa en este momento.

    ;; QUESTION SECTION:
    ;time.euro.apple.com. IN A

    ;; ANSWER SECTION:
    time.euro.apple.com. 86400 IN A 17.72.133.45
    time.euro.apple.com. 86400 IN A 17.72.133.42

    Cómo usarlo
    Viendo la necesidad de tener nuestros ordenadores en hora y sabiendo cómo funciona pool.ntp.org, veamos cómo debemos utilizarlo para aprovechar sus ventajas.

    Tanto si utilizamos programas cliente como programas servidor para tener nuestro reloj en hora, deberemos usar los nombres genéricos que hemos visto en lugar de fijar los servidores por su nombre o dirección IP concreta.
    Supongamos, por ejemplo, que vamos a usar ntpdate (que se distribuye con ntp) para sincronizar nuestro ordenador. Al hacerlo, usaremos servidores que estén cercanos (en términos de red) a nosotros, ya que es la mejor manera de facilitar las cosas al protocolo ntp.

    Estando en España podemos utilizar es.pool.ntp.org

    Como root,

    lluna:~# ntpdate es.pool.ntp.org
    28 Dec 23:17:58 ntpdate[16209]: adjust time server 217.127.249.18 offset 0.022792 sec

    Vemos que nos hemos sincronizado con uno de los servidores del pool (no nos importa cual), que sabemos que son vigilados para dar un buen servicio.
    Si lo hacemos otra vez (o varias), veremos que se nos asigna un servidor diferente:

    lluna:~# ntpdate es.pool.ntp.org
    28 Dec 23:18:03 ntpdate[16210]: adjust time server 80.34.215.206 offset 0.014720 sec

    lluna:~# ntpdate es.pool.ntp.org
    28 Dec 23:18:06 ntpdate[16211]: adjust time server 130.206.130.95 offset 0.011288 sec

    Si en nuestro país no hubiera servidores, podríamos usar los dominios continentales o el global:

    lluna:~# ntpdate europe.pool.ntp.org
    28 Dec 23:28:40 ntpdate[16301]: adjust time server 217.114.97.97 offset -0.018957 sec

    lluna:~# ntpdate pool.ntp.org
    28 Dec 23:29:09 ntpdate[16304]: adjust time server 63.164.62.249 offset 0.000687 sec

    Con el uso de ntpdate y herramientas similares conseguimos poner en hora nuestro reloj pero, a partir de ese momento, éste empieza a derivar alejándose de la hora correcta.
    Para tener un ordenador mínimamente sincronizado con estas herramientas será necesario programarlas con cron, de forma que se ejecuten periódicamente.

    El uso de clientes de este tipo tiene, a parte de no mantener la hora todo el tiempo, el problema de efecturar “saltos en el tiempo” en el reloj del sistema al ajustarlo, cosa que no agrada a muchos programas, entre ellos el kernel.
    Es mucho más recomendable la utilización de programas servidores como ntp o chrony para mantener la hora del ordenador. No crean estos problemas y son muy fáciles de configurar.
    De hecho, la gente que ha desarrollado las herramientas de ntp está discutiendo si van a eliminar ntpdate en futuras versiones.

    En el caso de que decidamos usar programas servidores (ya sea simplemente para tener nuestro ordenador en hora o para dar servicio a otras máquinas), podemos proceder de la siguiente forma:

    (el ejemplo usa ntpd)

    Instalar ntpd es muy sencillo, sobre todo en distribuciones como Debian. Tenéis un buen artículo que explica como hacerlo(3) en Bulma.
    Pero a la hora de configurarlo debéis tener en cuenta lo que hemos comentado hasta ahora y, en lugar de usar servidores fijos (a no ser que sean nuestros), conviene usar los de pool.ntp.org.

    Este prodría ser un fichero de configuración mínima, normalmente /etc/ntp.conf:

    driftfile /var/lib/ntp/ntp.drift

    server es.pool.ntp.org
    server es.pool.ntp.org
    server es.pool.ntp.org

    La primera linea es importante, porque hace que ntpd guarde en un fichero el valor de la deriva de nuestro reloj. De esta forma, al arrancar de nuevo, no tiene que calcularla (tarda aproximadamente una hora), sino que puede empezar con el último valor guardado. Este fichero se actualiza cada cierto tiempo.

    Lo más interesante del fichero de configuración son las lineas que nos indican qué servidores vamos a usar para sincronizarnos. Como veis, todas ellas son iguales, aprovechando la resolución DNS que hemos explicado más arriba. De esta forma, obtenemos tres servidores distintos con los que actuar.

    En el caso de que en el país en el que esté nuestra máquina no haya muchos servidores de hora o tengamos miedo de que, por alguna de esas casualidades, la resolución repita alguno, podemos añadir alguna linea más (ntp funciona bien a partir de tres).

    driftfile /var/lib/ntp/ntp.drift

    server es.pool.ntp.org
    server es.pool.ntp.org
    server es.pool.ntp.org
    server europe.pool.ntp.org
    server europe.pool.ntp.org

    ntpd tarda un tiempo en ponerse en hora, pero a partir de ese momento, mantendrá sincronizado nuestro reloj.
    Para acelerar el proceso, se pueden usar una serie de parámetros avanzados de configuración que podéis encontrar en la documentación de ntp(12).

    Pasado un tiempo podemos ver cómo nuestro ordenador se pone en hora a partir de otros:

    xisco@lluna:~$ ntpq -pn
    remote refid st t when poll reach delay offset jitter
    ==============================================================================
    -80.34.215.206 213.144.140.154 3 u 143 256 377 126.321 24.212 0.798
    +130.206.130.95 129.132.2.21 2 u 74 256 377 68.792 -8.019 2.836
    *217.127.249.18 193.79.237.14 2 u 88 256 377 110.388 -6.299 1.346
    80.38.245.22 130.206.3.166 2 u 74 256 377 942.683 -397.04 399.034
    +193.45.254.143 212.94.162.1 3 u 80 256 375 87.577 -2.074 100.146

    Aquí vemos cómo tomamos como referencia el tercero de los servidores (*), siendo el segundo y el quinto (+) alternativas a tener en cuenta que entran en el cálculo de la hora, descartando momentaneamente los demás.

    Con ntptrace conoceremos cuál es el origen de nuestra hora:

    xisco@lluna:~$ ntptrace -n
    127.0.0.1: stratum 3, offset 0.000038, synch distance 0.18706
    217.127.249.18: stratum 2, offset -0.006845, synch distance 0.09442
    193.79.237.14: stratum 1, offset -0.006269, synch distance 0.00000, refid ‘GPS’

    Nuestra máquina (127.0.0.1) toma la hora de 217.127.249.18, que está sincronizado con 193.79.237.14, que tiene por referencia un receptor GPS. En este caso, nuestro ordenador se ha convertido en un servidor NTP de stratum 3.

    Si dejamos que ntpd funcione durante más tiempo haciendo su trabajo mejoraremos mucho la precisión.

    NTP puede correr en cualquier tipo de UNIX y derivados. Incluso existe una versión para Win32.
    Si se decide usar programas clientes, cada sistema tiene los suyos, aunque yo recomendaría ntpdate. En el caso de sistemas Windows (hasta 2000), he probado con satisfacción Dimension4(13) (no es libre, pero sí gratuito), uno de los más completos para estos sistemas. Versiones superiores de Windows ya tienen sus propias herramientas.

    Todos aquellos que usáis Debian estáis de suerte. Hace ya tiempo que la persona encargada de mantener el paquete ntp se comprometió a usar pool.ntp.org en las configuraciones por defecto, así que seguramente ya los estáis usando. No estaria de más, pero, que comprovaseis vuestras configuraciones.

    Cómo unirse al proyecto
    ¡Cómo no! si estás interesado en el tema y cumples unos mínimos requisitos puedes unirte al proyecto haciendo públicos tus servidores de hora y ayudando a solventar el problema.
    En realidad es muy sencillo, tu máquina pasará a formar parte del pool y dará servicio a muchas otras, ayudando al mismo tiempo, a repartir la carga (que se convierte en muy poca). He aquí la gracia de los trabajos colaborativos en Internet.

    Los requisitos a cumplir son muy pocos:

  • Poseer una dirección IP estática.
  • Tener conexión permanente a Internet.
  • Abrir el puerto 123/UDP hacia el exterior.
  • Comprometerse a mantener el servicio en la medida de tus posibilidades.
  • Nada más que eso.

    Algunos se asustan al pensar que con pequeñas líneas ADSL o de cable, y recibiendo peticiones horarias de todo el mundo, van a quedar saturados y verán su actividad normal afectada. Nada más lejos de la realidad.
    En el peor de los casos, se reciben un par de peticiones por minuto, que además, mueven muy poca información. Ni se nota.

    Os pongo un ejemplo: estas son las peticiones que ha recibido un servidor cualquiera en los últimos diez minutos.

    xisco@lluna:~$ ntpdc -n -c monlist pool.ntp.org
    remote address port local address count m ver drop last first
    ===============================================================================
    217.127.32.90 34932 64.113.215.94 1 7 2 0 0 0
    68.55.19.124 123 64.113.215.94 14 3 4 0 2 839
    217.122.224.114 123 64.113.215.94 87143 3 1 0 3 3897979
    82.193.95.68 123 64.113.215.94 142 3 4 0 13 128422
    62.245.108.107 123 64.113.215.94 23276 3 4 0 14 1905206
    203.217.30.153 123 64.113.215.94 91359 3 4 0 18 5855033
    217.162.232.173 123 64.113.215.94 16053 3 2 0 20 9059586
    213.92.129.193 62326 64.113.215.94 125 3 4 0 23 9710
    63.211.151.94 123 64.113.215.94 6561 3 4 0 28 3533201
    198.17.18.245 123 64.113.215.94 46 3 4 0 29 3380
    63.211.151.82 123 64.113.215.94 8938 3 4 0 36 3533208
    194.67.224.150 123 64.113.215.94 4722 3 4 0 48 3220156

    doce en total, y una de ellas es la que acabamos de hacer.
    Probemos con otro…

    xisco@lluna:~$ ntpdc -n -c monlist pool.ntp.org
    remote address port local address count m ver drop last first
    ===============================================================================
    217.127.32.90 34932 216.204.154.12 1 7 2 0 0 0
    65.93.162.48 64689 216.204.154.12 1591 3 4 0 11 494226
    63.211.151.22 123 216.204.154.12 5331 3 4 0 18 3288680
    217.162.232.173 123 216.204.154.12 3627 3 2 0 25 3288940
    63.73.218.130 123 216.204.154.12 2091 3 4 0 28 282657
    193.252.186.212 123 216.204.154.12 66 3 4 0 30 50043
    63.211.151.80 123 216.204.154.12 3215 3 4 0 34 3288641
    62.2.201.222 123 216.204.154.12 1546 3 4 0 38 715817
    216.183.131.114 123 216.204.154.12 2978 3 3 0 43 1647336
    4.64.204.230 63983 216.204.154.12 382 3 3 0 52 809195
    193.165.220.66 64070 216.204.154.12 1777 3 4 0 54 559375
    66.152.249.115 123 216.204.154.12 17072 3 3 0 58 2431179
    212.115.19.158 123 216.204.154.12 793 3 4 0 59 289058

    trece en este caso, con una nuestra al igual que en el anterior.

    Como podéis ver, es ridícula la carga que tiene que soportar nuestro enlace con Internet (son datagramas UDP). Sólo los servidores más famosos que también están en la red pool.ntp.org soportan grandes cargas, pero es debido a las conexiones explícitas que reciben, no a las asignadas desde el pool.

    Para pasar a formar parte del proyecto, lo único que debéis hacer es configurar vuestro servidor, pero en este caso, no con servidores del pool (al menos, no asignados de forma aleatoria), sino que debéis elegir un conjunto estable de servidores que os den buen resultado (generalmente, que estén cercanos a vosotros en términos de red).

    Para elegirlos, podéis probar los de pool.ntp.org pero también los famosos servidores de stratum 1 y 2 (ahora sí, ya que la intención es quitarles carga) que podréis encontrar en distintos sitios:

    o, en general, cualquier conjunto que os provea de una buena sincronización.

    Pero, por favor, si no vais a hacer de servidores para otros (muchos otros), no uséis estas listas. Usad en su lugar los servidores del pool tal como se ha explicado antes.

    Una vez tengáis vuestro servidor en marcha (y habiendo comprobado su funcionamiento), podéis escribir a Adrian <[email protected](7)>, diciéndole que queréis ser incluidos en el pool, indicando la dirección IP del servidor y el país en el que está (físicamente). Eso es todo. 🙂

    Adrian suele estar bastante atareado y puede tardar varios días en contestar, dejad pasar unos cuantos antes de insistir.
    También puede pasar (lo sé por experiencia) que vuestros mensajes se queden en su sistema anti-spam, configurado muy ferozmente porque ya estaba cansado. En ese caso, podéis escribirme a mi y yo se lo haré llegar por un conducto abierto.

    Si queréis estar al día sobre lo que ocurre en el proyecto, os recomiendo visitar la página del mismo(17) de vez en cuando. También es conveniente que os apuntéis a las distintas listas de correo que hay allí (no os preocupéis, tienen muy poco tráfico).

    Y para que veáis lo vivo que está el proyecto, mientras estaba escribiendo esto, han mandado a una de estas listas un enlace hacia un nuevo servicio del pool. Se trata de la monitorización gráfica del estado de los servidores (está claro, en pruebas y como prototipo todavía).

    He aquí las gráficas para el servidor de Bulma, que también está incluido.

    ntp.bulma.net

    Los gráficos se actualizan cada 5 minutos – hora UTC-8 – m=ms, u=us – freq en ppm

    Más información sobre NTP

    NOTA: Esta es una versión preliminar del documento, que estará finalizado en unos días. Son bienvenidas todas las sugerencias.Lista de enlaces de este artículo:

  • http://www.ntp.org/
  • http://www.pool.ntp.org
  • http://bulma.net/body.phtml?nIdNoticia=1778
  • http://www.rediris.es/gt/iris-ntp/docs/
  • http://groups.google.com/groups?threadm=3E2DBFF7.F9A51614%40udel.edu
  • http://groups.google.com/groups?hl=es&lr=&ie=UTF-8&safe=off&group=comp.protocols
  • mailto:[email protected]
  • http://www.webopedia.com/TERM/R/Round_Robin_DNS.html
  • http://time.fortytwo.ch
  • http://www.eecis.udel.edu/~mills/
  • https://fortytwo.ch/mailman/pipermail/timekeepers-bulletin/
  • http://www.ntp.org/documentation.html
  • http://www.thinkman.com/dimension4/
  • http://www.eecis.udel.edu/~mills/ntp/servers.html
  • http://tycho.usno.navy.mil/ntp.html
  • http://www.cru.fr/NTP/serveurs_francais.html
  • http://www.pool.ntp.org/
  • http://pool.ntp.bitic.net
  • http://www.ntp.org
  • Este post ha sido traido de forma automatica desde https://web.archive.org/web/20140625063149/http:/bulma.net/body.phtml?nIdNoticia=1947 por un robot nigromante, si crees que puede mejorarse, por favor, contactanos.


    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.