[technique] St Go : saturation radio, besoin d'aide
Laurent GUERBY
laurent at guerby.net
Lun 28 Avr 13:42:09 CEST 2014
On Mon, 2014-04-28 at 13:13 +0200, Cyril wrote:
> 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.
Salut Cyril,
On a inventé un truc genial ca s'appelle les videos en streaming,
surtout avec des chats dessus :)
Les deux premieres IP en debit sont actuellement :
188.65.126.105 => dailymotion
173.194.9.74 => google (youtube)
Entre 50 et 80% du debit est port 80 (http) actuellement,
5 utilisateurs sont entre 1 et 4 Mbit/s, le reste
en dessous de 1 Mbit/s, une bonne vingtaine significatifs.
Quand tout le monde essaye de regarder une video
a 19h avec 350 kbit/s par personne ca coince,
la QoS n'y changera rien.
Pour la VoIP c'est plus compliqué le débit est loin
d'etre le seul parametre.
Sincèrement,
Laurent
> 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