Pour synchroniser des horloges à travers un réseau local (LAN), il est important d’être capable de mesurer le délai de transmission induit par les facteurs techniques et d’usages du réseau.
Lorsqu’une machine reçoit un message avec un horodatage en provenance d’une horloge maître, un délai est introduit par la distance à cette horloge. En effet, si un message parcourt un mètre de fibre optique ou, au contraire, traverse plusieurs datacenters différents, la durée de transmission peut varier et introduire un délai variable. Connaître cette latence est donc nécessaire pour synchroniser correctement son horloge.
Quelles sont les sources de la latence dans PTP ?
Les facteurs qui viennent influencer la latence sur un réseau sont nombreux. Ci-dessous les principaux :
- Le réseau physique. La latence introduite par ce facteur est statique et maitrisable puisqu’elle ne dépend uniquement que des caractéristiques du matériel.
- Le nombre de routeurs/switchs traversés par le message.
- Le trafic du réseau. En effet un paquet réseau peut être bloqué dans un routeur ou un switch à cause d’un trafic très important et des règles de QoS (Quality Of Service) mises en place. Ce phénomène n’est pas fréquent mais peut induire une très forte latence.
Latence symétrique ou asymétrique ?
La latence peut être symétrique ou asymétrique. Dans le cas asymétrique, il est plus difficile d’obtenir la précision maximale. Le protocole PTP (Precision Time Protocol) est réputé comme étant l’un des protocoles les plus précis. Il embarque un mécanisme pour calculer le délai et ainsi ajuster son horloge lors d’une synchronisation. Il est également équipé d’un champ spécifique (le correction field) qui permet au protocole d’être robuste aux latences asymétriques.
Calcul de la latence dans PTP ou comment ajuster la latence des serveurs récepteurs ?
Le mécanisme de calcul de la latence de PTP utilise les messages SYNC, FOLLOW_UP, DELAY_REQ et DELAY_RESP.
Le serveur qui souhaite synchroniser les horloges de ses clients envoie un message SYNC pour démarrer la synchronisation. Le message est envoyé à l’horodatage t1. Le client reçoit le message au temps t2. Si le serveur n’a pas la capacité d’envoyer le timestamp t1 directement dans le message SYNC, il envoie aussitôt après un message FOLLOW_UP avec l’horodatage t1 pour que le client soit au courant.
Le client envoie alors un message DELAY_REQ au serveur au temps t3. Ce message sera reçu par le serveur au temps t4. Ce dernier renvoie le message DELAY_RESP au client au temps t4’.
Le client peut alors calculer le délai d’un aller-retour entre lui et le serveur et se servir de ce délai pour ajuster son horloge lors de la synchronisation.
Cet échange de messages est représenté dans la figure 1 - Mécanisme de calcul du délai dans PTP.
A droite du récepteur (Slave Clock) on peut voir les horodatages que connaît le récepteur après chaque réception/envoi de message.
Avec ces 4 horodatages le récepteur est en mesure de calculer le délai de transmission entre lui et le serveur générateur (Master Clock) et d’utiliser ce calcul pour corriger le délai.
Pour cela, il va calculer un décalage (offset) qu’il appliquera à son horloge. Ce décalage vaut ½ (t2 – t1 – t4 + t3). Le calcul est juste si le délai est symétrique.
Les applications dans une infrastructure réseau PTP
Parfois le délai n’est pas symétrique. On retrouve ce cas lorsque les échanges entre le serveur et le client PTP passent par plusieurs routeurs ou switchs non compatibles PTP. Chaque équipement analyse le paquet pour le propager dans le réseau. Ce temps de traitement entraîne un délai supplémentaire qui n’est pas identique pour chaque paquet.
Dans le cas d’une infrastructure réseau PTP, deux périphériques clés permettent de distribuer le temps aux différents équipements en garantissant la précision de synchronisation :
- Le Boundary Clock (BC). Cet appareil agit comme une référence de temps pour les dispositifs récepteurs, il permet de générer lui-même les paquets de synchronisation.
- Le Transparent Clock (TC). Cet appareil mesure le temps nécessaire pour qu’un paquet traverse le réseau. Le TC ajoute alors ce temps de propagation dans le champ de correction (correction field). Le client connaît alors la partie du délai dynamique imputable aux temps de traitement des messages et peut la prendre en compte pour synchroniser son horloge à celle du serveur
Dans une infrastructure réseau PTP, chaque composant joue un rôle crucial, il est donc impératif de préparer et définir minutieusement l’architecture pour assurer une synchronisation temporelle fiable et cohérente sur l’ensemble du réseau.
Avec plus de 150 ans d’expertise en gestion des temps et présent dans plus de 140 pays, Bodet Time est un acteur français majeur de la synchronisation temporelle et du temps fréquence. Nos serveurs de temps PTP Netsilon permettent de synchroniser de façon sécurisée l’ensemble des équipements présents sur un réseau.
