Re: [FRnOG] [BIZ] Recherche Rails HP DL360e Gen8
Plop, Le 10/05/2021 à 22:42, Guillaume CREPIEUX via frnog a écrit : Je suis à la recherche de rail pour un HP ProLiant DL360e Gen8. Un broker proche de chez moi me les sors à 105€ H.T. pour la ref 734807-B21, contre 60 à 80€ chez d'autres ailleurs en Europe. Si tu trouves mieux ça peut m'intéresser ! @+ -- Jérôme Nicolle +33 6 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration
> Le 11 mai 2021 à 10:29, Fabien H 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é) > Je corrige, je pense que tu voulais dire que les paquets sortants sont statistiquement plus petits puisqu’il s’agit essentiellement de requêtes HTTP (on va dire 200-300 octets en moyenne), donc pas besoin de frag. Le CPU est impacté de la même manière qu’on fragmente un gros ou un petit paquet, mais effectivement, le gros de la fragmentation, c’est le LNS. Mais le CPE va être sollicité pour ré-assembler les 2 paquets, défrag quoi, et sans ASIC, ça doit prendre autant de CPU que la frag. Donc à vue de nez, l’impact est le même pour les 2 côtés, sauf que voilà, on va pas comparer un ASR avec un RB2011 :) Kevin, Pour revenir au RB2011, il est donné pour 800Mbps en routage avec fastpath. Tu es sûr que tu as fast-path activé ? Y a pas mal de trucs qui vont le désactiver, donc à ta place, je regarderais plutôt les perfs avec des filtres IP (j’imagine que tu en as), soit autour de 400Mbps. Mikrotik est pas très clair sur tout ça, comme tous les constructeurs d’ailleurs. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration
On Tue, May 11, 2021 at 11:29 AM Alexis Lameire wrote: > Hello, > Je rajouterais une information supplémentaire. Avec la négo de la MSS en > TCP cette impact est d'autant moins visible ! Finalement le trafic UDP, > hormis le DNS, il ne reste plus grand monde. > > Gene les VPN en tout genre, les services Google qui utilise tous UDP (sur chrome en tout cas), c'est négligeable ? > Cordialement > Alexis > > Le mar. 11 mai 2021 à 10:34, Kevin Thiou a écrit : > > > Merci > > > > Le mar. 11 mai 2021 à 10:31, Fabien H 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 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 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 > 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 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 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 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 p
Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration
Hello, Je rajouterais une information supplémentaire. Avec la négo de la MSS en TCP cette impact est d'autant moins visible ! Finalement le trafic UDP, hormis le DNS, il ne reste plus grand monde. Cordialement Alexis Le mar. 11 mai 2021 à 10:34, Kevin Thiou a écrit : > Merci > > Le mar. 11 mai 2021 à 10:31, Fabien H 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 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 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 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 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 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 > 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 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/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration
Merci Le mar. 11 mai 2021 à 10:31, Fabien H 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 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 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 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 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 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 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 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/
Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration
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 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 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 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 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 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 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 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/
Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration
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 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 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 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 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 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 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/
