Auteur Sujet: Êtes-vous impactés par "TCP ACK Suppression" ? (Lu 11027 fois)

vivien · « **Réponse #96 le:** 03 août 2012 à 09:17:45 »

Pour moi tu es optimisé. C'est un très bon débit pour Windows XP.

butler_fr · « **Réponse #97 le:** 03 août 2012 à 19:46:20 »

voila mes résultats (sous archlinux 64 3.4.7-1) !
bon ba y a pas photo^^

wget -O /dev/null http://90ms.testdebit.info/fichiers/3Gb.dat --2012-08-03 19:18:50-- http://90ms.testdebit.info/fichiers/3Gb.dat Résolution de 90ms.testdebit.info... 89.82.180.22 Connexion vers 90ms.testdebit.info|89.82.180.22|:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 375000000 (358M) [application/x-ns-proxy-autoconfig] Sauvegarde en : «/dev/null» 100%[======================================>] 375 000 000 579K/s ds 10m 22s X 2012-08-03 19:29:13 (588 KB/s) - «/dev/null» sauvegardé [375000000/375000000] $ wget -O /dev/null http://90ms.cable.testdebit.info/fichiers/3Gb.dat --2012-08-03 19:32:01-- http://90ms.cable.testdebit.info/fichiers/3Gb.dat Résolution de 90ms.cable.testdebit.info... 89.84.127.53 Connexion vers 90ms.cable.testdebit.info|89.84.127.53|:80...connecté. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 375000000 (358M) [application/x-ns-proxy-autoconfig] Sauvegarde en : «/dev/null» 100%[======================================>] 375 000 000 3,65M/s ds 1m 45s 2012-08-03 19:33:47 (3,39 MB/s) - «/dev/null» sauvegardé [375000000/375000000] $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8. 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=33.1 ms From 192.168.1.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.254) 64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=31.7 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=26.7 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=36.0 ms ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 26.784/31.928/36.074/3.364 ms bbox: Canaux descendants Canal Statut Modulation ID du canal Fréquence Puissance SNR 1 connecté QAM256 85 122000000 Hz 0.1 dBmV 42.7 dB 2 connecté QAM256 89 434000000 Hz 4.4 dBmV 42.4 dB 3 connecté QAM256 90 442000000 Hz 4.2 dBmV 41.9 dB 4 connecté QAM256 91 450000000 Hz 4.3 dBmV 42.0 dB Canaux montants Canal Statut Type de canal montant ID du canal Symbol rate Fréquence Puissance 1 activé TDMA 4 5120 Ksym/sec 52500000 Hz 51.7 dBmV

lordzurp · « **Réponse #98 le:** 04 août 2012 à 01:38:16 »

hello

j'ai refait un test ce soir (avec enfin une ligne qui marche bien !), sur mon serveur (FreeBSD 9.0), toujours avec le modem Ubee de MammouthTelecom ( 3 porteuses en down)
580Ko/s contre 2,6Mo/s

vivien · « **Réponse #99 le:** 04 août 2012 à 08:31:08 »

Oui, vous êtes tous les deux impactés.

Branco · « **Réponse #100 le:** 08 août 2012 à 12:17:02 »

@TOUS

Une piste à creuser...c'est très intéressant ! le pb de buffer sur les modems cable (BufferBloat)

Je suis tombé sur ce post de GC sur pb de débit Netgear CG 3100L

En gros, le client constate une chute de débit de son modem au bout de 10 jours, un simple reboot électrique du modem suffit et le débit max redevient normal.
Un gus du forum parle alors d'un pb de bufferbloat.

@Vivien
J'ai lu dans ton forum un article de pb de latence avec le BufferBloat sur des serveurs Linux
Ca craint si ce pb de buffer impacte aussi certains modems cable, cela doit parasiter avec la fonction TAS activée par dessus $:-\$

Rapport d'analyse sur le sujet du Cable Modem Buffer Control (en Anglais technique)
Analyse Septembre 2011 du mécanisme Buffer Control sur les modems cable
=> La recommandation des experts docsis serait d'avoir un modem avec un buffer d'une taille de 32 Ko pour un débit upstream de 5Mbps par exemple

Il est dit aussi que la plupart des CMTS ne supporte pas le contrôle du buffer upstream et qu'un seul équipementier le fait actuellement.

Citer

