 Bonjour, bienvenue à ce talk. Aujourd'hui, je vais parler du protocole de précision, de ptp, et de paquet de timestamping en Linux. Premièrement, une introduction sur ce que ce talk va se couvrir. Donc, aujourd'hui, l'un des goals est de comprendre ce que est le protocole de précision, de ptp, et ce sont les modes d'opération. Nous voulons voir un point de vue très high-level de ce que ptp est. Nous ne voulons pas mourir dans beaucoup de détails, mais nous voulons savoir comment ptp fonctionne. Donc, ce sera plus tard, et on va pouvoir ajouter pour ça, dans le kernel Linux, par ajouter des aspects dans le devise-driver, mais nous allons le couvrir. Nous voulons aussi avoir une première glance à ce que ce ptp est, de paquet de timestamping, et de ceux qui pourraient être soutenus dans le kernel. La plus importante, c'est ceux qui pourraient être soutenus dans le devise-driver hardware. Un discrétage de cela, c'est qu'on ne va pas couvrir tout sur le paquet de timestamping, parce que ce futur peut être utilisé pour des applications de valeur, et pas seulement pour ptp, mais dans ce talk, on ne va pas couvrir tout en regard de ptp. Nous allons essayer de comprendre pourquoi ptp est important en utilisant ptp, et pourquoi ce sera bénéficiaire. Finalement, nous allons voir comment soutenir ptp sur les features floating, including ptp hardware timestamping, et ptp hardware clocks in devise-drivers, lorsqu'il y a un driver qui sera responsable pour les engines de hardware qui peuvent soutenir ptp hardware timestamping, et qui a un ptp hardware clock. Nous allons commencer avec une petite information de background, pour comprendre pourquoi nous avons besoin de ptp, où ptp sera utilisé, et ensuite nous allons couvrir ce que c'est ptp. Nous allons avoir un premier overview de ce qu'est le protocole de temps de procédure. Nous allons ensuite bouger à ptp, voir ce que c'est ptp, pourquoi ce sera important pour ptp, et ensuite nous allons voir ce que la feature floating peut être faite en regard de ptp en Linux. Finalement, nous allons avoir quelques slides sur l'implementation de ptp, pour qu'on puisse avoir un exemple de ce genre d'application, pour qu'on puisse utiliser tous ces ptp de feature floating dans le kernel, et pour qu'on puisse avoir un exemple de ce qu'il peut être fait pour utiliser ptp au Linux. Alors, premièrement, un petit background sur pourquoi nous avons besoin de ptp. L'un des choses qui sont importantes en travaillant avec des machines multiples, c'est l'application d'application. Il y a plusieurs casques où vous voulez savoir ce que l'application s'est annoncé avant d'une autre, vous voulez savoir ce que l'application s'est annulée entre des items, des logs, des logs distributifs, des logs distributifs qui arrivent des machines variables, et vous voulez aussi avoir une ordonnance à l'application, quand vous débuggez des choses, quand vous faites des analyses de performance, donc vous devez savoir ce que l'application s'est annulée entre des items. Et pour beaucoup de casques, cette ordonnance sera basée sur un timestamp. Un timestamp sera généré avec un clac et le clac sera sur la machine locale. Quand vous utilisez une grande range de machines, chaque machine va avoir sa propre clac et nous allons utiliser ce clac pour assurer un timestamp. Tout ce timestamp sera utilisé pour comprendre ce qui sera l'ordre de ce qui se passe. Donc, quand nous avons ce genre de casques, de besoins, nous devons avoir une synchronisation de clac parce que nous avons besoin de tous les clac pour être synchronisés afin d'être capable d'entraîner l'application. Donc, nous devons synchroniser les fréquences, la phase et le temps de tous ces clac. Nous ne voulons pas faire cela manuellement. Il serait possible de le faire avec une grande précision, et cela serait un travail utile. Donc, nous avons accès aux protocoles pour faire cela. Un très bon protocole pour synchroniser les clac et pour synchroniser le temps à travers les machines est le protocole NTP. Si vous utilisez un système de linux, cela va probablement être en train de fonctionner. Cela peut être utilisé pour synchroniser le clac local contre des machines remotes, que ce soit sur l'internet. Cela fonctionne correctement, mais cela donnera seulement l'accuracité dans quelques millisecondes, dans le bon cas, quand vous utilisez un client NTP et des services NTP dans la même networks locales. Cela ne pourrait pas être précisément enough pour l'application, car vous pouvez avoir plusieurs événements dans les mêmes millisecondes. Et si cela se passe, si vous avez plusieurs événements dans les mêmes millisecondes, vous n'avez aucune idée et vous ne pouvez vraiment pas savoir ce qui était le premier à s'occuper. Vous n'aurez pas d'événements entre tous ces événements. Il y a donc besoin d'accuracité. C'est là où NTP s'occupe. Alors, nous allons voir un overview de ce qui sera NTP, afin d'en savoir le protocole, ce que l'on offre, afin d'avoir un point de vue de ce qui sera en train de fonctionner. NTP est aussi un protocole, un protocole pour la synchronisation, mais cette fois, c'est fait à l'accuracité des sub-millisecondes sur les réseaux locaux. Ça veut dire que l'accuracité sera beaucoup mieux que NTP et c'est pourquoi PTP peut être utilisé pour des valeurs de l'application quand l'application s'occupe sur plusieurs machines. Ce protocole est standardisé par l'I3E et c'est standardisé par 3 publications. Donc, si vous voulez le savoir en plus, vous comprenez comment PTP s'occupe. Vous pouvez voir ces 3 publications et vous devrez avoir tout à l'heure. PTP va travailler dans une architecture pyramide où vous aurez leaders et followers de la distribution. Donc, nous avons 3 possibilités. Vous pouvez avoir un leader qui s'appelle Grand Master dans le protocole. Vous pouvez avoir un clac bondarié. On verra ce qu'est un clac bondarié et où il peut être utilisé. Finalement, vous devrez avoir beaucoup de followers, qui s'occupe dans le standard. Le clac de follower sera synchronisé contre le leader. PTP est un protocole network. Il peut être transmis sur un varié de protocoles. Il peut être transmis sur Ethernet. Vous pouvez aussi utiliser UDP. Quand vous utilisez UDP, vous pouvez utiliser IPv4, IPv6. Vous pouvez aussi utiliser IPv4, IPv6. Vous pouvez aussi utiliser IPv4, IPv6. Vous pouvez aussi utiliser IPv4, IPv6. Vous pouvez aussi utiliser IPv4, IPv6. Vous pouvez utiliser la multicoste. Vous pouvez utiliser l'adresse unicast. Vous pouvez avoir plusieurs choix selon vos besoins. Bien sûr, selon la publication utilisée comme référence quand vous implementez le protocole. Ce n'est pas que tous ces modes soient disponibles. Alors, let's have a look at what a PTP network can look like. Vous avez un cloc leader. Le cloc leader sera la source de temps pour la PTP network. Il sera utilisé pour synchroniser tous les autres clocs. Il sera l'official cloc utilisé comme source de temps. C'est généralement synchronisé contre d'autres clocs externes en utilisant le GNSS ou d'autres mécanismes pour avoir un source external pour synchroniser le cloc. Et ce cloc leader est appelé un cloc ordinaire parce qu'il a une connexion de PTP network. Nous verrons qu'il y a un autre exemple d'un cloc ordinaire, mais le cloc leader est un cloc ordinaire parce qu'il aura une connexion de PTP network. Puis on peut avoir des clocs bondaires. Ces clocs sont optionnels. Donc, vous n'avez pas besoin d'avoir un cloc bondaire sur votre réseau. Il dépend d'où le réseau est un cloc qui va avoir plusieurs connexions de PTP network et il sera utilisé pour synchroniser le cloc contre le leader et acter comme source de clocs pour les suivants. C'est donc un cloc entre les networks pour que vous puissiez avoir un leader pour parler aux suivants qui ne sera pas directement accessible sur le réseau. Donc, le cloc leader va disparaître. Le cloc bondaire va devenir le next leader. C'est le cas. Finalement, nous avons les clocs des suivants. Les clocs suivants seront tous les éléments dans le réseau dans les networks PTP qui veulent être synchronisés pour être synchronisés contre le leader. Ce cloc ou contre le leader selon l'architecture du réseau. Si le leader disparaît ils pourraient aussi devenir le nouveau leader. Donc, maintenant, nous allons voir où les protocoles de PTP travaillent quand deux entités dans le réseau PTP vont être synchronisés. Le cloc pour obtenir un état entre le leader et les suivants pour que les suivants puissent ajuster leur cloc local afin d'améliorer le cloc du leader. Et pour faire ça, nous devons savoir quel est le delta entre les deux clocs. Toutes ces computations seront réalisées par tous les suivants. Donc, le leader ne fera pas la computation en regard à cette computation delta. Le leader va envoyer des clocs. Et ce que nous voulons savoir c'est ce qui sera le temps. Donc, nous voulons compter quand ces clocs vont rester sur le côté leader et nous voulons compter quand ces clocs vont arriver sur le côté suivant. Et donc, c'est terminé avec les clocs. Donc, en faisant ça, nous voulons avoir des clocs. Ce sera le temps quand la cloc de leader et puis le temps quand la cloc de leader arrive sur le côté suivant. Mais en faisant ça, nous ne voulons pas envoyer les clocs dans la cloc de leader parce que quand la cloc de leader est en place, la cloc de leader ne pourrait être inclus dans la cloc de leader. Donc, le leader va rétablir la cloc de leader dans la cloc de leader et cette cloc de leader va être inclus dans la cloc de leader. Puis, nous allons avoir un autre échange qui sera fait. C'est la cloc de leader quand la cloc de leader est envoyée à la cloc de leader. Donc, nous voulons compter une cloc de leader qui sera un autre temps et une cloc de leader qui sera la cloc de leader et une cloc de leader qui sera la cloc de leader. Et puis, nous devons retrouver les clocs en place pour que nous ayons une réponse de délai qui sera axée à la cloc de leader incluant le cloc de leader entre les clocs de leader et le cloc de leader. Donc, nous voulons procurer de la cloc de leader le temps entre le leader et le suivant, et les deux temps de tristesse sont T1-T0 et T3-T2, mais le temps de tristesse va aussi inclure le delta entre les deux clés, parce que comme nous savons, PTP sera utilisé pour synchroniser les clés, donc nous pouvons avoir clés non synchronisés complètement entre le leader et le suivant. Et ça veut dire que le temps de tristesse va inclure ce délai. Donc nous allons avoir le temps de tristesse entre le leader et le suivant, ce qui sera DLF, ça sera equal à T1-T0 plus le delta entre les deux clés. Et puis, dans la même manière, nous allons avoir le temps de tristesse entre le suivant et le leader, DFL, ce qui sera equal à T3-T2, aussi incluant le delta entre les deux clés. Ici, nous allons imaginer que les deux clés de tristesse seraient equal. Donc je sais, et nous savons que ce n'est pas... ce n'est pas entièrement vrai, mais dans la nettoire locale, nous ne devons plus avoir trop de délai pour notre computation, et c'est pourquoi nous faisons ça. Et donc si nous imaginons que les deux clés de tristesse soient equal, nous avons DLF qui est equal à DFL, et nous pouvons savoir ce que sera la delta entre les deux clés. Et la delta sera T1-T0 plus 2-T3 divided par 2. Et grâce à cette delta, l'implementation de la PTP sera capable d'utiliser un certain algorithme, un certain nombre qui sera appelé des filtres, pour savoir quel sort d'adjustement devrait être fait sur le clé local. Donc, est-ce que la fréquence sera plus basée, est-ce que nous devrions mettre le temps, est-ce que nous devrions ajuster la phase ? Beaucoup de choses peuvent arriver, et cela dépendra de toutes les computations locales. Mais l'aspect qui sera utilisé, l'élément qui sera utilisé pour cette computation sera la delta entre les deux clés. Ce que nous avons vu était un exemple que la PTP est en train de travailler dans un mode 2-step, ce qui est le mode défaut, en envoyant deux paquets. Mais vous pouvez aussi avoir un mode 1-step qui peut être soutenu. Donc, le mode 1-step va différer du mode 2-step par l'inclusion de T0 dans les paquets de sync. Donc, si vous vous rappelez, nous avons eu ce paquet de sync envoyé par le leader à la suivante et parce que nous ne pouvons pas impliquer T0 dans le paquet de sync, nous devrions envoyer après le paquet de sync dans un paquet de follow-up, incluant T0. Mais, en ayant le support de l'air hardware, nous pouvons issuer un timestamp quand un paquet sera envoyé à l'autre côté, quand un paquet sera envoyé par le leader à la suivante, et le paquet d'air hardware sera capable de aussi impliquer directement T0 dans ce paquet. Quand nous faisons cela, nous serons utilisant le mode 1-step de PTP. Donc, la seule différence sera dans le côté leader, c'est-à-dire que vous avez besoin de support de l'air hardware pour cela, si vous voulez utiliser le mode 1-step comme leader dans une network PTP, mais comme follower, vous n'aurez pas besoin de ça. La seule chose que vous avez besoin de est d'extracter T0 du paquet de sync, mais c'est seulement un décision de software. Donc, selon la machine, vous allez utiliser, selon les engines de hardware qui seront disponibles sur cette machine, vous pourrez pouvoir sélectionner le mode 1-step selon ce qui est disponible. Donc, nous avons vu que le paquet de timestamping a un rôle très important quand en utilisant PTP, parce que le timestamp sera utilisé pour compter ce qui sera le delta entre la clé de follower et le clé du leader. Et ce delta sera utilisé pour correcter toutes les clés dans la network PTP. Donc, nous verrons quelques choses sur le paquet de timestamping. L'une des choses quand en utilisant le paquet de timestamping pour PTP et aussi pour d'autres outils mais en regardant le PTP, c'est que le timestamp doit être accuré. Il joue un rôle critique dans le temps de la computation et si le timestamp n'est pas accuré, vous pourrez introduire des délais, des extra-délays, vous pouvez introduire des erreurs dans la computation et ce ne sera pas une bonne chose quand en utilisant PTP parce que le clé de ajustement ne sera pas exactement ce que vous espérez. Donc, idéalement, on aurait aimé un timestamp qui serait issu à l'exacte temps de transmission quand le paquet sera livré de l'application. Mais ce n'est pas possible dans le monde réel parce que le timestamp doit être accuré. Nous ne pouvons pas mettre un paquet de timestamp quand il arrivera à la layer link sur le medium. Donc, nous devons le faire avant. Et pour faire ça, nous avons deux possibilités. L'une serait de le faire dans le software et l'autre serait de le faire dans le hardware. Et donc, nous verrons ce qui est le différence entre les deux et pourquoi d'habitude on préfère de le faire dans le hardware. Quand on utilise le ptp. Donc, le timestamp peut être fait dans l'application en-dessous ou dans le kernel. Quand on utilise le ptp, nous ferons le timestamp dans le kernel parce que ce sera plus précis que le faire dans l'application. Et ce genre de timestamp sera fait en utilisant le système. Le delta entre le timestamp et l'idéal timestamp donc le temps actuel le temps actuel quand l'application sera de l'application sera assez grande parce que le timestamp sera fait dans le software et ce serait de loin de la transmission actuelle. Il peut y avoir beaucoup de choses. Il peut y avoir un scheduling donc il peut y avoir un autre thread qui peut être scheduling avant que l'application soit terminée sur le hardware. Il peut y avoir queues qui arriveront quand vous utilisez le timestamp dans l'application. Vous pouvez avoir intervier le feu donc vous pouvez avoir beaucoup de choses qui augmenteraient le delta entre le timestamp qui était issu et l'idéal. Donc vous pouvez utiliser le software timestamp mais si vous avez accès au hardware timestamp ce serait vraiment mieux d'avoir une bonne accuracy. Et donc vous avez hardware timestamp où le timestamp sera fait dans le hardware. Donc il pourrait être fait dans un driver mag ou un driver switch aussi. Vous pouvez le faire dans le feu ou il pourrait être fait dans un contrôle délicaté. Et ça va dépendre de ce que les engins du hardware seront capables sur votre machine. Donc ça va vraiment dépendre de la machine que vous utilisez. Quand vous utilisez le hardware timestamp hardware timestamp le source de clou sera ce qui s'appelle la clou de clou de clou qui va généralement être inclus dans les engins qui feront le timestamp. Donc nous ne serons pas utilisés le clou de système. Et quand vous faites ça vous aurez un petit delta entre quand le timestamp s'occupe et quand le paquette a actually la devise parce que ce sera fait dans le hardware. Donc ce sera vraiment close pour le pareurs Linc Et nous n'aurons pas District n'importe waite au-吾 Main cour doulou des Wajng fitted On a tendance à préférer utiliser la température du hardware et on ne veut pas vraiment utiliser la température des softwares, au moins quand vous voulez avoir une haute accuréité, et quand vous voulez vraiment synchroniser l'oclo avec une haute accuréité. Nous avons vu ce que la ptp était, nous avons vu que la ptp était en train de travailler, nous avons aussi regardé ce que la température était et pourquoi la température est importante en utilisant la ptp. Nous avons vu la différence entre la température des softwares et la température du hardware, et pourquoi on a tendance à préférer la température du hardware en utilisant la ptp. Donc maintenant, nous allons voir ce que peut être fait dans le Linux Kernel pour donner la ptp offloader pour utiliser les applications spatiales. Donc, quand on utilise la ptp offloader dans le kernel, nous allons combiner deux mécanismes pour offloader les choses. La première sera cette option de timestamp, et la deuxième sera l'infrastructure de la ptp hardware. C'est exactement ce que nous avons vu avant. Nous allons avoir un mécanisme pour enlever la température dans notre kernel. Ce que nous aimerons accomplir est d'avoir une température faite dans le hardware, donc une température qui serait configurée par un driver. Et puis, nous voulons avoir l'accessoire à la ptp hardware, parce que cette clé serait utilisée comme source de clé pour les packets de timestamp. Donc, nous devons synchroniser cette clé. Nous devons pouvoir ajuster cette clé. Et nous voulons avoir l'accessoire à quelques aidants, qui permettent d'avoir l'accessoire à la ptp hardware. Vous pouvez avoir l'accessoire à l'accessoire dans le kernel, dans la documentation de la ptp networking, qui explique dans une grande distance, tout ceci, mais nous allons couvrir ce qui devrait être fait quand vous voulez donner la température pour la ptp hardware dans un driver. Donc, le premier mécanisme que nous avons besoin de soutenir est l'option de la température au socket. Comme l'application de l'usage de l'usage qui est utilisée en utilisant une option de socket. Et cela peut être utilisé pour générer un timestamp, une réception, une transmission ou un boss. Vous devez pouvoir obtenir un timestamp pour des paquets qui sont envoyés sur la ptp network, des paquets qui seront reçus, et aussi pour les boss, si vous avez besoin. Cette option de socket de timestamp offre plusieurs sources. Vous devez pouvoir sélectionner ce qui sera la source de timestamp pour les paquets de timestamp. Nous avons deux sources, deux sources de software, pour que nous puissions obtenir un timestamp dans la ptp software, dans le kernel, mais dans la ptp software. Le premier, le software Rx, on va instruire le kernel pour les paquets de timestamp. En tant que la ptp de timestamp, nous allons laisser le driver de la ptp, le driver de la ptp network et l'on sera terminé sur le stack Rx. Donc, en tant qu'un paquet, nous arriverons dans le stack Rx. Vous devez savoir quand le paquet a été accepté. Il y a encore un delta entre quand le paquet a été reçu par le hardware, mais le delta est minimisé parce que vous savez que vous n'aurez que le processus fait par le driver de la ptp. Le deuxième serait le tx software, et quand vous selectez ça, nous demandons le kernel d'assurer un timestamp quand le paquet sera senté et le timestamp sera issu dans le driver de la ptp alors que quand il sera issu dépendant du driver de la ptp mais l'idée est de générer le timestamp juste avant d'endir sur le paquet pour le hardware. Donc, c'est toujours terminé en software vous avez besoin de le driver pour supporter d'être capable de l'utiliser. Donc, le côté Rx a été généré de tous les driver de la ptp mais celui-là doit être implémenté dans un driver de la ptp pour l'utiliser. Et puis nous avons deux sources de hardware l'un dans Rx l'autre dans tx et ces deux seront complètement liés à ce que le hardware de la ptp soit capable de l'utiliser et cela va, bien sûr, require le support du driver pour l'utiliser parce que vous devez avoir besoin d'un driver pour exposer ces capacités de timestamp pour l'utiliser et pour l'utiliser afin d'être capable de l'utiliser afin d'instruire le hardware pour les paquets de timestamp dans Rx, dans tx et on verra comment l'utiliser. Il y a d'autres options qui peuvent être utilisées mais qui sont plus d'advances et donc si vous voulez avoir un look à ce que cette option peut faire vous pouvez avoir un look à la documentation qui était sur le slide et vous devez avoir une bonne explication sur tout cela. Donc, avec le socket avec la option d'utiliser la ptp quand nous avons choisi une source de hardware pour la ptp nous devrions utiliser le hardware pour l'utiliser pour l'utiliser pour l'utiliser pour l'utiliser pour les paquets de timestamp et cela est fait avec un autre mécanisme qui va utiliser un call dédicaté ioctl et ce call va utiliser deux paramètres un sera tx type et l'autre sera l'Rx filter donc, quand vous utilisez un type tx vous avez quelques options la première serait de complètement dédicater le timestamp dans le driver de dédicaté ce n'est pas ce que nous voulons faire maintenant, nous voulons faire des paquets de timestamp donc nous avons une autre option qui sera on quand nous avons un timestamp et donné à un driver de dédicaté le driver de dédicaté va instructer le hardware pour les paquets de timestamp qui sera envoyé par ce device de dédicaté et le timestamp sera réporté pour le driver de dédicaté dans des valeurs de façon selon ce que l'engin sera capable de il pourrait être un interrupteur et quand le driver de dédicaté va retirer ce timestamp il va envoyer ça pour des paquets de dédicaté et l'application d'un espace sera capable de le rédicater en utilisant le socket ErrorQ pour que quand on utilise ntp quand on utilise ptp pour exemple, on sera capable de retirer un timestamp de hardware qui a été issue pour un paquet envoyé pour un suivant pour que nous puissions prendre ce timestamp et envoyer un autre paquet nous avons deux autres options la première sera 1 step sync et la deuxième 1 step ptp et cela sera utilisé quand nous voulons utiliser ptp en mode 1 step donc quand on utilise tx 1 step sync un timestamp sera issue quand le paquet sera envoyé pour un hardware de dédicaté mais le timestamp ne sera réporté dans le dédicaté et ne sera pas réporté pour utiliser le space mais il sera directement inclus dans le paquet donc avec la option sync il sera seulement utilisé dans le paquet sync pour que nous puissions supporter le mode 1 step et pour l'autre nous allons également incluir le timestamp dans le paquet de dédicaté un autre point avec la transmission c'est qu'on ne doit configurer les filtres parce que pas tous les paquets seraient timestampés quand on utilise le device l'application de l'usage va instruire le kernel pour le timestamp des paquets de dédicaté et pour seulement ces paquets nous pouvons configurer le hardware pour le timestamp mais ce n'est pas possible dans rx donc c'est pourquoi nous avons un filtre pour que nous puissions matcher des paquets de dédicaté pour que nous puissions souhaiter un timestamp pour ces paquets et pour qu'on utilise le timestamp et pour qu'on utilise le space pour qu'il soit utilisé donc vous avez un grand nombre de filtres qui peuvent être utilisés pour faire ça donc non ne pourra pas matcher tous les paquets vont matcher tout ce qui sera reçu donc le timestamp sera issu pour tous les paquets qui sont reçus et puis vous avez plus de précisions je n'ai que deux de ces mais vous avez une full list dans le net timestamp pour l'exemple une de ces deux possibilités sera d'instruire le hardware pour matcher les paquets de dédicaté seulement pour ces paquets et seulement pour ces paquets vous pourrez obtenir un timestamp donc vous pouvez vraiment avoir une grande configuration de performance sur le hardware pour que cela soit issu pour seulement des paquets spécifiques de dédicaté nous avons vu que beaucoup de ces possibilités doivent être supportées par des voitures donc nous devons poursuivre ce qui sera disponible et l'une de les moyens d'utiliser le debug c'est d'utiliser le tool et le T l'option T donc dans cet exemple si vous voulez voir ce que le TTH2 sera capable d'avoir pour le PTP nous pouvons voir et nous verrons que le TX timestamp dans le hardware et le software nous avons le même en RX nous avons aussi une liste de filtres qui sera supportée donc nous n'avons que deux options nous pouvons ne pas avoir pas de paquets ou nous pouvons filtrer toutes les paquets qui seront reçus sur l'interface pour obtenir un timestamp pour tous les paquets et dans le TX side nous pouvons supporter deux modèles pour les paquets donc quand on veut supporter l'option timestamp dans le driver de la devise nous devons impliquer un peu de paquets pour que nous puissions porter ce qui est disponible pour cette particular network engine nous devons explorer un peu de paquets pour que nous puissions mettre ce qui sera fait dans le hardware donc nous avions des filtres RX nous pouvons mettre ce qui serait le TX mod et toutes ces choses et donc nous devons impliquer un peu de choses pour assurer tout ça la façon dont nous pouvons le faire dépendre d'où nous voulons impliquer si c'est dans un driver ethernet ou si nous voulons faire ça dans un file network ou d'autres engines dédiés donc nous avons quelques fonctions pour impliquer nous avons quand on ajoute support dans un driver ethernet nous devons donner des infos de TX des infos de TX nous devons donner toutes les capacités pour ce hardware pour que nous pouvons voir ce qui est disponible pour un interface network nous devons provider un callback pour l'IOCTL et nous devons filtrer ce qui sera l'IOCTL utilisé pour que nous puissions instruire le driver pour que nous puissions instruire le hardware pour être configuré de la même manière et puis nous devons avoir deux différents deux autres interfaces pour rétribuer le TX timestamp nous avons quelque chose très similaire quand on travaille avec les failles de networking et quand on travaille avec d'autres dédiés et des drivers d'engin le point important c'est que ces deux interfaces nous permettront de faire exactement la même chose nous permettront de rapporter les capacités de timestamp nous permettront de configurer le mode d'opératage pour utiliser les filters Rx et le mode Tx de l'opératage et puis deux interfaces ou des callbacks pour être appelés pour rapporter le timestamp Rx et le timestamp Tx une autre chose avec le timestamp Tx c'est que ça pourrait être incliné parce que si le timestamp n'est pas inclus dans la paquette ça va arriver plus tard ce qui est issu va être envoyé au hardware il va passer au hardware le timestamp va être issu et plus tard le timestamp va être disponible donc il y a des callbacks spéciales pour apporter l'accès à ces timestamps ce qui va arriver plus tard quand on s'occupe de la paquette la autre c'est la fonctionnalité que nous avons besoin de soutenir quand nous voulons apporter la paquette dans le hardware c'est d'avoir l'accès à la paquette donc quand nous avons une paquette dans le dedicated engine nous devons décrire l'opération en utilisant l'information de la paquette et cette structure va avoir beaucoup de callbacks pour pouvoir sélectionner et faire des actions sur la paquette ou pour rapporter son état cette structure va également contenir quelques paramètres comme les ajustements maximaux qui peuvent être fait dans la fréquence pour exemple donc nous devons définir tout ça parce que la paquette doit être synchronisée donc certaines d'opérations qui seraient assez communes seraient en 64 cette paquette va réparer le temps de la paquette pour que nous puissions réparer sur le hardware et pour que nous puissions réparer le temps de la paquette en utilisant le temps de la paquette en 64 donc en temps nous devrions réparer le temps de la paquette et puis trois ajustements fonctionnels une serait pour ajuster la fréquence une autre pour ajuster le temps enfin la dernière pour ajuster la phase de la paquette selon ce qui est disponible dans le hardware engine vous ne pourriez pas pouvoir imprimer tous ces callbacks mais dans beaucoup de cas il devrait être imprimé il y a aussi d'autres fonctionnels qui peuvent être imprimés dans l'infrastructure ptp mais ce serait vraiment dépendant de la paquette et de la capacité mais il ne sera pas utilisé pour les opérations ptp on a l'opportunité de travailler sur un peu de les devices ptp et si vous voulez avoir un exemple sur comment la ptp est disponible et aussi on a l'opportunité pour la paquette et ceci est disponible dans la paquette ptp pour que vous puissiez avoir deux implementations une pour les ptp et l'autre pour la paquette donc pas avec exactement les mêmes interfaces mais vraiment imprimé et enfin on a l'opportunité d'utiliser l'implementation de ptp et tout ça peut être utilisé par l'application un projet très bien utilisé c'est le project Linux ptp donc c'est une implementation d'un protocole de position pour Linux et c'est maintenu par le soutien de la ptp donc c'est vraiment utilisé pour l'implementation d'implementation de ptp pour Linux et surtout c'est correctement utilisé par l'interface de kernel donc tout ce que l'on a utilisé sera utilisé de manière correcte par le project Linux ptp donc vous serez capable de l'utiliser pour les tests pour synchroniser les machines mais aussi si vous voulez l'implementation de référence et voir que tous ces interfaces seront utilisées par l'application de l'application vous devez pouvoir avoir un look sur les sources du project Linux ptp pour que vous puissiez voir toutes ces opérations qui sont faites il y a quelques utilités including ptp4l et phc2cis il y a d'autres mais on va seulement couvrir ces deux utilités qui sont assez cool quand vous voulez utiliser ptp sur un système Linux la première c'est ptp4l et c'est l'implementation de ptp pour ordinateurs et clocs bondaires donc ça peut être utilisé si vous voulez être le leader si vous voulez être le cloc bondaire ou si vous voulez être la suivante ptp4l peut-être que vous puissiez utiliser la tempestampation hardware donc vous pouvez configurer pour sélectionner ce qu'est utilisé pour la tempestampation et ça peut performer ptp opération sur le top de ptp ptp4l, ptp6l et ptp6l donc c'est vraiment un grand support pour les opérations ptp vous pouvez utiliser un file de configuration ou vous pouvez utiliser des paramètres comme nous avons dans cet exemple nous voulons performer ptp opération sur l'interface et th0 nous voulons utiliser la tempestampation hardware et nous voulons envoyer ptp sur internet donc comme vous pouvez le voir ce instance de ptp4l est observé par le master foreign donc c'est un leader qui est déjà disponible sur le réseau c'est-à-dire qu'il y a un acteur et puis vous avez un peu de logs qui arriveront quand le follower sera synchronisé contre le leader remote et la deuxième commande d'utilité serait ptp6l et cette utilité sera utilisée pour synchroniser deux ou plus clés et ça sera généralement utilisé quand nous voulons garder le système clé avec le ptp c'est utile nous voulons utiliser la tempestampation hardware parce que quand nous voulons utiliser la tempestampation hardware ptp4l nous voulons ajouter le phc donc le clé qui est utilisé pour les paquets de tempestampation hardware mais puis nous voulons synchroniser ce phc pour le système clé pour que le système clé soit utilisé par d'autres applications comme le clé source de tempestampation d'autres choses donc si nous voulons utiliser la tempestampation hardware nous devrions pouvoir utiliser le système clé et le phc2c sera utilisé pour synchroniser ces deux clés une commande quand nous voulons utiliser la tempestampation hardware nous n'avons pas besoin d'utiliser le phc2c parce que nous n'avons pas d'accès à un phc2c bien sûr parce que nous n'avons pas d'accès à la tempestampation hardware qui provoque ce genre de clés et dans ce genre de configuration ptp4l va directement synchroniser le système clé donc nous n'avons pas besoin d'utiliser le phc2c pour le système clé merci donc j'espère vraiment que vous vouliez voir ce que c'est ptp pour voir au moins qui fonctionne par un point de vue de haut niveau ce genre de feature pourrait être utilisé par le kernel Linux ce genre d'offloading pourrait être fait et pour l'utilisation du phc2c et pour l'utilisation du phc2c et pour l'utilisation du phc2c pour l'utilisation du phc2c je vous souhaite vraiment que ça soit utile pour vous merci