Auteur Sujet: SFR utilise le serveur SpeedTest de Massy - Performances de linux 2.6.24 (Lu 7269 fois)

vivien · « **le:** 08 octobre 2012 à 22:48:31 »

SFR viens de lancer une publicité qui met en avant les tests de débit sur la 3G+ Dual Carrier.

Le Dual Carrier permet de doubler le débit pour le client en utilisant deux porteuses. Même dans des conditions radio dégradées là ou vous auriez 1 Mb/s avec une seule fréquence, vous aurez 2 Mb/s avec deux fréquences :

A noter que Free Mobile ne peux pas faire de Dual Carrier, n'ayant pas deux plages consécutives en 3G.

Le serveur utilisé est le serveur SpeedTest de Massy :

Un hasard l'utilisation par SFR du serveur de Massy, hébergé par Bouygues Telecom ?

Probablement pas. Orange, Bouygues Telecom ou Numericable ont déjà conseillé ce serveur à leurs clients.

Un abonné Orange FTTH sur Toulouse a fait des tests comparatif de différents serveurs SpeedTest :

Citation de: thenaing le 02 mai 2012 à 01:15:11

Fait a 1h15 (heure du post), même config pour ma part.

Les serveurs récents ont les performances qui s'écroulent avec de la latence conjugué aux pertes de paquets observées sur Orange FTTH ou les pertes d’acquittements (TAS) observées chez Numericable / Bouygues Teleocm / Darty / Auchan Box.
=> Êtes-vous impactés par "TCP ACK Suppression" ?

vivien · « **Réponse #1 le:** 08 octobre 2012 à 22:50:20 »

Quel est le secret du serveur SpeedTest de Massy ?

Ce n'est pas un serveur représentatif de ce que l'on trouve sur Internet aujourd'hui.
C'est en effet un vieux Linux, Ubuntu 8.04 LTS 64bits alors que presque tous les serveurs sur Internet sont passés sur des versions plus récentes.
Je remercie au passage le groupe Mediactive qui m'a permis de découvrir les excellentes performances des vieux serveurs linux

Pourquoi le noyau linux 2.6.24 a de si bonnes performances ?

C'est l'un des dernier noyau a ne pas prendre certaines options de TCP offload engine - Segmentation et Checksum réalisée par la carte réseau pour décharger le CPU.

Lorsque la segmentation est déchargée sur la carte réseau, nous obtenons la figure ci-dessous. Le système d'exploitation ne segmente pas les données d'application, mais crée plutôt un grand paquet TCP / IP et l'envoie au conducteur. Les en-têtes TCP et IP sont en fait des en-têtes de modèle . Le conducteur crée une seule trame Ethernet (qui est capturé par Wireshark) et l'envoie à la carte réseau. Quand la carte réseau effectue la segmentation, elle utilise les en-têtes de modèles pour créer des trames Ethernet avec 5 vraies en-têtes TCP/IP Ethernet. Les 5 images sont ensuite envoyées sur le réseau :

Régulièrement de nouvelles optimisations sont pris en charge par linux et les nouvelles cartes réseaux afin de décharger le processeur et certaines semble avoir des effets négatif en terme de performance réseau si des pertes de paquet ou d’acquittement sont présentes.

Voici ce que j'ai quand je tape la commande ethtool -k eth0 sur le serveur de Massy :
# sudo ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on udp fragmentation offload: off generic segmentation offload: off

Sur les noyaux plus récents de nouvelles possibilité de déchargement vers la carte réseau sont disponibles => pus de précisions sur TCP offload engine.
Il est possible de s’approcher des performances d'Ubuntu 8.04 en mettant a off tcp-segmentation-offload et generic-segmentation-offload.

Je dit s’approcher car je ne retrouve pas exactement les même performances alors qu'on devrait s'attendre à les dépasser, des évolutions ayant été faites sur les nouveaux noyaux comme le patch google qui consiste a passer l'Initial Congestion Window de 3 segments a 10 segments. Cette innovation Google, introduite de le noyau 2.6.39 et suivant permet de monter bien plus vite en débit et mieux garder ce débit maximum. Voici un cas ou le gain est très important :