At the time of publication of this document, support for Buffer Control by CMTS vendors is seriously lacking.
While all vendors have plans to implement it, currently only one CMTS vendor supports CM (upstream) Buffer
Control (via the Minimal Implementation only). No CMTS vendors support CMTS (downstream) Buffer Control.

Je n'ai pas encore trouvé quel CMTS le fait aujourd'hui (peut-être Cisco, peut-être Casa Systems le nouveau CMTS installé à Metz...)

En résumé:
1/ Certains modems cable auraient ce pb de buffer en upstream
2/ Le pb de BufferBloat provoque une chute de débit au bout de qq jours et il faut rédemarrer le modem pour corriger.
3/ Le CMTS a un impact sur le buffer upstream du modem lors d'un téléchargement TCP

Donc c'est un sujet à creuser je pense !
J'espère que Bouygues et Numericable sont au courant de ce phénomène...

vivien · « **Réponse #101 le:** 08 août 2012 à 12:47:22 »

Pour les buffers il est question de les réduire sur Linux de façon à les adapter dynamiquement à la taille idéale. (Si une situation de famine (starvation) est détectée, alors c'est que le tampon de gestion était trop petit et il est donc agrandi. En revanche, si le nombre d'octets du tampon ne descend jamais sous une certaine limite, alors cela veut dire qu'il est possible de diminuer le tampon d'autant.)

Au niveau des systèmes réseaux, certains opérateurs (par exemple Free mobile sur son réseau propre) ont par contre des équipements avec des buffers trop petits qui ne sont pas adaptés aux serveurs récents qui envoient les données par gros paquets. Ce type de comportement peut être détecté également par un test de débit en téléchargeant sur http://testdebit.info un fichier du serveur "avec TCP offload engine" et un fichier du serveur "(sans TCP offload engine)". Si le débit est meilleur sur le serveur sans TOE c'est qu'il y a un souci ("TCP ACK Supression", buffer trop petit, ou encore un autre souci).

Branco · « **Réponse #102 le:** 08 août 2012 à 18:53:30 »

Avant même de parler d'optimiser le serveur Linux, là on parle d'un problème de performance TCP entre entre le CMTS et le modem.

Le contrôle du buffer modem en upstream est obligatoire depuis le 21/12/2011 dans la spécification DOCSIS 3.0.

Que devrait faire l'opérateur ?

1/Upgrader ses CMTS pour supporter le "Buffer Control"
Il faut que le CMTS soit compatible, et le software doit être minimum 12.2(33)SCF2, j'ignore quelle est la version des CMTS NC

2/Modifier ses fichiers de configuration modem avec les nouveaux paramètres
D'après les conclusions du rapport CableLabs, voici les nouveaux TLV à rajouter dans la partie "Upstream Service Flow" (pour ceux qui connaissent...sinon désolé pour le charabia technique).

