Totalement cohérent alors. Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr <sbu12...@gmail.com> a écrit : >C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ >en "mono" 100 et des bananes > >-------- Message d'origine -------- >De : Louis <luigi.1...@gmail.com> >Date : 15/02/2017 17:22 (GMT+01:00) >À : sbu123fr <sbu12...@gmail.com> >Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG ><frnog@frnog.org> >Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais >plutot 5 x 100Mo > >Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est >assez fiable. Pas de lecture disque >Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit : >280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le >débit. Avec un transfert multi-session, la tête de lecture/écriture >d'un disque classique est obligé de faire en permanence des >aller-retours. >Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit : >BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo >sur la chaîne de liaison > >-------- Message d'origine -------- >De : Ducassou Laurent <laurent.ducas...@spaceshell.fr> >Date : 15/02/2017 16:36 (GMT+01:00) >À : frnog@frnog.org >Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x > 100Mo > >Plus simplement : > >Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS >500Mbit/s. > >Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est > >que chaque site est relié que avec une fibre optique à 100Mbit/s. > >Ca arrive souvent dans les nuages MPLS des DSP ce "problème de >compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le >client final crois disposer de 500Mbit/s entre chaque site, mais en >réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à >100Mbit/s sur D et que E est au repos. > >Je crois avoir compris cela... > > >Le 15/02/2017 à 15:35, Louis a écrit : >> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait >plus >> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping. >> >> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre >sites). >> >> "Mais mon fournisseur de collecte m'explique que sur son service IP >MPLS >> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max >sur >> une session TCP entre 2 liens" >> >> >> >> Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit >: >> >>> Oui mais non, >>> >>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur >tous les >>> liens de façon parfaitement aléatoire, souvent les équipements >balancent le >>> trafic de manière *déterministe* sur l'un des liens physiques, en se >basant >>> sur le couple adresse source-destination, cela peut-être Adresse IP >source >>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois >peut-être >>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des >>> exceptions, et sûrement des solutions propriétaires. >>> >>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas >>> (exception faite des solutions propriétaires ou solutions non >déterministes >>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir >plus de >>> 100Mbps sur un LAG 5x100Mbps pour un même flux. >>> >>> cordialement, >>> >>> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>: >>> >>>> Après quelques recherche, j'arrive à la conclusion que la >limitation du >>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les >500Mbps >>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des >paramètres >>>> de l'OS. >>>> >>>> L'article de 2005 ne précise pas les valeurs de window size >utilisées. Sur >>>> les (très) vieux OS, la valeur maxi de window size était 65535 >octets >>>> parce >>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, >la RFC >>>> 1323 est largement utilisée. Elle introduit un paramètre window >size >>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de >window >>>> size. Le window size est étendu 16Mo au lieu de 64Ko. >>>> >>>> Calculateur de bande passante sur une session TCP : >>>> https://www.switch.ch/network/tools/tcp_throughput/ >>>> Pour la formule, c'est ici : >>>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu >>>> ghput-for-long-distance-links/ >>>> >>>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s >max), il >>>> faudrait une taille window de ~1800 Ko. >>>> >>>> Il faut regarder les paramètres de l'OS pour voir si les paramètres >>>> permettent d'avoir une window de cette taille. >>>> >>>> Sur les windows récents, les paramètres sont décrits ici : >>>> http://www.speedguide.net/articles/windows-8-10-2012-server- >>>> tcpip-tweaks-5077 >>>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows >7, le >>>> paramètre est normal. >>>> >>>> c:\>netsh interface tcp show global >>>> >>>> Paramètres TCP globaux >>>> ---------------------------------------------- >>>> État de mise à l'échelle côté réception : enabled >>>> État de déchargement Chimney : automatic >>>> État NetDMA : enabled >>>> Accès direct au cache : disabled >>>> *Réglage auto fenêtre de réception : normal* >>>> >>>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille >de >>>> window >>>> maxi associée à ce paramètre "normal". >>>> >>>> Il faudrait tester un téléchargement depuis un windows d'un gros >fichier >>>> avec une liaison >500 Mbps. Par exemple >http://ovh.net/files/1Gio.dat . >>>> On >>>> verrait quel débit on obtient et Wireshark pourrait donner la >taille de >>>> window. >>>> >>>> Louis >>>> >>>> Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a >écrit : >>>> >>>>> 40Kms grand max....... >>>>> >>>>> Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a >>>> écrit : >>>>>> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la >lumière. >>>>>> Donc tout dépend de la distance entre le point de départ et >d'arrivée. >>>>>> >>>>>> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler < >>>>>> michel.hostett...@telecom-paristech.fr> a écrit : >>>>>>> Bonjour, >>>>>>> >>>>>>> Est-ce encore plausible de nos jours, un temps d'aller retour de >30 >>>> ms ? >>>>>>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas >>>> évolué depuis 12 ans. >>>>>>> Cordialement, >>>>>>> Michel >>>>>>> >>>>>>> ----- Mail original ----- >>>>>>> De: "Louis" <luigi.1...@gmail.com> >>>>>>> À: "sbu123fr" <sbu12...@gmail.com> >>>>>>> Cc: "frnog-tech" <frnog-t...@frnog.org> >>>>>>> Envoyé: Mercredi 15 Février 2017 10:28:06 >>>>>>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais >plutot 5 x >>>> 100Mo >>>>>>> Probablement oui : >>>>>>> >>>>>>> http://smutz.us/techtips/NetworkLatency.html >>>>>>> >>>>>>> *Round trip latency* >>>>>>> >>>>>>> *TCP Throughput with no packet loss* >>>>>>> >>>>>>> *TCP Throughput with 2% packet loss* >>>>>>> >>>>>>> 0 ms >>>>>>> >>>>>>> 93.50 Mbps >>>>>>> >>>>>>> 3.72 Mbps >>>>>>> >>>>>>> 30 ms >>>>>>> >>>>>>> 16.20 Mbps >>>>>>> >>>>>>> 1.63 Mbps >>>>>>> >>>>>>> 60 ms >>>>>>> >>>>>>> 8.07 Mbps >>>>>>> >>>>>>> 1.33 Mbps >>>>>>> >>>>>>> 90 ms >>>>>>> >>>>>>> 5.32 Mbps >>>>>>> >>>>>>> 0.85 Mbps >>>>>>> >>>>>>> Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput >>>>>>> >>>>>>> Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a >écrit : >>>>>>> >>>>>>> Grand merci. >>>>>>>> Tu pense que sur des liens en île de france la latence est >telle >>>> que le >>>>>>>> trafic peut être divisé par 4-5? >>>>>>>> Cdt >>>>>>>> Sbu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -------- Message d'origine -------- >>>>>>>> De : Louis <luigi.1...@gmail.com> >>>>>>>> Date : 14/02/2017 18:05 (GMT+01:00) >>>>>>>> À : Sylvain sbu <sbu12...@gmail.com> >>>>>>>> Cc : frnog-tech <frnog-t...@frnog.org> >>>>>>>> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x >100Mo >>>>>>>> >>>>>>>> cela dépend surtout du temps de réponse sur les liens. On >perd en >>>> débit à >>>>>>>> cause des acquittements nécessaires à TCP. Les durées >d'acquittement >>>>>>>> s'accroissent avec les temps de réponse. Pendant ce temps là, >pas >>>> de donnée >>>>>>>> utile ne transite. >>>>>>>> >>>>>>>> Effectivement, un fenêtrage plus haut (window) permet >d'améliorer >>>> les >>>>>>>> performances en augmentant le nombre de paquets reçus avant >>>> acquittements. >>>>>>>> Cela fonctionne bien du moment qu'il n'y a pas de perte sur >les >>>> liens. >>>>>>>> Le fenêtrage est dynamique sur les serveurs en fonction de la >>>> qualité de >>>>>>>> la connexion. Les derniers OS ont des valeurs par défaut >optimisées >>>> mais >>>>>>>> qu'on peut tuner je crois. >>>>>>>> >>>>>>>> L'autre solution est d'optimiser le trafic TCP avec des >optimiseurs >>>> de >>>>>>>> trafic. Il existe pas mal d'équipements sur le marché qui >jouent >>>> entre >>>>>>>> autre sur les paramètres window TCP. >>>>>>>> >>>>>>>> Je suppose que le débit est voulu pour des gros transferts de >>>> fichier. >>>>>>>> Souvent, la solution adoptée est d'utiliser des outils qui >>>> parallélisent le >>>>>>>> transfert du même fichier sur plusieurs sessions TCP. >>>>>>>> >>>>>>>> cordialement, >>>>>>>> >>>>>>>> Louis >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Le 14 février 2017 à 16:45, Sylvain sbu <sbu12...@gmail.com> >a >>>> écrit : >>>>>>>> Bonjour, >>>>>>>>> Non rien a voir avec du hachage car en changeant un >paramétrè de >>>>>>>>> "fenêtre" il est possible d'augmenter le max traffic a 75% >des >>>> 500Mo. >>>>>>>>> cdt >>>>>>>>> SBU >>>>>>>>> >>>>>>>>> Le 14 février 2017 à 16:41, Dominique Rousseau ><d.rouss...@nnx.com> >>>> a >>>>>>>>> écrit : >>>>>>>>> >>>>>>>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [ >>>>>>>>>> sbu12...@gmail.com] a écrit: >>>>>>>>>> >>>>>>>>>>> Bonjour, >>>>>>>>>>> Je ne suis pas spécialiste du transport IP. >>>>>>>>>>> Mais mon fournisseur de collecte m'explique que sur son >service >>>> IP MPLS >>>>>>>>>>> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de >>>> trafic max >>>>>>>>>> sur >>>>>>>>>> >>>>>>>>>>> une session TCP entre 2 liens >>>>>>>>>>> >>>>>>>>>> Tes "4 liens", je suppose que c'est "5", avec de >l'aggregation. >>>>>>>>>> >>>>>>>>>> La limitation indiquée par ton fournisseur n'est pas >étonnante. >>>>>>>>>> Elle correspond aux algorithmes de répartition entre les >liens >>>> faisant >>>>>>>>>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée >sur les >>>>>>>>>> adresses MAC source et destination, par exemple. Ce hachage >sert à >>>>>>>>>> "choisir" l'un des liens faisant partie de l'aggregat, et >tout le >>>> trafic >>>>>>>>>> correspondant a cette meme clef de hachage utilisera le >meme lien. >>>>>>>>>> Tut te trouves alors limité par la capacité physique du >lien >>>>>>>>>> sélectionné. >>>>>>>>>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun >doit >>>> avoir une >>>>>>>>>> capacité de 100Mbps, et donc la limitation s'explique. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dominique Rousseau >>>>>>>>>> Neuronnexion, Prestataire Internet & Intranet >>>>>>>>>> 21 rue Frédéric Petit - 80000 Amiens >>>>>>>>>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - >>>> http://www.neuronnexion.coop >>>>>>>>>> >>>>>>>>>> --------------------------- >>>>>>>>>> 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/ >>>>>>> >>>>>>> >>>>>> -- >>>>>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma >>>>>> brièveté. >>>>>> >>>>> >>>> --------------------------- >>>> 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/ > > > > > >--------------------------- >Liste de diffusion du FRnOG >http://www.frnog.org/
-- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
