El 03/08/14 20:22, Manolo Díaz escribió: ...
alberto@apevia:~$ ntpdc -p remote local st poll reach delay offset disp ======================================================================= *RouterWrt 192.168.1.10 4 128 377 0.00032 -0.001888 0.10770 como ves, si son milisegundos sera despues del decimal, y la dispersión no llega a 1, tu tienes valores con varias unidadesClaro, tú estás usando tu router local, ese que está a pocos metros de distancia y es el siguiente nodo en la red, como servidor de tiempo. Naturalmente los retardos son bajísimos, faltaría más. Pero ese router ha de sincronizarse con otros servidores en internet, y seguro que el retardo ya no es tan bueno. No te engañes por la bondad de esos valores. Eso sí, como bien dices, todos los equipos de tu red estarán bien sincronizados. Tienes una configuración típica en una red local. En cambio, lo que está haciendo Maykel es usar directamente los servidores de tiempo de internet, sin consultar a ningún nodo de su red doméstica.
creo que estas mezclando los terminos,una cosa es el retardo en la consulta al NTP server que hayas configurado, y otra el desfase de la hora que tengas con el
sea cual sea la distancia que tengas con respecto a tu NTP server (el grado de proximidad, o saltos viene determinado por el stratum) tu desfase con respecto a tu servidor no debiera ser superior a medio segundo, ya que es este el umbral que determina NTP para ir modificando la hora de tu sistema (aunque de este dato no estoy seguro si corresponde a ntpdate)
si la consulta se ralentiza en demasia, entonces NTP deja de tener sentido ya que no puede garantizar la sincronización con el sistema
esas cifras que ha pegado, entiendo que deben ser provocadas por una ralentización excesiva en la consulta, o que lleva poco tiempo trabajando con este servidor, y aun no ha llegado a sincronizarlo correctamente (recordemos que NTP realiza su funcion gradualmente)