Solution d'horloge financière PTP - T830 permet une mise à niveau NTP en douceur jusqu'à de faibles microsecondes

Serveur d'horloge T830 Solution d'avant-vente PTP pour l'industrie financière

Solution de temps unifié T830 pour l'industrie financière : passage en douceur de NTP à PTP (IEEE 1588)

Modification minimale pour atteindre les microsecondes puis les sous-microsecondes/centaines de nanosecondes afin de répondre à la traçabilité et à l'auditabilité des transactions ---- Solution d'horloge pour l'industrie financière

Dans un réseau de production financière, le temps n'est pas "aussi proche que possible", mais "doit être cohérent et traçable". Lorsqu'on s'appuie uniquement sur NTP, la gigue des files d'attente, l'asymétrie des chemins à travers les trois couches et la congestion peuvent amplifier les écarts et les risques à l'échelle de la milliseconde et de la microseconde. Le PTP transforme les erreurs de source à extrémité, qui sont des fluctuations incontrôlables, en erreurs budgétisables, attribuables et gérables grâce à des horodatages matériels sur la puce NIC/commutateur, des horloges de frontière/transparentes et (en option) SyncE. Le protocole PTP transforme les erreurs "source-réseau" de fluctuations incontrôlables en quantités de travail budgétisables, attribuables et vérifiables grâce à des horodatages matériels sur la puce NIC/commutateur et (en option) SyncE. Avec le T830 comme noyau, sans interrompre le NTP du réseau existant, les liens critiques sont stabilisés à un niveau inférieur à la microseconde et resserrés à un niveau inférieur à la microseconde/centaine de nanosecondes dans les segments centraux contrôlés afin de maximiser la vérifiabilité et la certitude de conformité en échange d'une modification minimale.

Points douloureux et plafonds réalistes du PNT :Les opérations de résumé/stratégie ont une tolérance zéro pour les "ordres séquentiels", mais les horodatages logiciels de NTP et l'asymétrie des chemins rendent difficile la limitation des pics occasionnels ; la diffusion/lecture du marché exige une reproduction intersystème stricte, mais la gigue et le risque de queue de NTP augmentent les coûts de vérification ; le contrôle des ordres/risques repose sur une synchronisation étroite, mais la dérive interdomaine de NTP est susceptible de déclencher des erreurs d'appréciation et des retours en arrière ; la compensation/l'audit exige un "endossement horodaté", mais NTP ne dispose pas de corrections au niveau du matériel pour chaque saut et d'une chaîne de traçabilité UTC complète. Pour la compensation et l'audit, NTP ne dispose pas des corrections au niveau du matériel et d'une chaîne de traçabilité UTC complète pour chaque saut, alors que le règlement et l'audit nécessitent un "endossement horodaté". Par conséquent, NTP est adapté à la "disponibilité de base", mais présente une limite supérieure naturelle en ce qui concerne la cohérence du niveau financier et l'auditabilité.

Pourquoi le protocole PTP doit-il être mis en place ?Le protocole PTP élimine la gigue de la pile hôte grâce aux horodatages matériels, corrige les retards de résidence avec T-BC/T-TC et unifie les fréquences du réseau avec SyncE ; il donne la priorité à One-Step dans les segments contrôlés pour réduire la gigue, et à Two-Step dans les segments restreints pour assurer la compatibilité.

Réflexion sur la transition

principe généralCoexistence de la priorité PTP et du NTP : dans l'optique d'une modification minimale du réseau existant, le T830 fournit simultanément le PTP et le NTP, et peut être commuté en douceur à n'importe quel stade.
Règles de sélection(une phrase à retenir) : ceux qui prennent en charge L2 vont vers L2 ; ceux qui ne prennent pas en charge L2 mais qui prennent en charge PTP vont vers UDPv4 ; ceux qui ne prennent en charge que NTP continuent à aller vers NTP.

Option 1 (coexistence de protocoles mixtes) :