Bref, si certaines personnes ont des connaissances sur le sujet et peuvent m'aider à mettre en place un serveur de Massy encore plus performant, je suis preneur !

Nico · « **Réponse #2 le:** 08 octobre 2012 à 22:56:33 »

Citation de: vivien le 08 octobre 2012 à 22:48:31

A noter que Free Mobile ne peux pas faire de Dual Carrier, n'ayant pas deux plages consécutives en 3G.

On en parle beaucoup mais est-ce que tu as un lien vers l'explication "technique" de cette limitation ?

Sinon vivien, le Dual Carrier ça marche bien aussi vers ton serveur :

Leon · « **Réponse #3 le:** 09 octobre 2012 à 06:38:11 »

Citation de: vivien le 08 octobre 2012 à 22:50:20

Quel est le secret du serveur SpeedTest de Massy ?

Ce n'est pas un serveur représentatif de ce que l'on trouve sur Internet aujourd'hui.
C'est en effet un vieux Linux, Ubuntu 8.04 LTS 64bits alors que presque tous les serveurs sur Internet sont passés sur des versions plus récentes.

Vivien, pour ton article, j'avoue que je n'ai pas tout compris. Ca veut dire que l'ancien noyau, qui n'a pas les options "TCP Offload Engine", ni la modification de "l'initial condition window" est plus performant? Pourquoi? C'est quand même bizarre.

Leon.

thenico · « **Réponse #4 le:** 09 octobre 2012 à 07:31:48 »

Il est plus performant dans certaines conditions car son non-support des options d'offloading empêche le déclenchement de bug dans la carte réseau (offloading ~= morceau de la stack réseau dans la carte réseau).
Maintenant sur ta LAN ou sur un réseau qui ne fait pas d'optimisation exotique, ça ne sera pas le cas...

vivien · « **Réponse #5 le:** 09 octobre 2012 à 08:31:06 »

Les noyaux linux 2.6.39 et suivant montent bien plus vite en débit, et c'est toujours un plus.

Maintenant les noyaux de moins de 4ans on un débit qui est limité en cas de perte de paquets ou de perte d’acquittement dès que le ping augmente. Rien ne sert de monter vite en débit si on est limité à 30 Mb/s.

=> Sans perte de paquet les nouveaux noyaux avec les optimisations google sont plus rapide
=> Avec perte de paquet ou d’acquittement, les anciens noyaux sont plus rapide.

Dans le cas de SFR, je suis surpris (d'où ce post), je pensais que les noyaux récents avec toutes les optimisations seraient plus performant.

thenico, je me suis demandé si c'était une mauvaise implèmentation de TOE par Broadcom mais il n'en est rien : avec une carte réseau Nvidia j'ai le même souci quand TOE est activé.

C'est un constat. Je cherche toujours l'explication pour comprendre ce phénomène.

Citation de: Nico le 08 octobre 2012 à 22:56:33

On en parle beaucoup mais est-ce que tu as un lien vers l'explication "technique" de cette limitation ?

Je lance cet appel dans l'espoir que une personne puisse m'expliquer...

Nico · « **Réponse #6 le:** 09 octobre 2012 à 08:51:56 »

Citation de: vivien le 09 octobre 2012 à 08:31:06

Dans le cas de SFR, je suis surpris (d'où ce post), je pensais que les noyaux récents avec toutes les optimisations seraient plus performant.

En fait je me pose une question, est-ce que ça a été fait intentionnellement de choisir le speedtest de Massy ? Encore ça aurait été un test par l'ingé, je veux bien, mais pour une pub, j'ai comme un doute.

thenico · « **Réponse #7 le:** 09 octobre 2012 à 16:47:51 »

Citation de: Nico le 09 octobre 2012 à 08:51:56

En fait je me pose une question, est-ce que ça a été fait intentionnellement de choisir le speedtest de Massy ? Encore ça aurait été un test par l'ingé, je veux bien, mais pour une pub, j'ai comme un doute.

Même les gens du Marketing sont capable de d'optimiser les résultats (surtout pour une pub).
Il suffit qu'ils aient testés plusieurs serveurs, vu que Massy donnait toujours un résultat supérieur et ne sont probablement pas allez plus loin.