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-throughput-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/

Répondre à