À tout hasard : tu n'aurais pas des règles ebtables?

Bonsoir,
Tout d'abord merci pour ce site qui m'a permis de faire les tests que je voulais. Le mode bridge fonctionne et grâce au logiciel netem (génial pour tester le comportement des reseaux!) j'ai pu vérifier le comportement au "stress" des boitiers TV V5 et V6.
J'ai effectué les tests sur les 2 boitiers reliés l'un après l'autre sur le nouveau server V6, le tout sans cpl donc  sans problème de  débit. Le tout sur la même chaine HD (et ce sur un laps de temps suffisament court pour ne pas mettre en cause le débit du flux video).

La première constatation c'est que le flux video "arrive" plus vite sur la TV avec la V6 que la V5 (hardware ? software ?).

Après, j'ai à l'aide de netem, introduit de la latence ou du retard, ou de la corruption sur les paquets simulant des defauts de ligne.

La constatation est nette, dans les 3 cas la V5 "accepte" plus de defauts que sa petite soeur la V6.

Là où cela est encore plus sensible, c'est la réaction des 2 boitiers face à ces defauts, concernant la video : la V5 se contente pour l'image d'introduire des freezes, ou arctefact et reprend son cours dès que l'on rétablit la ligne sans defaut. La V6 elle aussi se met à "freezer" mais cela va jusqu'au gel d'image, qu'il n'est plus possible de rétablir, si ce n'est en débranchant électriquement le boitier : moralité : plantage total!

Concernant le son, les comportements sont là encore bien différents, si la V5 se contente au pire de couper totalement le son et laisser l'image continuer (on peut avoir aussi un son haché), la V6 elle èmet de TRES forts  craquements quand il y a un défaut, ces craquements sont d'autant plus amplifiés que l'on est raccordé sur un ampli/home 5.1.

Est-ce un problème de hardware ou de software En tout état de cause ce qui pouvait "passer" sur des lignes faiblement perturbées ne passe plus avec le nouveau boitier.( J'ai fait 2 enregistrements du son perturbé l'un sur la V5 l'autre sur la V6 mais je ne sais pas comment les attacher au message).

Bien sur ces problèmes vont encore être plus présents si l'on utilise des cpl ayant des perturbations ou des débits insuffisants.

Merci pour ces tests, très intéressant.

A tu testé un peu de gigue ?

Certains décodeurs n'ont aucun buffer et un paquet qui arrive en retard d'un paquet est considéré comme perdu. En HD les paquets étant très proche, le moindre petite gigue rend la TV inutilisable. Heureusement les paquets sont priorisés de bout en bout et normalement la gigue est nulle même si les liens sont saturés.

La documentation pour introduire de la gigue avec NetEm :

Packet re-ordering

There are two different ways to specify reordering. The first method gap uses a fixed sequence and reorders every Nth packet. A simple usage of this is:

 # tc qdisc change dev eth0 root netem gap 5 delay 10ms

This causes every 5th (10th, 15th, ...) packet to go to be sent immediately and every other packet to be delayed by 10ms. This is predictable and useful for base protocol testing like reassembly.

The second form reorder of re-ordering is more like real life. It causes a certain percentage of the packets to get mis-ordered.

 # tc qdisc change dev eth0 root netem delay 10ms reorder 25% 50%

In this example, 25% of packets (with a correlation of 50%) will get sent immediately, others will be delayed by 10ms.

Newer versions of netem will also re-order packets if the random delay values are out of order. The following will cause some reordering:

 # tc qdisc change dev eth0 root netem delay 100ms 75ms

If the first packet gets a random delay of 100ms (100ms base - 0ms jitter) and the second packet is sent 1ms later and gets a delay of 50ms (100ms base - 50ms jitter); the second packet will be sent first. This is because the queue discipline tfifo inside netem, keeps packets in order by time to send.

Caveats

    Mixing forms of reordering may lead to unexpected results
    Any method of reordering to work, some delay is necessary.
    If the delay is less than the inter-packet arrival time then no reordering will be seen.

Vivien,
suite à tes observations j'ai donc fait le test de gigue.
Là encore 2 comportements différents :
le boitier V5 supporte beaucoup plus (ou traite mieux?) le phénomène, le son continue normalement mais  l'image a de nombreux arctefacts, jusqu'à se figer pendants quelques secondes.
Tout redevient normal quand on rétablit un flux normal.

Le boitier V6 quant à lui, continue également à diffuser le son normalement, mais commence à générer des arctefacts beaucoup plus tôt, l'image finalement se fige et là contrairement à la V5 ça ne revient pas à la normale quand on rétablit le flux (tout est planté au niveau de la tv, on peut revenir au menu, mais si on revient sur la tv la dernière image qui a figé revient, plus de son, si on change de chaines ça mouline sans jamais remettre une image), plus grave il faut arrêter le boitier pour retrouver une situation normale (comme dans les cas précédents).

Concernant les différences constatées au niveau du son ("mitraillette" sur la V6) est-ce un problème de hardware ou software ?

Oui le son de la V6 a vraiment un problème.

Il faut mettre le son fort pour entendre tes enregistrements...

Bonsoir,

Une petite question technique : le server et le player de la V6 sont reliés soit par câble ethernet à 1Gb/s soit par cpl à 100Mb/s. Il semble que si l'on configure manuellement la vitesse à 10Mb/s les problèmes s'atténuent !!
Est-ce que techniquement ça se défend de dire que le flux vidéo étant transmis plus lentement, la partie server a "plus" de temps pour n'envoyer que des trames bonnes et traiter les erreurs d'entrée ADSL?