Sylvain, quel est le temps de réponse que tu obtiens? Et quelle taille de window as-tu lors des transferts?
Le 15 février 2017 à 23:22, <sbu12...@gmail.com> a écrit : > 100Mb nous sommes en 2017…… en IDF… > > > > *De :* Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr] > *Envoyé :* mercredi 15 février 2017 17:52 > *À :* frnog@frnog.org; sbu123fr; Louis > *Cc :* Liste FRnoG > *Objet :* Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens > (MPLS) 500Mo mais plutot 5 x 100Mo > > > > 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/
