![[Image: banniereforumhifi.jpg]](https://i.postimg.cc/wxwWFvzj/banniereforumhifi.jpg)
Il y a 6 heures
(Modification du message : Il y a 6 heures par KIKIWILLYBEE.)
Bonjour,
Svp ,
A propos du choix d’une technologie rsx , d’une implantation, d’un actif rsx. pour un équipement audio , et avant la recherche complexe des métriques au travers de WireShark sur un autre fil ; peut être pourrions nous nous interroger sur les aspects qui pourraient intervenir dans l’analyse des causes de détérioration de l’intégrité de notre flux réseau pour le streaming audio , et ainsi
Pourrions-nous résumer les ´bruits’ divers intervenant dans notre process de streaming audio : de qualité audiophile que les anglo-saxons acharnés du sujet à l’instar de AUDIOPHILSTYLE .us nomment SQ.
Et aussi pouvoir affirmer la non pertinence de certaines mesures…. ;-)
Cela ,
Afin de tenter une approche plus complexe , et plus près des réalités physiques ….
Et comprendre pourquoi les aspects qualitatifs exclus de fait un Wi-Fi. ( à l’exception du DRAFT. 7 , qui pour la qualité nécessaire pour les gamers , vidéastes … inclus une artillerie algorithmiques : quad band de multiplexages , intelligence dynamique de la gestion des liens . .. contraignant la latence , le délai , le ´Network Jitter’ ) et ainsi se rapprocher de la qualité de service nécessaire pour des applications dite ´TIME SENSITIVE’. Telles Audio Vidéo Bridge , AES67. (Dante. , RAVENNA. , LiveWire. …) , Aoip. , Voip. ….et bien sûr notre précieux .flux SQ. …..
En premier lieu :
nous pourrions citer les bruits relatifs au transport lui même : ceux donc associés au flux réseau 8o2.3
- Jitter : la fameuse et incontournable guigue ou : Variations dans le timing de la distribution des paquets audio. Ces fluctuations dans la synchronisation de l’horloge réseau dans un flux dit ISOCHRONE détériore l’intégrité des données, celle ci est évaluée globalement à l’aide de la statistique BER. Bit error ratio. Dans les environnements critiques celle ci doit tendre vers les 1o-12/1o-13 , soit un bit perdu tout les milliards ou dizaine de milliards de bits.
- Attachée aussi à la distribution des paquets et du flux la Latence : Retard dans le transfert des données audio. Si mal gérée, elle peut induire une perte de synchronisation (désynchronisation labiale / visuelle, effet d’écho). Évaluée en milli seconde, elle correspond à un double ping.
- De même pour le flux réseau on mesure le Packet loss. ou Paquets perdus , c’est une erreur de transmission : En cas de congestion réseau ou de mauvaise gestion des buffers, des fragments audio peuvent être perdus ou arriver hors séquence, générant des coupures ou des artefacts.
(Cf.MOS Mean. Opinion. Score. De l’Aoip./Voip. Déjà expliqué dans d’autres posts…svp.).
En second lieu :
les Bruits électromagnétiques et radioélectriques EMI HF , CEM. , ou encore RFI. ..
- EMI / RFI (interférences électromagnétiques et radiofréquences) : Les équipements audio connectés au réseau Ethernet peuvent être exposés aux interférences causées par des appareils électriques proches (wifi équipement domestique…) il faut éviter des câbles non blindés, et éloigner des réseaux sans fil voisins. Bien sûr émetteur massif multibandes d’émission HF. Et leurs interférences
- les bruits électriques touche surtout l’alimentation des équipements , nous relèverons les bruits sur le mode commun transmis par les masses et blindages , et le bruit différentiel relatif aux bruits du signal de la tension d’alimentation et la stabilité de celui,celle ci , ainsi après le PSRR. (Power Supply Réjection Ratio , exprimé en dB a une fréquence ou bande passante de référence ) ; on complètera la qualification de l’alimentation par le Ripple V.S-1 ou ondulation résiduelle. Bruits du mode différentiel…
Enfin ,
accessoirement les Bruits anthropiques ou inhérents à l’environnement..
• Composants de faible qualité : Les switchs réseau, routeurs et câbles Ethernet mal adaptés ou non blindés peuvent introduire des pertes, du jitter, ou des interférences.
Et svp …
Pour en revenir, sur Wireshark. et l’accès aux métriques rsx.8o2.3. ci dessous :
Latence. (TCP)
- Pour la latence, il faut capturer le trafic sur l’interface concernée et filtrer sur la session TCP cible (exemple: filtre « tcp » ou en précisant les IP).
- Wireshark indique le temps d’arrivée de chaque paquet dans la colonne « Time ». La latence RTT (Round Trip Time) s’obtient en soustrayant le timestamp du paquet de requête
(TCP SYN, HTTP GET, etc.)
à celui de la réponse
(TCP SYN/ACK, HTTP OK, etc.):
$$
\text{latence} = t_\text{réponse} - t_\text{requête}
$$
- pour un affichage synthétique :
Menu « Statistiques → Conversations → TCP », où le RTT est résumé pour chaque stream.
- Il est aussi possible de tracer les RTT. Roubd time trip sur la durée en allant dans menu « Statistiques → IO Graphs » et en ajoutant le champ TCP delta (intervalle inter-paquet).
Perte de paquets (Packet Loss)
- La perte s'identifie avec les filtres d’analyse « tcp.analysis.retransmission » (retransmission de segment) et « tcp.analysis.duplicate_ack » (duplicate ACK après segment manquant).
- Wireshark signale les paquets perdus par l’alerte: le
« [TCP previous segment not captured] » lorsque les numéros de séquence TCP sautent de façon inattendue.
- Pour voir les pertes, appliquez les filtres :
- `tcp.analysis.retransmission`
pour les paquets retransmis
- `tcp.analysis.ack_lost_segment` pour les ACKs associés à une perte.
Notre Jitter (Variation temporelle inter-paquet # delay. )
- Le jitter TCP n’est pas calculé nativement par Wireshark comme pour RTP, mais vous pouvez l’estimer . ; Exportez les timestamps des paquets TCP (colonne à ajouter : `tcp.options.timestamp.tsval`), puis calculez la variance des intervalles d’arrivée (delta entre chaque paquet) sur Excel ou un script dédié. (Ce dont je ne dispose pas , dsl ,) . Le jitter correspond à des fluctuations du délai inter-paquet, causés par problèmes de queue, congestion ou traitement. Cela en fonction de la qualité de l’infrastructure, des débits sollicités, de la puissance CPU. Des actifs …
- En option, vous svp , pouvez visualiser les deltas sur
Menu : « Statistiques → Graphiques IO » pour repérer les pics et la régularité des arrivées.
Sources svp :
To Find Network Latency in Wireshar | PDF - Scribd ;
https://www.scribd.com/document/78238660...n-Wireshar
Examining Packet Loss Using Wireshark ;
https://www.linkedin.com/pulse/examining...ejith-raju
Jitter values for TCP Streams in Wireshark? ;
https://stackoverflow.com/questions/9530...-wireshark
Troubleshooting Latency, Packet Loss, and Jitter Using ... : https://www.linkedin.com/pulse/troublesh...nune-nxaof
TCP Segment Loss in Wireshark: Expert Tips and Tricks - PacketSafari :
https://packetsafari.com/blog/2022/12/27...-wireshark
Detect TCP Delays with Wireshark .;
https://www.youtube.com/watch?v=e_iS4DfLCEM
Jitter value for an RTP stream ; https://www.reddit.com/r/wireshark/comme...tp_stream/
[8] 7.5. TCP Analysis https://www.wireshark.org/docs/wsug_html...lysis.html
Jitter calculation in Wireshark ;
https://stackoverflow.com/
…
Bien à vous,
Cordialement,
W ;-).
Svp ,
A propos du choix d’une technologie rsx , d’une implantation, d’un actif rsx. pour un équipement audio , et avant la recherche complexe des métriques au travers de WireShark sur un autre fil ; peut être pourrions nous nous interroger sur les aspects qui pourraient intervenir dans l’analyse des causes de détérioration de l’intégrité de notre flux réseau pour le streaming audio , et ainsi
Pourrions-nous résumer les ´bruits’ divers intervenant dans notre process de streaming audio : de qualité audiophile que les anglo-saxons acharnés du sujet à l’instar de AUDIOPHILSTYLE .us nomment SQ.
Et aussi pouvoir affirmer la non pertinence de certaines mesures…. ;-)
Cela ,
Afin de tenter une approche plus complexe , et plus près des réalités physiques ….
Et comprendre pourquoi les aspects qualitatifs exclus de fait un Wi-Fi. ( à l’exception du DRAFT. 7 , qui pour la qualité nécessaire pour les gamers , vidéastes … inclus une artillerie algorithmiques : quad band de multiplexages , intelligence dynamique de la gestion des liens . .. contraignant la latence , le délai , le ´Network Jitter’ ) et ainsi se rapprocher de la qualité de service nécessaire pour des applications dite ´TIME SENSITIVE’. Telles Audio Vidéo Bridge , AES67. (Dante. , RAVENNA. , LiveWire. …) , Aoip. , Voip. ….et bien sûr notre précieux .flux SQ. …..
En premier lieu :
nous pourrions citer les bruits relatifs au transport lui même : ceux donc associés au flux réseau 8o2.3
- Jitter : la fameuse et incontournable guigue ou : Variations dans le timing de la distribution des paquets audio. Ces fluctuations dans la synchronisation de l’horloge réseau dans un flux dit ISOCHRONE détériore l’intégrité des données, celle ci est évaluée globalement à l’aide de la statistique BER. Bit error ratio. Dans les environnements critiques celle ci doit tendre vers les 1o-12/1o-13 , soit un bit perdu tout les milliards ou dizaine de milliards de bits.
- Attachée aussi à la distribution des paquets et du flux la Latence : Retard dans le transfert des données audio. Si mal gérée, elle peut induire une perte de synchronisation (désynchronisation labiale / visuelle, effet d’écho). Évaluée en milli seconde, elle correspond à un double ping.
- De même pour le flux réseau on mesure le Packet loss. ou Paquets perdus , c’est une erreur de transmission : En cas de congestion réseau ou de mauvaise gestion des buffers, des fragments audio peuvent être perdus ou arriver hors séquence, générant des coupures ou des artefacts.
(Cf.MOS Mean. Opinion. Score. De l’Aoip./Voip. Déjà expliqué dans d’autres posts…svp.).
En second lieu :
les Bruits électromagnétiques et radioélectriques EMI HF , CEM. , ou encore RFI. ..
- EMI / RFI (interférences électromagnétiques et radiofréquences) : Les équipements audio connectés au réseau Ethernet peuvent être exposés aux interférences causées par des appareils électriques proches (wifi équipement domestique…) il faut éviter des câbles non blindés, et éloigner des réseaux sans fil voisins. Bien sûr émetteur massif multibandes d’émission HF. Et leurs interférences
- les bruits électriques touche surtout l’alimentation des équipements , nous relèverons les bruits sur le mode commun transmis par les masses et blindages , et le bruit différentiel relatif aux bruits du signal de la tension d’alimentation et la stabilité de celui,celle ci , ainsi après le PSRR. (Power Supply Réjection Ratio , exprimé en dB a une fréquence ou bande passante de référence ) ; on complètera la qualification de l’alimentation par le Ripple V.S-1 ou ondulation résiduelle. Bruits du mode différentiel…
Enfin ,
accessoirement les Bruits anthropiques ou inhérents à l’environnement..
• Composants de faible qualité : Les switchs réseau, routeurs et câbles Ethernet mal adaptés ou non blindés peuvent introduire des pertes, du jitter, ou des interférences.
Et svp …
Pour en revenir, sur Wireshark. et l’accès aux métriques rsx.8o2.3. ci dessous :
Latence. (TCP)
- Pour la latence, il faut capturer le trafic sur l’interface concernée et filtrer sur la session TCP cible (exemple: filtre « tcp » ou en précisant les IP).
- Wireshark indique le temps d’arrivée de chaque paquet dans la colonne « Time ». La latence RTT (Round Trip Time) s’obtient en soustrayant le timestamp du paquet de requête
(TCP SYN, HTTP GET, etc.)
à celui de la réponse
(TCP SYN/ACK, HTTP OK, etc.):
$$
\text{latence} = t_\text{réponse} - t_\text{requête}
$$
- pour un affichage synthétique :
Menu « Statistiques → Conversations → TCP », où le RTT est résumé pour chaque stream.
- Il est aussi possible de tracer les RTT. Roubd time trip sur la durée en allant dans menu « Statistiques → IO Graphs » et en ajoutant le champ TCP delta (intervalle inter-paquet).
Perte de paquets (Packet Loss)
- La perte s'identifie avec les filtres d’analyse « tcp.analysis.retransmission » (retransmission de segment) et « tcp.analysis.duplicate_ack » (duplicate ACK après segment manquant).
- Wireshark signale les paquets perdus par l’alerte: le
« [TCP previous segment not captured] » lorsque les numéros de séquence TCP sautent de façon inattendue.
- Pour voir les pertes, appliquez les filtres :
- `tcp.analysis.retransmission`
pour les paquets retransmis
- `tcp.analysis.ack_lost_segment` pour les ACKs associés à une perte.
Notre Jitter (Variation temporelle inter-paquet # delay. )
- Le jitter TCP n’est pas calculé nativement par Wireshark comme pour RTP, mais vous pouvez l’estimer . ; Exportez les timestamps des paquets TCP (colonne à ajouter : `tcp.options.timestamp.tsval`), puis calculez la variance des intervalles d’arrivée (delta entre chaque paquet) sur Excel ou un script dédié. (Ce dont je ne dispose pas , dsl ,) . Le jitter correspond à des fluctuations du délai inter-paquet, causés par problèmes de queue, congestion ou traitement. Cela en fonction de la qualité de l’infrastructure, des débits sollicités, de la puissance CPU. Des actifs …
- En option, vous svp , pouvez visualiser les deltas sur
Menu : « Statistiques → Graphiques IO » pour repérer les pics et la régularité des arrivées.
Sources svp :
To Find Network Latency in Wireshar | PDF - Scribd ;
https://www.scribd.com/document/78238660...n-Wireshar
Examining Packet Loss Using Wireshark ;
https://www.linkedin.com/pulse/examining...ejith-raju
Jitter values for TCP Streams in Wireshark? ;
https://stackoverflow.com/questions/9530...-wireshark
Troubleshooting Latency, Packet Loss, and Jitter Using ... : https://www.linkedin.com/pulse/troublesh...nune-nxaof
TCP Segment Loss in Wireshark: Expert Tips and Tricks - PacketSafari :
https://packetsafari.com/blog/2022/12/27...-wireshark
Detect TCP Delays with Wireshark .;
https://www.youtube.com/watch?v=e_iS4DfLCEM
Jitter value for an RTP stream ; https://www.reddit.com/r/wireshark/comme...tp_stream/
[8] 7.5. TCP Analysis https://www.wireshark.org/docs/wsug_html...lysis.html
Jitter calculation in Wireshark ;
https://stackoverflow.com/
…
Bien à vous,
Cordialement,
W ;-).
![[Image: PLAN-RSX-2.jpg]](https://i.ibb.co/6wZscdG/PLAN-RSX-2.jpg)