Serveur de temps NTP - DTS 4135

Serveur de temps NTP - DTS 4135

DTS 4135 est une référence de temps pour tous les clients NTP dans les réseaux moyens et grands (IPv4 / IPv6). Il est très précis et avec son concept intelligent pour un fonctionnement redondant, il offre un haut degré de fiabilité et de disponibilité.

Type d'oscillateur:TCXO (DTS 4135) / OCXO (DTS 4136)
1 port LAN (RJ45)/RPS :fournit NTP (< 3'000 requêtes/s)
Sorties :2x sortie DCF/impulsion/fréquence, 2x IRIG-B / AFNOR, 2x sortie série, 1x sortie boucle de courant DCF
Temps de haute précision:Réception de l'heure du GPS
Redondance:fonctionnement maître-esclave avec commutation automatique en cas d'erreur
Afficher plus
Configuration IPDHCP, IPv4 statique, IPv6
Source d'alimentationEntrée AC : 90 à 240 VAC / 50 - 60 Hz / 0.25 A, 2 entrées DC : 24 VDC +20 % / -10 % / 20 W
PrécisionGPS (entrée DCF) vers serveur NTP : typique < ± 100 µs / GPS (entrée DCF) vers DCF 77 / sortie impulsions : typique < ± 10 µs
OpérationTerminal série via RS 232 (face avant, sub-D 9p mâle) / Via LAN : MOBA-NMS, Telnet, SSH, SNMP
ChronométrageSynchronisé avec le GPS
Afficher plus

SNTP (Simple Network Time Protocol) et NTP (Network Time Protocol) décrivent exactement le même format de paquet réseau, les différences peuvent être trouvées dans la façon dont un système traite le contenu de ces paquets afin de synchroniser son heure. Il s'agit essentiellement de deux manières différentes de gérer la synchronisation de l'heure.

 

Alors qu'un serveur ou client NTP complet atteint un niveau de précision très élevé et évite autant que possible les horodatages brusques en utilisant différentes méthodes mathématiques et statistiques et des ajustements de vitesse d'horloge en douceur, SNTP ne peut être recommandé que pour les applications simples, où les exigences de précision et de fiabilité ne sont pas trop exigeantes.

 

En ignorant les valeurs de dérive et en utilisant des méthodes simplifiées de réglage de l'horloge système (souvent un simple pas de temps), SNTP n'obtient qu'une synchronisation temporelle de faible qualité par rapport à une implémentation NTP complète. SNTP version 4 est défini dans RFC2030, où il se lit :

 

« Il est fortement recommandé d'utiliser SNTP uniquement aux extrémités du sous-réseau de synchronisation. Les clients SNTP ne doivent fonctionner qu'aux extrémités (strate supérieure) du sous-réseau et dans des configurations où aucun client NTP ou SNTP ne dépend d'un autre client SNTP pour la synchronisation. Les serveurs SNTP ne doivent fonctionner qu'à la racine (strate 1) du sous-réseau et uniquement dans des configurations où aucune autre source de synchronisation autre qu'un service de temps radio ou modem fiable n'est disponible. Le degré complet de fiabilité normalement attendu des serveurs principaux n'est possible qu'en utilisant les sources redondantes, les divers chemins de sous-réseau et les algorithmes élaborés d'une implémentation NTP complète. »

 

Par conséquent, le terme « serveur de temps NTP » ou « client compatible NTP » peut – par définition – décrire un système avec un NTP entièrement mis en œuvre ainsi que tout autre produit qui utilise et comprend le protocole NTP mais atteint des niveaux de fiabilité, de précision et de Sécurité.

Si une connexion Internet fonctionne correctement, NTP peut déterminer et prendre en compte les retards de transmission de paquets de manière assez fiable. Cependant, si la connexion Internet est à sa limite de capacité, la synchronisation temporelle peut être considérablement dégradée en raison de la forte dispersion des délais de transmission des paquets. Les raisons peuvent être des attaques de pirates informatiques, qui ne doivent pas s'adresser à votre propre réseau, ou de nouveaux virus provoquant un énorme flot d'e-mails, comme cela s'est déjà produit dans le passé. Un propre serveur NTP ne peut pas être facilement compromis sur Internet.

Il existe deux manières de prendre en compte la seconde intercalaire dans votre propre système horaire informatique. La première solution (DTS4160, DTS4210) consiste à lire automatiquement la seconde intercalaire via le récepteur GPS et à l'implémenter par le serveur de temps dans l'horodatage NTP généré. L'automatisation de cet appareil repose sur le fait que les opérateurs de satellites GPS prennent généralement en compte la spécification IERS, ce qui est garanti par un préavis et la seconde intercalaire elle-même. Ce n'est qu'en s'appuyant sur ces deux composants que les récepteurs GPS et les serveurs de temps peuvent traiter la seconde intercalaire correctement et exactement au bon moment et l'implémenter en termes de technologie système.

Certains exploitants d'infrastructures critiques préfèrent en revanche la procédure manuelle, car il existe un certain risque résiduel en ce qui concerne la réception sécurisée des deux composants mentionnés ci-dessus et la seconde intercalaire doit généralement être suivie séparément pour d'autres systèmes informatiques. En outre, la définition des secondes intercalaires n'est pas une procédure standard, de sorte que cela peut également parler d'un processus conscient, puis manuel, de la part de l'utilisateur. Avec cette solution alternative de réglage manuel, vous pouvez effectuer un réglage correspondant en temps utile avec nos appareils DTS, par exemple via MOBA NMS ou Telnet SSH, le serveur de temps DTS traitant ensuite en toute sécurité la seconde intercalaire et l'implémentant en conséquence.

En général, ce délai est inférieur à 1 ms, lorsque le réseau et le nombre de requêtes client par seconde ne sont pas pris en compte.

Le délai du réseau peut varier considérablement en fonction de la charge de trafic. C'est pourquoi les paquets NTP contiennent deux horodatages (sortie de paquet et entrée de paquet). Ainsi, le temps de réponse peut être calculé et compensé.

 

Conclusion:

Pour le NTP standard, le délai réseau (temps de réponse) n'est pas pertinent pour la précision de la synchronisation client.

Sauf que lorsque le délai devrait être très élevé, alors l'accessibilité du serveur NTP pourrait être dégradée.