Serveur de temps NTP - DTS 4132

Serveur de temps NTP - DTS 4132

L’appareil polyvalent DTS 4132 est une horloge-mère de réseau et une référence temporelle pour les clients NTP dans les réseaux de moyenne et grande taille avec jusqu’à 2 ports réseau (IPV4/IPV6). Grâce à sa haute précision et à son concept intelligent de fonctionnement redondant, il offre un haut degré de fiabilité et de disponibilité. En outre, il fournit MOBALIne pour les horloges esclaves à réglage automatique.

Type d'oscillateur :TCXO
2 Port LAN (RJ45) / RPS :fournit NTP sur les deux ports (<1'500 requêtes/s sur les deux ports combinés)
Sorties :2x sortie DCF/impulsion/fréquence, 2x sortie série, 1x sortie boucle de courant DCF
Heure 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, statique IPv4, IPv6
Alimentation électriqueAlimentation redondante (secteur/DC ou DC/DC)
PrécisionGPS (entrée DCF) vers serveur NTP : typique < ± 100 µs / GPS (entrée DCF) vers DCF / sortie d'impulsion : typique < ± 10 µs
FonctionnementTerminal série via RS 232 (face avant, sub-D 9p mâle) / Via LAN : MOBA-NMS, Telnet, SSH, SNMP
Le 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 se situant dans la manière dont un système traite le contenu de ces paquets afin de synchroniser son temps. Il s’agit en fait de deux façons différentes de gérer la synchronisation du temps.

 

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

 

En ne tenant pas compte des valeurs de dérive et en utilisant des méthodes simplifiées d’ajustement de l’horloge système (souvent un simple pas de temps), SNTP ne permet d’obtenir qu’une synchronisation temporelle de faible qualité par rapport à une mise en œuvre complète du protocole NTP. La version 4 de SNTP est définie dans le document RFC2030, où l’on peut lire ce qui suit :

 

« Il est fortement recommandé de n’utiliser SNTP qu’aux extrémités du sous-réseau de synchronisation. Les clients SNTP ne doivent fonctionner qu’aux feuilles (strate la plus élevée) 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 les configurations où il n’existe pas d’autre source de synchronisation qu’un service horaire fiable par radio ou modem. Le degré de fiabilité habituellement attendu des serveurs primaires 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, les termes « serveur de temps NTP » ou « client compatible NTP » peuvent – par définition – décrire un système doté d’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é bien inférieurs.

Si une connexion internet fonctionne correctement, NTP peut déterminer et prendre en compte les délais de transmission des paquets de manière assez fiable. Toutefois, si la connexion internet est à la limite de sa capacité, la synchronisation du temps peut être considérablement dégradée en raison de la forte dispersion des délais de transmission des paquets. Cela peut s’expliquer par des attaques de pirates informatiques, qui ne doivent pas viser votre propre réseau, ou par de nouveaux virus provoquant une avalanche de courriels, comme cela s’est déjà produit par le passé. Un serveur NTP propre ne peut pas être facilement compromis en dehors de l’internet.

Il y a essentiellement deux façons de prendre en compte la seconde intercalaire dans votre propre système de temps informatique. La première solution (DTS4160, DTS4210) consiste à lire automatiquement la seconde intercalaire via le récepteur GPS et le serveur de temps peut l’intégrer dans l’horodatage NTP émis. Cet automatisme s’explique par le fait que les opérateurs de satellites GPS tiennent généralement compte de la spécification IERS, qui est garantie par un préavis et par la seconde intercalaire elle-même. Ce n’est que sur la base de ces deux éléments que les récepteurs GPS et les serveurs de temps peuvent traiter la seconde intercalaire correctement et exactement au bon moment, et la mettre en œuvre en termes de technologie du système.

Certains exploitants d’infrastructures critiques préfèrent quant à eux la procédure manuelle parce qu’il existe un certain risque résiduel en ce qui concerne la réception sécurisée des deux éléments susmentionnés et que 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 qu’elle peut également témoigner 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 alors en toute sécurité la seconde intercalaire et l’appliquant en conséquence.

Généralement, elle est de < 1ms, lorsque le réseau et le nombre de demandes de clients par seconde ne sont pas pris en considération.

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 du paquet et entrée du paquet). Le temps de réponse peut ainsi être calculé et compensé.

 

Conclusion :

Pour le NTP standard, le retard du réseau (temps de réponse) n’a pas d’incidence sur la précision de la synchronisation du client.

Toutefois, lorsque le délai est très élevé, la joignabilité du serveur NTP peut être compromise.