Hola.
Existen varios servidores horarios usando protocolo NTP para mantener nuestros dispositivos razonablemente ajustados.
En España, la hora oficial la provee el Real Observatorio de la Armada, en San Fernando (Cadiz).
Para ver como ca podeis abrir este enlace: https://www2.roa.es/hora/
De todas formas, las cosas son mas complicadas de lo que parece, asi que si comparais la hora ( segundos incluidos) en varios moviles, vereis que en funcion del proveedor y de la red, hay variaciones de algunos segundos.
Curioso, ¿no?. Tanta tecnologia ......
Saludos.
ANgazu.
Servidores NTP horarios.
-
ANgazu
- Moderador Global
- Mensajes: 2362
- Registrado: 05 Nov 2014 21:02
- Agradecido : 160 veces
- Agradecimiento recibido: 1615 veces
-
ea1faq
- Mensajes: 7
- Registrado: 18 Dic 2023 14:57
- Agradecido : 69 veces
- Agradecimiento recibido: 16 veces
Servidores NTP horarios.
Los moviles tienen un ajuste de hora muy poco ortodoxo. Se supone que pillan la hora de las estaciones base de telefonia y cada estación base tiene un servidor de hora independiente por GPS. Por parte de las estaciones base la hora que sirven es perfecta, otra cosa es como lo manejan los dispositivos moviles.
En cuanto a los ordenadores, el protocolo NTP esta diseñado para pillar la hora de muchas fuentes, compararlas, seleccionar las de mas calidad, incluso generar un fichero "drift" que ajusta por si solo la imprecision del reloj local segun el error calculado previamente.
En los sistemas Linux/UNIX con ntp es facil tener una precision de 1ms si esta configurado correctamente.
Para aplicaciones informáticas es mas que suficiente.
No obstante, para algunas tareas es necesario tener mas precisión, con lo cual no queda mas remedio que usar un GPS y usar la salida de pulsos PPS para sincronizar. De esa forma es fácil tener una precisión mejor que 1 microsegundo.
Hace años colabore en un proyecto para sacar las orbitas de los meteoros pillando las reflexiones desde 3 puntos diferentes de España. Para tal tarea necesitábamos tener las grabaciones de audio finamente sincronizadas. Usamos un NTP profesional sincronizado por GPS y con salida de PPS que metíamos en un canal de la tarjeta de sonido y por el otro canal iba el audio de la emisora de VHF sintonizando el radar de Graves. Usábamos un software llamado vlftoolkit.
Eso puede ser muy interesante si por ejemplo se quieren localizar emisiones usando dos estaciones y mirando el tiempo de llegada de la señal.
Salida tipica de un ntp en linux. la columna offset es la diferencia horaria en ms.
En cuanto a los ordenadores, el protocolo NTP esta diseñado para pillar la hora de muchas fuentes, compararlas, seleccionar las de mas calidad, incluso generar un fichero "drift" que ajusta por si solo la imprecision del reloj local segun el error calculado previamente.
En los sistemas Linux/UNIX con ntp es facil tener una precision de 1ms si esta configurado correctamente.
Para aplicaciones informáticas es mas que suficiente.
No obstante, para algunas tareas es necesario tener mas precisión, con lo cual no queda mas remedio que usar un GPS y usar la salida de pulsos PPS para sincronizar. De esa forma es fácil tener una precisión mejor que 1 microsegundo.
Hace años colabore en un proyecto para sacar las orbitas de los meteoros pillando las reflexiones desde 3 puntos diferentes de España. Para tal tarea necesitábamos tener las grabaciones de audio finamente sincronizadas. Usamos un NTP profesional sincronizado por GPS y con salida de PPS que metíamos en un canal de la tarjeta de sonido y por el otro canal iba el audio de la emisora de VHF sintonizando el radar de Graves. Usábamos un software llamado vlftoolkit.
Eso puede ser muy interesante si por ejemplo se quieren localizar emisiones usando dos estaciones y mirando el tiempo de llegada de la señal.
Salida tipica de un ntp en linux. la columna offset es la diferencia horaria en ms.
ntpq -p
remote refid st t when poll reach delay offset jitter
=======================================================================================================
0.debian.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0001
1.debian.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0001
2.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0001
3.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0001
-ntp01.pingless.com 189.97.54.122 2 u 633 1024 377 33.2436 0.1329 0.7017
+ip195-20-235-143.pbiaas.com 193.147.107.33 2 u 734 1024 377 13.6480 -0.1951 1.2147
+tick.espanix.net .GNSS. 1 u 617 1024 377 10.9249 0.7268 0.5660
*tock.espanix.net .GNSS. 1 u 635 1024 377 11.0068 0.7345 0.3893
-gnss-ntp.ilimit.es .PPS. 1 u 570 1024 377 16.5428 -1.5018 0.2920
-any.time.nl 145.238.80.80 2 u 780 1024 377 6.7169 -0.5285 0.5330
+eixample.v6.rocks 195.95.153.59 2 u 704 1024 377 17.8940 0.2709 0.4890
-ip94-143-139-219.pbiaas.com 150.214.94.5 2 u 685 1024 377 13.4641 -1.3599 0.2635
Y la precisión que me esta dando ahora mismo un receptor de rayos de blitzortung.org que precisamente usa la salida de pps de un gps para marcar la hora de los datos recibidos. Del orden de nanosegundos.-
ANgazu
- Moderador Global
- Mensajes: 2362
- Registrado: 05 Nov 2014 21:02
- Agradecido : 160 veces
- Agradecimiento recibido: 1615 veces
Servidores NTP horarios.
Hola.
Muchas gracias por la explicación. Normalmente nadie se fija en estos pequeños errores.
En Linux es sencillo. En windows, cambiar el servidor NTP por otro es algo rollo, claro que para lo que lo usamos, es más que suficiente el de microsoft.
Hace años, cuando las tarjetas de sonido tenían errores de mas de 100 ppm, usábamos el PPS del GPS para medir el error y efectuar las correcciones adecuadas en las grabaciones. Ahora, tanto los SDR como las tajetas de sonido raramente se van más allá de 1 o 2 ppm, lo que es más que suficiente. Hay que tener en cuenta que un modem Stanag 4285 permite errores de +- 5ppm.
A pesar de los GNSS, aún hay muchos equipos que mantienen osciladores de alta tecnología. Un caso en uso son los transceptores de FHSS, que suelen usar el TOD para sincronizarse. Si lo interfieren, son capaces de mantener el sincronismo interno más de 20 dias, claro que esos equipos cuestan un pastizal y se salen de mi presupuesto.
Saludos.
ANgazu.
Muchas gracias por la explicación. Normalmente nadie se fija en estos pequeños errores.
En Linux es sencillo. En windows, cambiar el servidor NTP por otro es algo rollo, claro que para lo que lo usamos, es más que suficiente el de microsoft.
Hace años, cuando las tarjetas de sonido tenían errores de mas de 100 ppm, usábamos el PPS del GPS para medir el error y efectuar las correcciones adecuadas en las grabaciones. Ahora, tanto los SDR como las tajetas de sonido raramente se van más allá de 1 o 2 ppm, lo que es más que suficiente. Hay que tener en cuenta que un modem Stanag 4285 permite errores de +- 5ppm.
A pesar de los GNSS, aún hay muchos equipos que mantienen osciladores de alta tecnología. Un caso en uso son los transceptores de FHSS, que suelen usar el TOD para sincronizarse. Si lo interfieren, son capaces de mantener el sincronismo interno más de 20 dias, claro que esos equipos cuestan un pastizal y se salen de mi presupuesto.
Saludos.
ANgazu.
"Quod natura non dat, ..."
"8472"
"8472"