Pendant les deux expériences, la TV est allumé sur un flux TV HD (La 6 ou la 1). Une des métriques de la mesure est la présence (ou l’absence) de “glitches” sur l’écran.

Mon réseau interne ressemble à ca :

— VDSL —|WAN|[ freebox server ]|LAN| —- lien ethernet 100M —- |eth2|[ routeur openwrt ]|eth0| —- lien 100M —- [switch 1GB ] —- TV, Pc etc...

Le routeur openwrt est utilisé pour faire les mesures de débit et vérifier le packet drop à son niveau.

Expérience 1
~~~~~~~~~~~~~

Afin de créer du débit, j’utilise le test “débit local” en téléchargeant le fichier de 1Go plusieurs fois simultanément.

Le débit créé est d’environ 35MB/s en sortie du freebox server mini, pour 10000 pps (pkt per second).

L’impact sur la qualité du flux TV est quasi nul, il y a bien quelques pertes de paquets visibles sur la TV, mais l’infra réseau tient globalement.

Expérience 2
~~~~~~~~~~~~

Dans cette expérience, on génère un flux équivalent, mais qui traverse le freebox server, et qui ne vient pas de la freebox elle-même, comme c’est le cas pour le test de débit local utilisé précédemment.

On génère du débit en téléchargeant quelques archives du noyaux linux depuis kernel.org simultanément.

Le débit généré est au max de de 18MB/s, avec 1500 pps.

Conclusions

Pourquoi ca drop dans la freebox ?

En générant un débit inférieur (en terme de débit et de packet rate) qui traverse la freebox, on arrive à perturber le flux TV très perceptiblement. J’en conclus que traverser la pile IP de Linux coute cher au CPU de la freebox server mini.

Questions

0) Suis-je le seul à observer ce comportement ?

1) Serait il possible d’avoir les compteurs des interfaces réseaux (eth0) en ce qui concerne le packet drop afin de confirmer cette hypothèse ?

2) Faut-il passer la freebox en mode bridge pour pouvoir profiter des 100Mb/s de la nouvelle interface ?