Il y'a effectivement de la fragmentation sur le CPE sur le trafic montant. C'est un fonctionnement habituel. Normalement ton CPE est dimensionné selon le débit de ton lien, donc le CPU devrait suivre même avec un peu de fragmentation.
Sachant que la plupart du temps c'est le trafic descendant qui a le débit le plus élevé sur un lien donc le CPE ne subit pas de fragmentation dans le sens descendant (le LNS oui mais il est surement dimensionné) Le mar. 11 mai 2021 à 10:13, Kevin Thiou <kevinth...@gmail.com> a écrit : > Pour changer toujours dans le dépatouillage :) > > J'ai des comportements étranges. > > Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens > semblent fonctionner. > > Pour certains j'ai des problèmes de débit. > > Je me pose la question de la puissance du CPE, car dans beaucoup de cas il > y a un RB2011. > Je ne demande pas une solution mais juste une validation de ma réflexion. > > La station cliente (windows souvent) à une MTU à 1500, l'interface LAN > client sur le CPE a une MTU de 1500. > La session pppoe se retrouve avec une MTU à 1460. L'interface de > terminaison sur le cisco est aussi à 1460. > > Me trompè-je si je pense qu'une grosse partie de la fragmentation a lieu > sur le CPE ? > Et par conséquent si le CPE est un peu juste niveau CPU le débit s'écroule. > > Merci de vos lumières > > > Le mar. 4 mai 2021 à 23:21, Kevin Thiou <kevinth...@gmail.com> a écrit : > >> Je me posais justement la question des calculs théoriques. >> >> j'ai trouvé ca comme article : >> >> >> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/ >> >> >> Le mar. 4 mai 2021 à 23:10, David Ponzone <david.ponz...@gmail.com> a >> écrit : >> >>> J’ai pas osé te le suggérer :) >>> Le 2011, il commence à dater. >>> CHR dans une VM c’est pas mal pour les tests de BW. >>> >>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte >>> significative de bande passante (pas 70% en tout cas). >>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la >>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à >>> attendre. >>> >>> >>> Le 4 mai 2021 à 23:04, Kevin Thiou <kevinth...@gmail.com> a écrit : >>> >>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il >>> galère à envoyer plus ... >>> >>> Donc avec un serveur de test public mikrotik on atteint des valeurs bien >>> meilleurs. >>> >>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou <kevinth...@gmail.com> a écrit : >>> >>>> j'ai le même modèle. >>>> >>>> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et >>>> faire des tests croisés. >>>> >>>> Le mar. 4 mai 2021 à 22:53, David Ponzone <david.ponz...@gmail.com> a >>>> écrit : >>>> >>>>> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en >>>>> PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori). >>>>> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template. >>>>> >>>>> Donc je pense que ton problème est ailleurs. >>>>> Ou alors tu te méfies pas assez du CPU de ton MK. >>>>> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins >>>>> puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout >>>>> cas, qui limite le bandwidth-test). >>>>> >>>>> > Le 4 mai 2021 à 22:39, Kevin Thiou <kevinth...@gmail.com> a écrit : >>>>> > >>>>> > Je ne vais pas rentrer dans le c'est la faute à truc. >>>>> > Pour le moment, celui qui m'occupe ne commence pas par un S. >>>>> > >>>>> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai >>>>> perte de débit en tcp par rapport à l'udp par exemple. >>>>> > >>>>> > J'utilise l'outil de test de mikrotik qui donne des résultat que je >>>>> trouve acceptable. >>>>> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp. >>>>> > >>>>> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP >>>>> annoncée. >>>>> > >>>>> >>>>> >>> --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
