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> 
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 < <mailto:sbu12...@gmail.com> 
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/

Répondre à