Auteur Sujet: Différences de performance entre testdebit.info et ftp.oleane.fr (Lu 6379 fois)

charly · « **le:** 29 novembre 2011 à 01:56:31 »

Quelqu'un peut il m'expliquer ces différences de débit :

Via google chrome (test fait en http et ftp via le nav les résultats sont les même)

Via FlashFXP :

testdebit.info :
5.5 mo/s de moyenne

ftp.oleane.fr :
Transferé: debian-6.0.3-i386-CD-1.iso 648,00 MB, 1 minute 1 seconde (10,59 MB/s)

Test fait a 1h du matin, dans les même conditions, a 10min d'interval

Pourquoi j'ai 2.5mo/s de différence sur le serveur testdebit.info quand j'utilise un client ftp, alors que j'ai aucune différence sur le serveur ftp de oleane
Et pourquoi un débit doublé sur un serveur de chez orange/ft ? alors que si j'ai bien compris le tracert, le serveur oleane serrait plus "loin"

Merci a vous !

Boris de Bouygues Telecom · « **Réponse #1 le:** 29 novembre 2011 à 13:44:49 »

testdebit.info est un serveur récent et ftp.oleane.fr est un serveur plus ancien.

La fonction "TCP ACK Suppression" qui entraîne des surpression d'acquittements TCP en upload est aujourdh'ui utilisé sur de nombreux accés Internet avec un débit fortement asymétrique.

Nous avons noté un fort impact sur le débit pour les serveurs avec un noyau linux récent (< 2ans). Aucun impact si le noyau est ancien (> 2ans).

Du coté de Bouygues Telecom nous travaillons :
- A supprimer rapidement "TCP ACK Suppression" de notre Bbox
- Mettre en place des serveurs de test de débit avec un noyeau plus ancien.

En attendant, nous déconseillons l'utilisation du serveur SpeedTest d'Aubervilliers et de testdebit.info. Il faut préférer le serveur SpeedTest de Paris et http://test-debit.free.fr/ (votre Serveur Oleane semble également posséder un bon débit)

Pour en savoir plus sur TCP ACK Suppression :

TCP ACK Suppression

TCP ACK Suppression overcomes the TRGC limitation without actually affecting the DOCSIS specification or involving the CMTS. It improves downstream TCP transmissions by taking advantage of TRGC and only sending the last ACK it receives when its data grant becomes active. Thus, the number of TCP ACKs is fewer, but the number of bytes acknowledged by each TCP ACK is increased.

Consider a user who is FTPing a file downstream. There will be a succession of ACKs sent at a rate proportional to the TCP data packets received. Assume that TCP ACKs are being sent every 1.5 ms on a system that has a TRGC of 4.5 ms.

When the cable modem receives the first TCP ACK from the CPE, it will send a request for bandwidth equivalent to one TCP ACK. Each ACK contains an acknowledgement number that corresponds to the byte in the transfer that is being acknowledged. All prior bytes are considered acknowledged.

In this example, TCP ACK #1 is acknowledging byte 1500, ACK #2 3000, and ACK #3 4500. The size of each ACK is equivalent. At time 4.5 ms, the TAS-enabled modem will have the opportunity to send one packet whose size is the length of a standard ACK packet.

Therefore, instead of sending ACK #1, the modem sends ACK #3. This is possible because the CM has received ACK #3 at T = 3.0 ms, has had time to inspect the packet, and has had time to make the switch before the grant becomes active. This grant, remember, was received as a result of the request sent after receiving ACK #1.

Without TAS enabled, the user's FTP was limited to about 222 ACKs per second x 1500 bytes per ACK x 8 bits per byte, or about 2.6 Megabits acknowledged per second. By enabling TAS, this maximum was increased to 222 ACKs per second x an average of 4500 bytes per ACK or about 8 Megabits acknowledged each second.

The benefit that TAS has over concatenation is that it not only increases downstream throughput but it also decreases the amount of bandwidth consumed in the upstream. However, TAS only works on TCP ACKs. It has no effect on any other traffic. Concatenation, on the other hand, works on all traffic.

Concatenation and TAS are not mutually exclusive. They operate independently, but they can operate at the same time.

