Merci Le mar. 11 mai 2021 à 10:31, Fabien H <frnog.fab...@gmail.com> a écrit :
> 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/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
