Emmanuel García : Tâche 4 : Qualité de service
-🖥️-
Pour cette tâche, j’ai choisi d’effectuer différents tests de qualité de service (Quality of Service -QoS) sur l’application PS3 Media Server, via un réseau sans fil Infinitum.
Serveur multimédia PS3
Serveur multimédia PS3 ou SPM, il s’agit d’un serveur multimédia UPnP DLNA.
DLNA (Digital Living Network Alliance) est une norme qui permet aux appareils numériques tels que les PC, les téléviseurs, les smartphones connectés en réseau, de partager des données entre eux, s’ils sont compatibles.
Les appareils compatibles DLNA remplissent deux fonctions différentes. « Serveurs » qui distribuent des éléments multimédias tels que des images, de la musique ou des vidéos, et « clients » qui reçoivent et reproduisent lesdites données.
En utilisant la PS3 comme client et un PC exécutant PMS comme serveur, il est possible de lire des images, des vidéos ou de la musique stockées sur le serveur via le réseau local.
Qualité de service
Lorsque vous effectuez l’exemple avec un réseau sans fil, la configuration est similaire à la suivante (en omettant le périphérique audio) :
Les facteurs qui seront pris en compte (expliqués dans le labo post) sont les suivants :
- Gigue
- Débit binaire
- Perte de colis
- Latence
Débit binaire
Le débit binaire est essentiellement la vitesse de transmission avec laquelle l’application doit fonctionner. Ici, le fait qu’il s’agisse d’un serveur DLNA, c’est-à-dire que les transmissions soient locales, aide beaucoup à augmenter le débit binaire, ce qui en fait un réel facteur qui affecte la qualité de service.
Avec PMS, il est facile de surveiller le débit binaire car il montre comment il change avec le maximum de la session entière. Lors de la mise en pause ou de la non lecture de la vidéo, elle sera logiquement à 0 car rien n’est envoyé. Mais au fur et à mesure de la lecture de la vidéo, le débit binaire augmente et varie dans le temps, entre 0 et MAX, MAX pouvant également changer.
Le débit binaire actuel représente la vitesse de transmission actuelle (11 mégaoctets par seconde) et le débit binaire maximal le maximum atteint dans la session en cours.
J’ai pu constater deux choses très importantes :
- Compte tenu du fait que je n’avais aucune autre application utilisant le réseau, le débit moyen était d’environ 11 Mb/s – 12 Mb/s sans aucune interférence notable.
- En tombant en dessous de 10 Mb/s, la vidéo se figeait proportionnellement à la diminution de la vitesse.
Conclusion avec le débit : En supposant que le service soit utilisé seul, c’est-à-dire sans utiliser aucune autre application susceptible de limiter le débit binaire utilisé par PMS, il fonctionne parfaitement sans décalage ni interférence notable. Mais ce n’est pas toujours le cas, normalement les gens ont leurs smartphones connectés à leur réseau tout en regardant des films avec ce type de flux, ou quelqu’un d’autre effectue simultanément une autre tâche, ce qui affecterait les performances du PMS.
Perte de colis
Comme mentionné dans l’article de laboratoire, la perte de paquets n’est pas vraiment significative en termes de qualité de service si le débit binaire est élevé. Plus le débit binaire augmente, moins la probabilité de perte de paquets est grande.
De même, en effectuant une mesure de perte de paquets à l’aide de Wireshark, nous pouvons voir que cela est vrai. Pour voir les paquets perdus au cours d’une session TCP, il faut d’abord isoler ladite session des autres, en cliquant sur un certain paquet dont nous savons qu’il appartient à ladite session et en sélectionnant Suivre le flux TCP. Cela nous présente une fenêtre avec les paquets filtrés pour n’afficher que ceux qui appartiennent à cette communication. Avec cela, un nouveau filtre « et tcp.analysis.lost_segment » est ajouté pour pouvoir afficher les paquets perdus. Dans ce cas aucun colis n’est apparu qui a été perdu pendant la communication Comme vous pouvez le voir.
Conclusion: Comme nous travaillons avec des débits binaires considérablement élevés, la perte de paquets n’est pas significative, ajoutant également qu’il s’agit d’un réseau local.
Latence (Délai)
A partir du moment où l’on sait que le PMS fonctionne avec la technologie DLNA, c’est-à-dire que dans les réseaux locaux on peut prédire que la latence n’est pas un réel facteur (le serveur et le client sont sur le même réseau), mais on peut aussi le vérifier.
Pour mesurer la latence, j’ai simplement utilisé ping, ping de l’IP du serveur (PC) vers l’IP du client (PS3). Les résultats (couvrant les IP pour des raisons de sécurité) sont les suivants :
On obtient ici une moyenne de 3ms dans les temps, avec un maximum de 5ms. Le temps est excellent comme prévu, pour être un simple envoi à un réseau local.
Conclusion: La latence n’est pas un facteur dans le cas du PMS, principalement du fait que la communication entre client et serveur s’effectue sur un réseau local, et que les temps d’envoi et de retour (aller-retour) sont trop courts.
Gigue
Pour étudier la gigue ou (variation du délai de paquet), Wireshark est à nouveau utilisé, faisant un graphe temporel sur les transmissions entre le client et le serveur (PC et PS3). Celui-ci est accessible dans l’onglet Statistiques-> graphe de flux. Avec cela, nous pouvons créer un graphique du flux de la session TCP, montrant les heures auxquelles les données sont envoyées et reçues.
En regardant vers la gauche, nous avons les heures auxquelles les paquets ont été envoyés (à partir du point 0 où la mesure a commencé).
En traçant les variations dans le temps, on voit plus facilement les changements :
Conclusion: Il y a de la gigue dans la transmission des données entre le client et le serveur, du fait que certains paquets sont envoyés plus rapidement que d’autres.
N’oubliez pas de partager l’article avec vos amis !