J'ai le même problème sur ma connexion professionnelle 5Mbps que dans une autre publication sur ce site. Dès qu'un ordinateur démarre un téléchargement, la latence au premier saut après notre DFG fournie par notre FAI (Bell) disparaît. Ce premier saut est probablement dans notre même bâtiment et dure 1 ms en permanence, lancez un téléchargement, par exemple une mise à jour Windows, et il passe à 200-1000 ms.
J'ai passé des heures au téléphone avec du soutien, tous disant que vous avez atteint la bande passante maximale disponible, il est normal que votre latence augmente. Mais ma lecture me dit qu'ils cassent quelque chose avec TCP. J'ai effectué des tests sur une connexion Shaw à domicile et même sur un Rogers LTE exécutant des téléchargements et atteignant le maximum de Mbps pour mon compte, mais la latence ne passe pas par le toit.
Ai-je raison de croire que Bell fait quelque chose pour briser les technologies intégrées de TCP afin de gérer son débit en fonction de la bande passante disponible entre les 2 points d'extrémité?
Réponses:
Bell vous dit la vérité. Lorsque vous essayez de pousser 5 Mbps (ou plus) dans une connexion à 5 Mbps, tout est rangé dans un petit ordre ordonné (lecture: file d'attente). Votre ping s'éteint sans délai car il n'y a pas de retard. Cependant, la réponse est maintenant à la fin de la file d'attente. TCP fait exactement ce qu'il est censé faire ici - l'expéditeur remplit la fenêtre de réception autorisée.
Il y a des choses que vous pouvez faire de votre côté de la ligne (QoS, WRED, etc.) pour aider à réduire les effets, mais c'est le genre de chose que vous verrez quand il y a une grande différence entre la bande passante de l'expéditeur et du récepteur. Je l'ai vécu pendant des années (T1, DS3 à 6 Mbps, même modem à 10 Mbps) Vous pouvez demander au FAI de réduire la taille de la file d'attente de son côté, mais ils ne le feront probablement pas, car cela entraînera des pertes de paquets .
la source
La plupart des formes de «QoS» de nos jours n'incluent pas AQM car les fournisseurs ont trouvé trop difficile de configurer RED de manière automatique sans faire de mal. Cela entraîne les retards horribles que vous voyez sur de nombreux appareils courants aujourd'hui, notamment les modems câble et sans fil. Donc, simplement recommander "activer les qos" ... n'aide pas. En fait, sur au moins un des produits Netgear, l'activation du limiteur de débit pour "QoS" conduit à des résultats bien pires ...
Récemment, un nouvel algorithme de mise en file d'attente équitable + AQM est apparu qui semble fonctionner extrêmement bien, et mieux, ne nécessite presque aucune configuration en plus de définir le limiteur de débit. Il s'appelle fq_codel, et il est maintenant largement disponible dans la plupart des Linux et a également été porté sur BSD. Cela fait partie de la "QoS" par défaut dans les brise-barrières openwrt, cerowrt et gargoyle utilise une (assez bonne) version antérieure appelée sfqred avec un schéma innovant d'ajustement automatique des taux appelé ACC.
Vous pouvez donc claquer une boîte basée sur cela devant votre lien de mauvaise conduite, activer leur limiteur de débit QoS (défini juste légèrement en dessous des paramètres entrants et sortants de vos fournisseurs afin que vous preniez le contrôle) + fq_codel, et obtenir de bien meilleures performances pour tous ceux qui l'utilisent . Je veux dire étonnamment mieux: voir la démo ietf ci-dessous, le rapport au groupe de travail iccrg à l'ietf, etc.
Pour bien plus de détails sur le problème de bufferbloat et ses correctifs, voir:
http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos
Nous essayons (bien sûr) de convaincre divers fournisseurs de CPE ISP de prêter attention, tout comme les cablelabs, qui ont publié une merveilleuse étude de ces nouvelles choses il y a quelques mois, qui contient également quelques détails sur la mauvaise conduite actuelle des modems câble en particulier.
http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf
la source
Ce que vous voyez est tout à fait typique. De nombreux fournisseurs de services évalueront la limite et / ou utiliseront un mécanisme de QoS pour réduire la priorité d'ICMP (qui inclut le ping traditionnel et la traceroute) car il a parfois été utilisé dans les attaques par déni de service.
Bien qu'un lien ne soit pas encombré, la priorité réduite n'affecte rien car aucun trafic n'est mis en file d'attente. Pendant ces périodes, votre latence reste faible car les paquets ICMP seront transmis immédiatement et ne seront pas retardés du tout.
Lorsque le lien est encombré, les files d'attente de priorité élevée attirent davantage l'attention. Selon le mécanisme de mise en file d'attente, il peut transférer plusieurs paquets d'une file d'attente de priorité supérieure pour chaque paquet d'une file d'attente de priorité inférieure ou même transmettre uniquement lorsqu'il n'y a rien dans une file d'attente de priorité supérieure. Dans tous les cas, un paquet relégué dans une file d'attente de priorité inférieure sera généralement retenu plus longtemps que sur une liaison sans encombrement, ce qui augmente la latence.
la source
Vous souffrez probablement de bufferbloat et vous voulez AQM (Active Queue Management). J'ai écrit un script pour Linux qui rend cela assez facile:
Il vous suffit d' enregistrer le script
traffic-shaping
etchmod a+x
et l' exécuter en tant que root (après avoir lu le code source, évidemment).Pour votre cas d'utilisation, je suggère
la source
linux-lowlatency
noyau pour que le système continue de traiter tous les packages.