streamers, mesures ou écoutes?

[KIKIWILLYBEE]

Bonsoir les Gars,
Et de nouveaux mes vœux les plus cordiaux à tous .. ;-)..

SVP :
La fonction d’un lecteur réseau est de distribuer un flux informatique , et éventuellement d’opérer une conversion de protocole , et un déplacement de couches ‘OSÎ’  : extractions des paquets Ip. …
Un bon lecteur réseau s’efforcera d’opérer de façon optimal ces fonctions : le respect de l’intégrité des paquets ip.  , au delà de la robustesse 8o2.3 et le respects du flux isochrone :  le flux informatique à récurrence temporelle stricte , idéalement à guigue nulle .
Fameuse cette guigue ou jitter est le delta de temps dans la distribution des echantilllons numériques, caractériser par délay et latence , mesurer en temps . : S-1.
Pour nos équipements , ce que permets les technologies domestique est une précision temporellle à court terme , cf. Bruit de phase , et Allan Variance de l’orde de la pico seconde  : 1o-12 jusqu’à la dizaine centaine de Femto seconde : 1o-15 pour les équipements les mieux dotés. (un équipement de labo hp keysight Agilent aura une précision supérieure à 25 1o-15 S-1).
L’autre partie de la fonction est la conversion de protocole , accompagné souvent d’un changement de couche OSI . C’est un process informatique . A l’exemple de la conversion d’un flux réseaux 8o2.3 rj vers l’USB 2.o audio . Ce process consomme du temps CPU. et peu aussi altéré l’échantillon par perte d’information , mais en fonction de la performance de l’algorithme de conversion introduire ou non logiquement delay et latence corrélé au temps CPU. De plus ces protocoles ne sont pas dotés de correction d’erreurs . La perte de bit , d’information est definitive.
Il faut donc un process durci , et rapide pour préserver l’échantillon et minimiser delay et latence source de guigue ,
Cette guigue introduit une imprécision temporelle dans le flux isochrone , est cela se straduira par une imprécision de l’image stéréo , et de la juste localisation des pupitres et instruments effet brouillon…

(Puis Notre réseau semblerait  donc avoir plusieurs maux ,  évoquons  le NETWORKING JITTER .

Celà altère l’intégrité des données et paquets tcp et adresses ip, et corrompt donc l’intégrité des fichiers ou flux transmis mais aussi les références temporelles . Il est visualisé dynamiquement sur un analyseur de trame TCP/IP par le 'diagramme de l’œil', et caractérisé par sa latence , les délais et les pertes de paquets.
(perte paquets, retard, latence). Un 'ping' vers la source... ou des outils d’administration tel Solarwind,PRTG Network Manager , Cisco mngt ... permettent cette évaluation .

Ces mesures sont soit : sur _simple point ou RTT. (single Endpoint)  : Round Trip Term ,
ou  : en _double point : variation entre deux intervalles pour la transmission et réception paquets ).
une mesure de la bande passante égale a la définition de la capacité de saturation rsx. 'Paquet loss' ajoutera une information de qualité... )

Avec 'Latence' ms-1, '
Delay' ms-1, '
.’Over all packet latency' en %
il est possible  alors d'évaluer le 'Networking jitter' composé du 'Jitter constant': valeur consolidé moyenne de la variation de 'Delay' paquet à paquet ,
le 'Jitter dit transitoire' qui affectera un seul paquet égale aussi à 'la variation de delay à court terme' ayant pour causse essentiellement la congestion du réseau…

la norme de qualité , et les tolérances pour les rsx 8o2.3 sont
de 2o à 3o nano seconde 1o-9 S-1 pour le delay,
1% de 'paquet loss',
et +/-15o milli seconde 1o-3 S-1 pour le 'over all packet latency'.

Pour introduire , svp la fonction du streamer , En tout cas ce que j’ai pu en appréhender  , les copains.. !?..

..
Bien a vous,
Cordialement,
W :-).