Bonjour,
Dans mon réseau domestique j'ai un petit serveur sur lequel une application de monitoring réseau exécute un ping sur Google toutes les 10 secondes.
Si sur ma machine principale j'effectue des speed tests, la latence des pings double et parfois le ping finit en erreur.
C'est un problème que je reproduis très facilement avec des speed tests, mais que je rencontre aussi parfois dans l'utilisation quotidienne même si ce n'est pas perceptible pour les utilisateurs (pas de freeze TV par exemple).
La box 8X ainsi que ma machine principale sont chacune sur un port 10G, le serveur sur un port 2.5G, le tout sur le même switch qui a une capacité de commutation de 80 Gb/s.
Est-ce que je peux en déduire que la box 8X a du mal à router tous les paquets quand le trafic est élevé ? Est-ce un problème de QoS ? Est-ce spécifique à la 8X, ou est-ce que les autres box se comportent comme cela dans la même situation ?

IPv6 ne peut pas fonctionner correctement sans ICMP, donc pas sûr que ce soit un bon candidat.
Je reste surpris qu'avec un lien à 8Gb utilisé à 50%, un malheureux ping ne puisse pas passer, quitte à réduire de 0,001% le reste du trafic.

Baaaah... c'est normal.

Tu dis que ta machine est en 10G, et ton serveur (qui fait les ping) en 2.5G.
Ta machine fait les speedtests, sature le lien délibéremment, et tu observes des pertes.
Et oui, il n'y a pas de miracle, les trames ICMP (comme d'autres d'ailleurs) n'ont plus de place dans la queue de l'OLT vers toi.
Au début oui il met en file d'attente (d'où la hausse de ping), mais au bout d'un moment si la charge ne baisse pas, bah il jette comme l'a très bien dit Fyr.

Tu révèles ne pas voir de problème avec la TV, là aussi c'est normal, les paquets multicast sont priorisés pour qu'ils passent, quoi qu'il arrive.

Donc évite de faire des speedtests inutilement, fais confiance à ton FAI, 10G t'es largement bien, et surfe tranquille

Ah là ça avance un peu. Ca veut dire que c'est au niveau de l'OLT que ça sature et pas au niveau de la box ?
Comme je l'ai dit dans mon 1er message, je reproduis facilement avec des speedtests, mais le phénomène arrive sporadiquement sans chercher à le provoquer.
Et c'est ce dernier cas qui me gène un peu, car ça veut dire que parfois avec un usage "raisonnable" on peut avoir l'OLT saturé.
Si pendant que mon voisin fait un speedtest mes pings ne passent plus (ou inversement  ), ce n'est pas satisfaisant. Il y a quand même un problème de QoS quelque part.
Ce n'est pas normal qu'un seul abonné ait le pouvoir de saturer un OLT à lui tout seul au détriment des autres.
Je suis surpris qu'un OLT n'ait pas une protection aussi élémentaire, c'est assez inquiétant à quel point le réseau est vulnérable.

Oui.

En fait, c'est assez inédit, mais les gros FAI vous vendent la totalité de la capa de l'arbre aux abonnés du même arbre.
Avant, vous aviez de l'ADSL 20 mégas, mais le DSLAM était en gigabit, la question ne se posait pas.
Là vous avez 10G dans l'arbre, et 10G à la prise... mais vous n'êtes pas seul dessus.
Donc un seul abonné peut saturer l'arbre s'il a le matos pour (+ avec la conso des voisins).
D'où le fait de prioriser certains flux comme la TV ou la VOIP, sinon ce serait horrible si le geek du quartier fasse sauter le téléphone ou la tv.

D'un côté, la capa est là, elle est allumée, utilisez-la si elle est dispo.
D'un autre, c'est absurde de vendre à UN client la capa totale dispo du réseau mutualisé.

Heureusement qu'on n'a pas cette mentalité pour l'électricité, sinon les pauvres transfos prendraient cher 

Disons que ça serait moins choquant si la bande passante était réellement répartie entre les abonnées, ce qui ne semble pas être le cas.
Parce que tout miser sur le coopératif, c'est bien mal connaitre l'humanité qui est naturellement plus proche de la loi de la jungle que du partage.
J'en déduis que la file d'attente est globale à l'OLT, et qu'il n'y a pas en plus une liste d'attente par abonné ?
Si c'est le cas, le design est assez primaire, alors qu'on pourrait faire une sorte de round robin entre les abonnés.
Bref, il ne reste plus que la TV pour pleurer.

Non, tu as à minima une file pour chaque interface, donc chaque port de l'OLT (donc ton arbre)

Et statistiquement, l'output (du point de vue de l'OLT, donc OLT vers toi) est toujours plus sollicité et soumis à drop si saturation.

Et non la bande passante n'est pas répartie équitablement. Vous n'avez pas 10G divisé par le nbre d'abonné, tout le temps, en statique.

Il y a une capa de 10G à l'instant T, une utilisation de 300 mégas à l'instant T.
Si tu viens tirer les 10G, il y aura statistiquement beaucoup plus de paquets qui seront pour toi, mais aussi qui seront droppé.
Mais ceux qui consomment tranquillou, eux aussi vont avoir du drop.

Et c'est avec ces drops que TCP va adapter le débit chez tout le monde, et où ça va se tasser.

Merci pour ces précisions, elles expliquent mes observations.
Est-ce qu'il existe un moyen pour différencier une saturation au niveau d'un l'arbre, d'une saturation en amont de l'OLT parce que ce lien n'est pas assez dimensionné, par exemple si tous les arbres sont à 50% à un moment donné ?

Non. Tu ne peux pas savoir, toi qui en en aval, toutes les décisions prises (ou non) sur tes paquets en amont.

Si l'ensemble de tes paquets arrive, tu seras incapable de dire si c'est parce que l'arbre est saturé ou non.
Par ex, si l'arbre est saturé, si ton trafic a fait l'objet d'une priorisation particulière, etc.