[technique] St Go : saturation radio, besoin d'aide
Cyril
popolinux at gmail.com
Lun 28 Avr 13:13:33 CEST 2014
Bonjour Emmanuel et Laurent,
Merci pour votre aide.
Le problème se ressent au niveau du téléchargement, mais également au
niveau des téléphones IP.
C'est un point qui est remonté régulièrement.
Le lien principal (St Go - Villeneuve) est normalement le plus limitant,
les autres liens vers Lieoux sont à vue directe et en hauteur (église,
points très hauts, faibles distances...).
On montais à ~40 Mb jusqu'à Lieoux (hors prod bien entendu).
J'ai regardé à 11h30 le lien principal montait jusqu'à 20 Mb en down et
10 Mb en up alors que tout le monde était au boulot.
Je ne sais pas l'expliquer autrement qu'en concluant qu'il y a des
téléchargements/uploads en tâche de fond toute la journée.
Tentons au moins le coup en mettant la QoS en place.
Si ça marche, tant mieux, si ça ne marche pas on l'enlève.
Les tests précédents n'étaient pas super concluants car l'uplink était
totalement saturé.
Nous n'arrivions même plus à garantir le débit de base.
Maintenant nous avons un lien 100 Mb symétrique, la but est simplement
d'équilibrer les liaisons radio.
Merci
Cyril
Le 28/04/2014 12:25, Laurent GUERBY a écrit :
> On Mon, 2014-04-28 at 11:53 +0200, Emmanuel Thierry wrote:
>> Salut,
>>
>> Par curiosité il y a quoi dans votre script QoS ?
>> En principe un hashlimit srcip sur le lien montant et hashlimit dstip
>> sur le lien descendant (associé à srcmask et dstmask fixés à 64 en
>> IPv6) devraient permettre de limiter le débit par adhérent sans trop
>> d'overhead, non ?
>>
>> Manu
> Salut Emmanuel,
>
> Le script de QoS en volume qui etait utilisé depuis 2011 est la :
>
> http://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Buffer_Bloat#QoS
>
> (avec "rate 1kbit" remplacé par debit_total_dispo/nb_utilisateur)
>
> L'idée vient de Fernando de Sames Wireless.
>
> Historiquement il tournait a la tete tunnel openvpn pour controler le
> download (vu des abonnes Saint-Gaudens) sur le serveur gw a Paris (qui
> n'est plus en prod ttnn depuis le passage a Sames), maintenant il
> pourrait tourner directement sur le routeur saint-gaudens (qui a le
> script symetrique avec la version upload) comme il n'y a plus de
> contention sur le backbone.
>
> Empiriquement je dirai que ca a marché vaguement jusque vers une dizaine
> d'utilisateur, apres je pense qu'avec trop de "class" (ici 174) les
> algorithmes htb ne marchent plus vraiment.
>
> Mais les chiffres d'Isabelle et les statistiques mensuelles montrent que
> le probleme ne vient pas de surconsommation P2P : meme avec seulement un
> ou deux utilisateurs P2P elle n'aurait jamais eu 6 Mbit/s sur 20 Mbits
> disponible sur une seule connection TCP.
>
> Le hashlimit d'iptables n'a pas l'air de gerer une ressource
> partageable en burst ce que sait faire tc en htb, si on limite tout
> le monde a 350 kbit/s ca ne va pas ameliorer le ressenti :).
>
> Sincèrement,
>
> Laurent
>
>> Le 28 avr. 2014 à 11:22, Cyril a écrit :
>>
>>> Bonjour Laurent,
>>>
>>> Merci pour ces précisions statistiques.
>>>
>>> Nous avons enlevé Martres et Labarthe de la branche radio saturée.
>>> Elle comporte environ 80 adhérents.
>>> Nous avons du mal à dépasser les 20 Mb de moyenne (cf Aircontrol).
>>>
>>> La branche radio actuellement saturée comporte un tout petit peu plus d'adhérents, mais pas grand monde n'a été ajouté ces derniers temps.
>>> Le débit consommé est plus dans les 25-30 Mb.
>>> Comment expliquer cette surconsommation sur cette branche ?
>>>
>>> Concernant le P2P, je suis étonné qu'il n'y ait pas plus d'utilisateurs, tant mieux.
>>> En revanche, le problème reste identique avec un seul utilisateur P2P : la répartition se fait par flux TCP.
>>> Un seul utilisateur P2P qui télécharge sur 30 peers va avoir le même "poids" que 30 adhérents qui téléchargent en simultané.
>>>
>>> Concernant la QoS, je pense que nous pourrions refaire un test.
>>> Si ça ne marche pas, nous pouvons la supprimer.
>>> Ou sinon utiliser les interfaces des antennes pour mettre une limite de débit + burst ?
>>>
>>> Merci pour eux
>>> Cyril
>>>
>>>
>>> Le 28/04/2014 09:40, Laurent GUERBY a écrit :
>>>> On Mon, 2014-04-28 at 00:45 +0200, Cyril GOUSSE wrote:
>>>>> Salut à vous tous,
>>>> Bonjour Cyril,
>>>>
>>>>> Isabelle, adhérente de l'asso à Lieoux, m'a envoyé le mail ci-après,
>>>>> ainsi que le screenshot ci-joint.
>>>>> Le lien principal entre l'arrivée fibre et les serres de Villeneuve
>>>>> sature.
>>>>>
>>>>> Après quelques optimisations, le débit est passé de 30 à 42 Mb/s, mais
>>>>> je crains qu'on ne puisse aller plus loin.
>>>>>
>>>>> Je vois les solutions suivantes :
>>>>> 1. Ajouter des départs radio (c'est en cours mais ça prend du
>>>>> temps et ça ne fera que retarder les échéances),
>>>>> 2. Utiliser d'autres équipements (FH avec licence ? Airfiber 5
>>>>> Ghz ?),
>>>>> 3. Remettre en place la QoS par IP pour que le partage des
>>>>> ressources soit plus équitable.
>>>>>
>>>>> Personnellement je pense que le 3ème point permet de résoudre le souci
>>>>> simplement et rapidement.
>>>>> Les utilisateurs du P2P sont actuellement les plus gros consommateurs
>>>>> et sont privilégiés car la répartition du débit se fait par flux et
>>>>> non par IP adhérent.
>>>> Il y a actuellement 174 abonnés radio a Saint-Gaudens pour
>>>> une bande passante maximale totale de 60 Mbit/s due
>>>> aux deux arrivées radio a environ 30 Mbit/s,
>>>> le maximum total que j'ai observée etant 68 Mbit/s.
>>>>
>>>> Le speed test d'isabelle est noté comme etant a 18h33 GMT voila le
>>>> traffix RX/TX en Mbit/s sur l'interconnexion Saint-Gaudens VLAN 2417
>>>> (vue du routeur h3 a Toulouse) :
>>>>
>>>> 20140427T202403 2417: 31.2/43.4
>>>> 20140427T202903 2417: 32.1/39.3
>>>> 20140427T203403 2417: 33.0/37.5
>>>> 20140427T203903 2417: 31.2/36.9
>>>> 20140427T204403 2417: 29.6/38.5
>>>>
>>>> La pointe de traffic la plus proche a été durant la nuit
>>>> a 61 Mbit/s (probablement un backup vu le sens et
>>>> le declenchement a minuit pile, fin vers 2h du matin) :
>>>>
>>>> 20140428T004408 3131: 2417: 61.0/ 6.5
>>>>
>>>> Si je divise 60 Mbit/s par 174 abonnés cela fait
>>>> une moyenne de 0.35 Mbit/s par abonné (oui 350 kbit/s).
>>>>
>>>> Isabelle a eu autour de 6 Mbit/s down et 12 Mbit/s up
>>>> lors de ses tests en pleine heure de pointe ce qui montre
>>>> qu'il n'y avait pas d'utilisateurs de P2P. En effet
>>>> si on suppose que 174 / 2 = 67 utilisateurs sont
>>>> sur la branche radio d'Isabelle et qu'ils
>>>> prennent la moitié du debit de 30 Mbit/s cela fait seulement
>>>> trois ou quatre adhérents sur 67 qui utilisent leur
>>>> connection pour un download a cet instant la
>>>> (5 ou 6 dans le pire des cas ou l'autre branche
>>>> radio est inactive).
>>>>
>>>> Mes observations regulieres du debit par IP ne semblent
>>>> pas montrer d'utilisateurs P2P intensifs actuellement
>>>> a Saint-Gaudens. En statistiques moyennes le max d'usage d'un abonné
>>>> Saint-Gaudens est a 1.9 Mbit/s down 1 Mbit/s up (et tu le connais
>>>> bien :), le suivant est a 30% de ces chiffres et on tombe a 10% de ces
>>>> chiffres au 10eme utilisateur (0.19 Mbit/s down et 0.1 Mbit/s up)
>>>> ce qui est dans les moyennes d'utilisation sur tous les FAI.
>>>>
>>>> Le phenomene qu'observe Isabelle est simplement du au
>>>> succes de l'association a Saint-Gaudens et l'augmentation
>>>> du nombre d'adherent a ressource radio constante.
>>>>
>>>>> La QoS par IP était en place auparavant mais Laurent l'avait
>>>>> désactivée lors de l'upgrade fibre à 100 Mb/s car nous ne saturions
>>>>> plus l'uplink.
>>>>>
>>>>> Sur gw.tetaneutral.net, le script /root/qos.sh réalisait la QoS.
>>>>> Quelqu'un pourrait-il le remettre en place sur la prod actuelle ?
>>>>> Si je ne m'abuse il faut appliquer les règles au niveau de h3, sur
>>>>> l'interface eth0.2417
>>>>> Niveau paramétrage je peux communiquer la liste des IP publiques en
>>>>> prod à St Gaudens.
>>>> Le script de QoS marchait relativement mal lors qu'il etait en place,
>>>> tu etais le premier a me le signaler 3 ou 4 fois par semaine :).
>>>>
>>>> Je n'ai aucune raison de penser que l'ancien script de QoS
>>>> ameliorerait les choses, et toutes les raisons de penser
>>>> qu'il va empirer les choses a cause en particulier de la longueur
>>>> de la chaine iptables (activée a chaque paquet), le fait
>>>> que le garanti soit tres bas (350 kbit/s) et decorrelé
>>>> de la réalité radio (deux chaines radio differente
>>>> donc baisser le debit sur l'une ne va pas miraculeusement
>>>> faire augmenter le debit sur l'autre).
>>>>
>>>> Des travaux sont en cours pour mettre en place
>>>> le nouveau routeur unique et plus performant a Toulouse,
>>>> et les premiers outils seront liés aux statistiques
>>>> qui nous permettrons d'y voir plus clair.
>>>>
>>>> Sur la partie radio les nouveaux modeles ubiquity
>>>> sont reportés comme etant meilleurs mais le firmware
>>>> n'est pas encore stable d'apres mes tests et les retours
>>>> sur les forum et les personnels d'ubiquity renvoient
>>>> vers la version 5.6 a paraitre pour les corrections (1).
>>>>
>>>> Sur du point a point radio on peut esperer une amelioration
>>>> du debit en passant a OpenWRT, cela l'objet de discussion a l'assemblee
>>>> generale de la federation FDN a Sames du 8 au 11 mai :
>>>>
>>>> http://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/AGFFDN2014
>>>>
>>>> Sincèrement,
>>>>
>>>> Laurent
>>>>
>>>> (1) le dernier bug en date est amusant :
>>>> http://community.ubnt.com/t5/airMAX-General-Discussion/US-Nanobeam-and-5-5-8/m-p/814312#M40931
>>>>
>>>>
>>>>> Merci pour votre aide.
>>>>> Cyril
>>>>>
>>>>>
>>>>> -------- Message original --------
>>>>> Sujet:
>>>>> snif snif test debit
>>>>> Date :
>>>>> Sun, 27 Apr 2014 19:40:41 +0100
>>>>> (BST)
>>>>> De :
>>>>> Isabelle
>>>>> Répondre à :
>>>>> Isabelle
>>>>> Pour :
>>>>> Cyril
>>>>>
>>>>>
>>>>>
>>>>> Coucou
>>>>>
>>>>> ca baisse ca degringole....snif snif lol
>>>>> bisous à vous deux ou trois
>>>>> isa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> technique mailing list
>>>>> technique at lists.tetaneutral.net
>>>>> http://lists.tetaneutral.net/listinfo/technique
>>>> _______________________________________________
>>>> technique mailing list
>>>> technique at lists.tetaneutral.net
>>>> http://lists.tetaneutral.net/listinfo/technique
>>> _______________________________________________
>>> technique mailing list
>>> technique at lists.tetaneutral.net
>>> http://lists.tetaneutral.net/listinfo/technique
>> _______________________________________________
>> technique mailing list
>> technique at lists.tetaneutral.net
>> http://lists.tetaneutral.net/listinfo/technique
>
Plus d'informations sur la liste de diffusion technique