T830 Sortie parallèle de PTP et NTP : les clients qui supportent L2 vont directement à L2 pour une gigue plus faible ; les clients qui supportent PTP mais pas L2 vont à UDPv4 (G.8275.2) pour traverser la couche 3 et les domaines de politique ; les dispositifs de stock qui supportent seulement NTP continuent à utiliser NTP. Le côté réseau est légèrement isolé par le numéro de domaine/priorité + VLAN avec des liaisons montantes à faible perturbation et un "resserrement de l'alignement" à l'échelle du réseau. "Aligner d'abord et resserrer ensuite.

Option 2 (Intra-Domain L2 High Accuracy + Inter-Domain UDPv4 Flexible Interconnect) :

L2 (G.8275.1 + SyncE) est adopté pour le segment central de l'agrégation/citations, T-BC est activé pour le segment central/l'agrégation, T-TC est activé pour l'accès, et la priorité est donnée à l'étape unique (si l'étape unique n'est pas prise en charge, on utilise alors l'étape double) ; les segments inter-salles de serveurs/trois niveaux ou hétérogènes sont unifiés avec l'articulation UDPv4 (G.8275.2) pour former un objectif de stabilité "sub-microseconde/cent nanoseconde intra-domaine, faible microseconde inter-domaine" ; les deux programmes peuvent être promus en parallèle : d'abord, l'ensemble du réseau "tourne", et "faible microseconde" entre les domaines. L'objectif de stabilité "sub-microseconde/centaine de nanosecondes à l'intérieur du domaine et faible microseconde entre les domaines" ; les deux programmes peuvent être promus en parallèle : d'abord, laisser l'ensemble du réseau "fonctionner et avoir raison", puis "tirer le chemin critique au maximum et être plus précis". ".

Stratégie d'architecture (L2 vs UDPv4, One-Step vs Two-Step)

Compromis entre L2 et UDPv4 : les campus/co-locations contrôlés donnent la priorité à L2 (G.8275.1 + SyncE) pour une gigue et une symétrie optimales ; les couches 3/interdomaines utilisent UDPv4 (G.8275.2) pour la traversée des itinéraires et des domaines de sécurité.

Le compromis entre One-Step et Two-Step : One-Step est utilisé pour supporter One-Step ; Two-Step est utilisé si One-Step n'est pas supporté ; One-Step complète l'alignement dans une seule trame et a une gigue plus faible, mais a des exigences matérielles ; Two-Step est couplé avec deux trames et a une meilleure compatibilité. À l'heure actuelle, les entreprises sont principalement configurées avec Two-Step.

Extension du campus/des salles informatiques multiples (plusieurs × T830) : plusieurs T830 dans chaque salle informatique en sélectionnent un comme T-GM de domaine, les segments centraux intra-domaine utilisent L2 (G.8275.1 + SyncE), inter-domaines utilisent UDPv4 (prend en charge la configuration prioritaire L2) ; le nombre de domaines/la planification prioritaire de la reprise après sinistre multi-sources est conforme à l'état stable, et l'écart du système global peut atteindre l'objectif de "nanosecondes de transaction + microsecondes d'enregistrement + millisecondes de bureau". Objectif "nanoseconde de transaction + microseconde de journalisation + milliseconde de bureau". Les objectifs sont atteints grâce à une hiérarchisation en fonction de l'importance de l'activité.

Dans le cadre de l'agrégation à haute fréquence et de l'échange de stratégies à faible latence, l'horodatage unifié UTC réduit considérablement les litiges sur la question de savoir "qui était le premier et qui était le dernier" ; dans le cadre de la diffusion et de la rediffusion du marché, la chronologie intersystème est strictement alignée, ce qui permet de reproduire et d'expliquer les rediffusions anormales ; dans le cadre des scénarios d'ordonnancement et de contrôle des risques, l'horodatage cohérent réduit le coût des erreurs d'appréciation et des retours en arrière ; dans le cadre de la compensation et de l'audit, la chaîne de traçabilité "GNSS/PRTC→TGM→réseau (BC/TC)→hôte (T-TSC)" permet à chaque horodatage d'avoir sa provenance et de faire l'objet d'une sauvegarde. La chaîne de traçabilité "GNSS/PRTC→T-GM→Réseau (BC/TC)→Hôte (T-TSC)" permet à chaque horodatage d'avoir une provenance et un aval.

Pourquoi le serveur d'horloge T830 ?

Tout d'abord, du côté de la source de temps, le serveur d'horloge T830 peut être mis à niveau de PRTC-A à PRTC-B sur demande, et réserver de l'espace pour l'évolution ePRTC afin d'étendre la conservation du temps dans les scénarios perturbés par le GNSS ; du côté du réseau, le serveur d'horloge T830 prend en charge L2 et UDPv4 deux types d'images PTP en même temps, ce qui convient naturellement au scénario hybride "L2 pour ceux qui prennent en charge L2, UDPv4 pour ceux qui ne le prennent pas en charge ; NTP pour ceux qui ne prennent pas en charge PTP" que vous avez proposé, et avec T-BC/T-TC, SyncE, One-Step/Two-Step. Le serveur d'horloge T830 prend en charge les images PTP L2 et UDPv4, ce qui convient naturellement au scénario mixte "L2 pour ceux qui supportent L2 et UDPv4 pour ceux qui ne le supportent pas ; NTP pour ceux qui ne supportent pas PTP" que vous avez proposé, et coopère naturellement avec T-BC/T-TC, SyncE et One-Step/Two-Step ; du côté du terminal, en plus du parallélisme PTP/NTP, le serveur d'horloge T830 fournit des références physiques telles que 1PPS/ToD/10 MHz, ce qui est pratique pour l'étalonnage et l'échantillonnage en laboratoire. Outre le parallélisme PTP/NTP, le serveur d'horloge T830 fournit également des références physiques telles que 1PPS/ToD/10 MHz du côté du terminal, ce qui est pratique pour l'étalonnage et l'échantillonnage en laboratoire, et prépare des "justificatifs" pour les preuves de conformité. De plus, la méthode de livraison progressive du serveur d'horloge T830 "un pour commencer, deux pour la haute disponibilité et plusieurs pour l'échelle" vous permet d'obtenir des avantages visibles dans les domaines critiques avec des coûts de transformation de l'inventaire minimes, puis de mettre à niveau le chemin principal vers des indicateurs de niveau inférieur à la microseconde/centre de nanoseconde sans reconfigurer l'ensemble du réseau en une seule fois.

Alignement de la valeur financière de l'entreprise

Stratégie d'agrégation à haute fréquence/faible latence : les horodatages UTC unifiés réduisent considérablement les conflits "qui est le premier, qui est le dernier", et le segment central L2/One-Step + BC/TC réduit la gigue à des niveaux inférieurs à la microseconde.

Validation/reprise des citations : les calendriers intersystèmes sont strictement alignés et les reprises anormales sont reproductibles et interprétables.

Contrôle des commandes et des risques : un calendrier cohérent réduit le coût des faux positifs et des retours en arrière.

Règlement et audit : La chaîne "GNSS/PRTC→T-GM→Réseau (BC/TC)→Hôte (T-TSC)" constitue une chaîne de traçabilité UTC complète, de sorte que chaque horodatage "a une provenance, peut être endossé et peut être réexaminé".

Réponses rapides aux questions fréquemment posées

L'horloge principale est à deux étages en amont, pourquoi le segment central est-il toujours à un étage ?

La personne qui envoie la synchronisation définit le type ; la retransmission d'une étape à la T-BC entrant dans la section centrale est suffisante ; la T-TC ne modifie pas le type d'étape.

Pourquoi pas une L2 complète ?

La traversée, le coût et la maintenabilité à travers la couche 3 et les domaines de sécurité dictent que l'inter-domaine est mieux adapté à l'UDPv4 ; "extrême dans le domaine, livrable dans l'inter-domaine" est la solution d'ingénierie optimale.

Qu'en est-il des appareils qui ne prennent pas en charge le protocole PTP ?

T830 sortie parallèle NTP, compatible avec le stock ; les appareils compatibles PTP passent en L2 ou UDPv4 selon la capacité à synchroniser les trois types de terminaux en une seule étape.