- État Fermée
- Pourcentage achevé
- Type Évolution
- Catégorie WAN
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 1.1.4
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par fabriceroux - 23/03/2012
Dernière modification par mbizon - 22/11/2013
FS#9793 - Reduction des buffers de connexion
Suite à l’écoute du dernier épisode du podcast Security Now (Buffer Bloat), je suis allé tester ma connexion Freebox Server ADSL 12M/1M dégroupage total avec Netalyzr. La partie gênante du rapport final est la suivante:
“Network buffer measurements (?): Uplink 560 ms, Downlink 87 ms
We estimate your uplink as having 560 msec of buffering. This level can in some situations prove somewhat high, and you may experience degraded performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. Real-time applications, such as games or audio chat, may also work poorly when conducting large uploads at the same time.
We estimate your downlink as having 87 msec of buffering. This level may serve well for maximizing speed while minimizing the impact of large transfers on other traffic.”
En gros le buffer de sortie est trop gros pour un fonctionnement optimal de la connexion. Si j’uploade un gros fichier tout en me baladant sur le net et en discutant en VoIP:
- le buffer se remplit à cause du gros fichier.
- la navigation est ralentie car chaque paquet arrive en fin du buffer FIFO. Il faut attendre 0.5s avant qu’il soit envoyé.
- la discussion VoIP devient inutilisable.
Idéalement, avec un mini buffer:
- l’upload du fichier est géré par TCP. Qui adapte la vitesse d’envoi à la capacité de la liaison.
- la navigation n’est pas ralentie car les paquet sont envoyé dès que possible (largement avant la demi seconde du cas précédent).
- la voix sur IP est utilisable (peut être avec une sonorité métallique mais utilisable).
Conclusion: il faut minimiser la taille du buffer de sortie sur les Freebox Server. Il est peut être parfait pour un utilisation fibre. Mais dans le cas de l’ADSL, il impacte grandement l’utilisation multitâches.
Liens:
http://twit.tv/show/security-now/345 http://netalyzr.icsi.berkeley.edu/
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
lol.
Vous n’avez manifestement pas vérifié ce que le résultat du test prétend.
Cet outil de test ne suppose pas l’existence d’une QOS quelconque. Pour faire son test de latence, il fait un pseudo flood UDP vers un seul et unique serveur et mesure le RTT.
La freebox utilise les qdisc PRIO et SFQ pour le traffic sortant:
Etant donné que le test se contente de flooder un serveur unique ⇒ meme ip/proto/ports pour chaque paquet ⇒ meme bucket de la table de hash ⇒ latence qui augmente.
Si vous lancez une autre connection TCP, elle a toute les chances d’utiliser un autre bucket, et donc d’avoir une latence minimale.
Faites le test pour vous en convaincre, lancez un gros upload et gardez un ping à coté.
Merci pour cette réponse technique rapide. Effectivement, mon exemple de gros buffer était un cas extrême qui ne s’applique pas au Freebox Server. Le QoS présent dans le Freebox Server lisse les choses.
Mes essais de ping (en ms) vers un serveur anglais que j’utilise sont les suivants:
- lien vide: moy = 26 / max = 27.
- un upload http: moy = 37 / max = 51.
- un upload https: moy = 35 / max = 52.
- un upload https sur port exotique: moy = 36 / max = 52.
- deux uploads http: moy = 47 / max = 63.
- trois uploads http: moy = 60 / max = 80.
Pour ma culture générale j’ai lancé le client bittorrent du Freebox Server avec une limite d’upload à 90ko/s. Je ne sais pas si il est aussi intelligent que µTorrent quant à la limitation automatique du débit aux limites du tuyau. Le ping restait entre 80 et 280 la majorité du temps avec des retours à 26ms par moment. moy = 113 / max = 514.
Les résultats sont plus reluisants que dans mon exemple extrême. Qui a dit que les marseillais exagéraient :) ? Ce test corrèle l’observation non scientifique: un upload ca va, trois uploads bonjour les dégats. “Chérie arrête d’envoyer des photos sur internet, je ne peux plus jouer en ligne.”
Je reste convaincu que l’utilisation d’un buffer trop grand (ici environ 64ko) a un effet négatif. TCP et Bittorrent sont capables de se limiter pour rester sous la limite de débit du point le plus lent. TCP cherche en permanence à toucher la limite. La présence d’un buffer trop grand fait dépasser cette limite. TCP quand il atteint la limite baisse son débit de quelques %. Il lui faudra plusieurs échecs pour revenir sous le débit réel du tuyau. Puis il tentera à nouveau de monter en vitesse... pour atteindre une limite... puis baisser encore...
Je préfèrerai un buffer plus petit qui rejette les paquets des gros consommateurs histoire de leur signaler qu’il ne sert à rien d’envoyer 150ko/s quand le tuyau encaisse 100ko/s.
Que je sache, je ne peux pas forcer un low delay sur les paquets de mes jeux en ligne. La solution la plus simple pour prioriser mon trafic par rapport aux autres périphériques de mon LAN serait de pouvoir booster tout ce qui vient de mon adresse MAC.
Où sont listées les règles QoS de la Freebox? Je me doute que VoIP et multimédia doivent être en “low delay” quid du reste.
Est il prévu de fournir une interface de paramétrage QoS?
pour info la Freebox utilise maintenant fq_codel, mais même resultat sur netalyzr. Après recherche, l'outil n'est pas adapté:
https://lists.bufferbloat.net/pipermail/bloat/2013-February/001338.html
A big problem with netanalyzer (presently) is that it measures a single UDP
flow in its buffering analysis. It is unaware of packet scheduling (such as
what fq_codel and sfq and qfq do). So it will show large buffers in a rate
limited fq_codel case... *but they don't matter*, because of the fair
queuing component.
Les règles de la Freebox ne sont pas éditables, on fera peut être ce que vous proposez (QOS par adresse MAC), en attendant vous pouvez changer le TOS depuis votre PC.