The effect of using both simultaneously will be more downstream TCP bandwidth with less upstream overhead.

Source : CedMagazine.com, le 1er janvier 2007.

Boris de Bouygues Telecom · « **Réponse #2 le:** 30 novembre 2011 à 15:25:08 »

A noter que le test de débit proposé sur http://testdebit.bbox.fr/ n'est pas hébergé par Bouygues Telecom mais utilise le serveur de DeroupTest. Il n'est pas impacté par TCP ACK Supression mais limité pour les offres 100 Mb/s car le serveur est relié à 100 Mb/s à Internet et de nombreuses personnes font des tests dessus. Il est donc difficile d'avoir plus de 7à Mb/s.

Pour SpeedTest :
- Serveur de Lyon / 69 => Impacté par TCP ACK Supression
- Serveur de Paris / 75 => Non impacté par TCP ACK Supression - meilleur serveur pour les offres câble
- Serveur d'Aubervilliers / 93 => Impacté par TCP ACK Supression [cela va changer en janvier avec un downgrade vers un noyau linux ancien]
- Serveur de Clichy /92 => non testé
- Serveur de Roubaix / 59 => Le ping peut être double de la réalité

Les autres tests de débit basés sur la technologie SpeedTest / Ookla :
- Serveur de Numericable => Non impacté par TCP ACK Supression - Performances instables pour les abonnés Bbox.
- Serveur de DegroupTest / 59 (OVH - Debian) => Non impacté par TCP ACK Supression mais limité par son lien 100 Mb/s
- Serveur de Test-ADSL / 59 (OVH) => limité par son lien 100 Mb/s

Boris.

charly · « **Réponse #3 le:** 23 décembre 2011 à 02:28:29 »

Nouveaux tests avec les serveurs optimisés de testdebit.info :

Tests de téléchargements :

FTP :
- FTTH : Transferé 1 Fichier (119,21 MB) en 40,86 secondes (2,95 MB/s)

- FTTLA : Transferé 1 Fichier (1,16 GB) en 1 minute 51 seconde (10,73 MB/s)

En HTTP :
- FTTH :

- FTTLA :

Speedtest.net :

- Aubervilliers

- Paris

Pourquoi la différence constatée entre les serveurs avec et sans optimisation TCP ACK en téléchargement (ftp/http 30mb > 100mb) n'est pas la même que celle constatée sur speedtest 65mb > 95mb ?

vivien · « **Réponse #4 le:** 23 décembre 2011 à 11:27:19 »

Citation de: charly le 23 décembre 2011 à 02:28:29

Pourquoi la différence constatée entre les serveurs avec et sans optimisation TCP ACK en téléchargement (ftp/http 30mb > 100mb) n'est pas la même que celle constatée sur speedtest 65mb > 95mb ?

Très bonne question. Pour l'expliquer il faut détailler la méthodologie utilisée par SpeedTest pour le très haut débit.

SpeedTest utilise 4 connexions TCP en parallèle. Objectif : diminuer au maximum les limitations de débit par connexion TCP comme la RWin limitée de Windows qui ne permet pas de monter a 100Mb/s dès que la latence n'est pas extrêmement faible ou TCP ACK Supression.

TCP ACK Suppression limite le débit par connexion TCP. Il est toujours possible de "remplir" le tuyau en établissant de multiple connexions TCP.

Méthodologie SpeedTest :

Download (en trés haut débit) : Téléchargement en parallèle de deux fichiers de 4,3 Mo chacun, puis deux fichiers de 7,5 Mo et enfin 4 fichiers de 30,2 Mo soit un total de 145 Mo. Le débit relevé n'est pas le débit moyen mais le débit en régime établi.

Upload : Émission en parallèle sur 4 connexions TCP jusqu'à ce que le débit soit stable. Le débit relevé est le débit en régime établi.

Ping : Moyenne de 10 « ping » http (GET de 453 octets et réponse de 336 octets).

De nombreux autres tests sur le net n'utilisent qu'une connexion TCP et prennent le débit moyen sur un petit fichier. Dans ces conditions les débits sont plus que médiocre pour les connexions câble.