Servidor de hora NTP - DTS 4135

Servidor de hora NTP - DTS 4135

DTS 4135 es una referencia de tiempo para todos los clientes NTP en redes medianas y grandes (IPv4 / IPv6). Es muy preciso y, con su concepto inteligente de funcionamiento redundante, ofrece un alto grado de fiabilidad y disponibilidad.

Tipo de oscilador:TCXO (DTS 4135) / OCXO (DTS 4136)
1 puertos LAN (RJ45) / RPS:proporciona NTP (< 3 solicitudes/s)
Salidas:2x salida DCF/pulso/frecuencia, 2x IRIG-B / AFNOR, 2x salida serie, 1x salida de bucle de corriente DCF
Tiempo de alta precisión:Recepción de hora desde GPS
Redundancia:funcionamiento maestro-esclavo con conmutación automática en caso de error
Mostrar más
Configuración de IPDHCP, IPv4 estático, IPv6
Fuente de alimentaciónEntrada CA: 90 a 240 VCA / 50 - 60 Hz / 0.25 A, 2 x Entrada CC: 24 VCC +20 % / -10 % / 20 W
ExactitudGPS (entrada DCF) a servidor NTP: típico < ± 100 µs / GPS (entrada DCF) a DCF 77 / salida de pulsos: típico < ± 10 µs
OperaciónTerminal serie vía RS 232 (frontal, sub-D 9p macho) / Vía LAN: MOBA-NMS, Telnet, SSH, SNMP
cronometrajeSincronizado con GPS
Mostrar más

SNTP (Simple Network Time Protocol) y NTP (Network Time Protocol) describen exactamente el mismo formato de paquete de red, las diferencias se pueden encontrar en la forma en que un sistema maneja el contenido de estos paquetes para sincronizar su tiempo. Básicamente, son dos formas diferentes de cómo lidiar con la sincronización de tiempo.

 

Si bien un servidor o cliente NTP con todas las funciones alcanza un nivel muy alto de precisión y evita las marcas de tiempo abruptas tanto como sea posible mediante el uso de diferentes métodos matemáticos y estadísticos y ajustes suaves de la velocidad del reloj, SNTP solo puede ser recoModificado para aplicaciones simples, donde los requisitos de precisión y confiabilidad no son demasiado exigentes.

 

Al ignorar los valores de deriva y utilizar formas simplificadas de métodos de ajuste del reloj del sistema (a menudo, pasos de tiempo simples), SNTP solo logra una sincronización de tiempo de baja calidad en comparación con una implementación de NTP completa. La versión 4 de SNTP se define en RFC2030, donde dice:

 

“Es fuertemente recoSe recomendó que SNTP se utilice solo en los extremos de la subred de sincronización. Los clientes SNTP deben operar solo en las hojas (estrato más alto) de la subred y en configuraciones donde ningún cliente NTP o SNTP depende de otro cliente SNTP para la sincronización. Los servidores SNTP deben operar solo en la raíz (estrato 1) de la subred y luego solo en configuraciones en las que no haya otra fuente de sincronización disponible que no sea un servicio de tiempo de módem o radio confiable. El grado completo de confiabilidad que normalmente se espera de los servidores primarios solo es posible utilizando fuentes redundantes, diversas rutas de subred y algoritmos diseñados de una implementación completa de NTP ".

 

Por lo tanto, el término "servidor de tiempo NTP" o "cliente compatible con NTP" puede, por definición, describir un sistema con un NTP completamente implementado, así como cualquier otro producto que use y comprenda el protocolo NTP pero que alcance niveles mucho peores de confiabilidad, precisión y seguridad.

Si una conexión a Internet funciona correctamente, NTP puede determinar y contabilizar los retrasos en la transmisión de paquetes de forma bastante fiable. Sin embargo, si la conexión a Internet está en su límite de capacidad, la sincronización de tiempo puede degradarse significativamente debido a la alta dispersión en los retrasos en la transmisión de paquetes. Las razones de esto pueden ser ataques de piratas informáticos, que no deben dirigirse a su propia red, o nuevos virus que causan una gran cantidad de correos electrónicos, como ya sucedió en el pasado. Un servidor NTP propio no se puede comprometer fácilmente fuera de Internet.

Básicamente hay dos formas de dar el salto second en cuenta en su propio sistema de tiempo de TI. La primera solución (DTS4160, DTS4210) es que el salto second se lee automáticamente a través del receptor GPS y el servidor de tiempo puede implementar esto en la marca de tiempo NTP que se emite. El trasfondo del automatismo de este dispositivo es que los operadores de satélites GPS generalmente tienen en cuenta la especificación IERS en consecuencia, que está garantizada por aviso previo y los saltos reales.econd sí mismo. Solo sobre la base de ambos componentes, los receptores GPS y los servidores de tiempo pueden procesar los saltos.econd correctamente y exactamente en el momento adecuado y también implementarlo en términos de tecnología de sistemas.

Algunos operadores de infraestructuras críticas, en cambio, prefieren el procedimiento manual porque existe un cierto riesgo residual con respecto a la recepción segura tanto de los componentes antes mencionados como de los saltos.econd normalmente tiene que ser rastreado por separado para otros sistemas de TI de todos modos. Además, la definición de saltoseconds no es un procedimiento estándar, por lo que también puede hablar de un proceso consciente, luego manual, por parte del usuario. Con esta solución alternativa de configuración manual, puede realizar la configuración correspondiente a su debido tiempo con nuestros dispositivos DTS, por ejemplo, a través de MOBA NMS o Telnet SSH, por lo que el servidor de tiempo DTS procesa los saltos de manera segura.econd y lo implementa en consecuencia.

Normalmente es <1 ms, cuando la red y el número de solicitudes del cliente por second no se tiene en cuenta.

El retraso de la red puede diferir mucho, dependiendo de la carga de tráfico. Es por eso que los paquetes NTP contienen dos marcas de tiempo (salida y entrada de paquetes). Por tanto, el tiempo de respuesta se puede calcular y compensar.

 

Conclusión:

Para NTP estándar, el retardo de la red (tiempo de respuesta) no es relevante para la precisión de la sincronización del cliente.

Excepto, cuando la demora debería ser muy alta, la accesibilidad del servidor NTP podría degradarse.