/* Upstream minimum buffer */
Type 24.35.1
Length 4
Value 0 (par défaut et c'est recommandé)

/* Upstream target buffer */
Type 24.35.2
Length 4
Value 8192 pour l'offre 30M/1M; 32768 pour le 100M/5M

/* Upstream maximum buffer */
Type 24.35.3
Length 4
Value 0 (par défaut et c'est recommandé)

Allez au boulot messieurs !

corrector · « **Réponse #103 le:** 09 août 2012 à 03:57:21 »

Citation de: vivien le 08 août 2012 à 12:47:22

(Si une situation de famine (starvation) est détectée, alors c'est que le tampon de gestion était trop petit et il est donc agrandi. En revanche, si le nombre d'octets du tampon ne descend jamais sous une certaine limite, alors cela veut dire qu'il est possible de diminuer le tampon d'autant.)

Autrement dit : la file d'attente au supermarché doit juste servir à lisser les irrégularités dans l'arrivée des clients à la caisse. (En aucun cas ce n'est un moyen de gérer une insuffisance persistante du nombre de caissières par rapport au nombre de client. C'est une bourde que font de nombreuses personnes. Posez la question autour de vous : "à quoi correspond une file d'attente?" Certaines de ces personnes sont des ingénieurs apparemment.)

J'ajoute que la longueur des files d'attente dans un supermarché est principalement un indicateur du délai qu'il faut au responsable pour augmenter le nombre de caisses ouvertes, donc à son indolence (ou à sa connerie).

zorly · « **Réponse #104 le:** 13 août 2012 à 12:01:04 »

Bonjour, je suis nouveau ici et en faisant des recherche sur certaine de met lenteur sur les jeux en ligne PSN avec numericable offre power 100/5m à sarreguemines je suis tombé ici j'ai fais le test page 1 et sa donne ceci :
Test 1 : 1.91Mo/s
Test 2 : 1.98Mo/s

Resultat speedtest
Massy : Ping 15ms
Descendant 101.02Mbps
Montant 4.91Mbps
Paris ( mediactive ) Ping 25ms
Descendant 37.21Mbps
Montant 4.90Mbps

Les canaux du modem :

Code: [Sélectionner]

Canal de réception
Statut	Modulation	Canal	Débit de symboles	Fréquence	              Puissance	    SNR
Acquis	QAM256	                117	6952000 sym/sec	410000000 Hz	              1.8 dBmV	    37.5 dB
Acquis	QAM256	                  7	6952000 sym/sec	402000000 Hz	              1.1 dBmV	    36.5 dB
Acquis	QAM256	                118	6952000 sym/sec	418000000 Hz	              1.7 dBmV	    37.4 dB
Acquis	QAM256	                119	6952000 sym/sec	426000000 Hz	              1.6 dBmV	    37.5 dB
Acquis	QAM256	                120	6952000 sym/sec	434000000 Hz	              1.4 dBmV	    37.4 dB
En cours	Inconnu		              0 sym/sec 	0 Hz	                             0.0 dBmV     0.0 dB
En cours	Inconnu		              0 sym/sec 	0 Hz	                             0.0 dBmV     0.0 dB
En cours	Inconnu		              0 sym/sec 	0 Hz	                             0.0 dBmV     0.0 dB


Canal d'émission
Statut de l'enregistrement	Modulation	ID de canal	Débit de symboles	Fréquence	Puissance
Acquis	                             ATDMA	                      3	               5120 Ksym/sec	60400000 Hz	40.0 dBmV
Non acquis	                  Inconnu		                              0 Ksym/sec	0 Hz	               0.0 dBmV
Non acquis	                  Inconnu		                              0 Ksym/sec	0 Hz	               0.0 dBmV
Non acquis	                  Inconnu		                              0 Ksym/sec	0 Hz	               0.0 dBmV

Cella fais un moment que je pense que numericable triche sur les connection car lors de test je n'ai jamais des resultat identique entre chaque serveur, mes telechargement divers ( 01.net, clubic, samsung, asus, linux ect.. ) sont tres souvent au desus de 10Mo/s et lors des jeux en ligne j'ai de grosse hachurecomme si il manqué des donné par moment, pendant 2 minutte je peut avoir de l'avance et apres pendant 5 min du retard et toujour avec des deplacement en sacade.

Si cella peut aidez quelqu'un ou si vous avez une solution pour m'aidez sa serait cool!
Cordialement

PS : désolé pour le desorde dans les canal mais j'ai pas reussi a faire mieux!

vivien · « **Réponse #105 le:** 13 août 2012 à 12:50:19 »

Étonnant, tes deux tests de débit sont assez proche (2 Mo/s) ce qui tendrais a dire que tu n'est pas impacté par "TCP ACK Suppression".

Le problème c'est que le SpeedTest de Massy est bien meilleurs que celui de Paris (Mediactive) et là c'est normalement synonyme de pb "TCP ACK Suppression".
Que donne le SpeedTest d'Aubervilliers ? (normalement assez proche de celui de Paris Mediactive)

Pourrais-tu de nouveau :
- réaliser un test avec un serveur standard avec +90ms de ping standard : http://90ms.testdebit.info/fichiers/3Gb.dat

- réaliser un test avec un serveur optimisé "TCP ACK Suppression" avec +90ms de ping : http://90ms.cable.testdebit.info/fichiers/3Gb.dat

zorly · « **Réponse #106 le:** 13 août 2012 à 13:04:08 »

a 25% il se stabilise a 1.95Mo/s pour le 1er
a 35% il se stabilise a 2.00Mo/s pour le 2eme

un test plus prés de chez moi en Allemagne :

vivien · « **Réponse #107 le:** 13 août 2012 à 13:17:44 »

Merci.

Tu fais parti des rares clients non impactés par "TCP ACK Suppression" sans que l'on comprenne pourquoi...

Pour le problème de débit vers le serveur de Paris, j'ai transféré ton message dans un nouveau post : Pb débit SpeedTest sur serveur de Paris (mediactive)