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 : > >> Bonjour >> Avec du multi session on obtient 280Mo >> Donc 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/
