[technique] St Go : saturation radio, besoin d'aide

[Cyril]

Ok ça marche.
Je ne pourrais pas être présent mais je laisse le soin à Laurent de 
collecter les infos nécessaires.

Merci à vous tous
Cyril

Le 28/04/2014 20:12, Fernando Alves a écrit :
> On verra lors de l'AG FFDN ça sera plus facile pour les explications et
> tout....
>
> Le 28/04/2014 19:46, Cyril a écrit :
>> Si j'ai bien compris tu tournes encore en collecte ADSL et tu n'arrive
>> à avoir que quelques mécontents en VoIP ?
>> Beau boulot...
>>
>> En tous les cas le comportement est génial car c'est progressif et
>> tout le monde s'y retrouve.
>> Celui qui fait de gros téléchargements verra que son débit diminue
>> s'il abuse, mais de toute manière le téléchargement tourne en tâche de
>> fond et ça ne le dérange pas.
>> L'utilisateur classique verra de très bons résultats en "speedtest",
>> aura une très bonne perception et disposera du débit pour ses
>> téléchargements ponctuels.
>>
>> Sans vouloir abuser de ton temps, aurais-tu quelques minutes pour
>> échanger par téléphone et essayer de mettre en place ce système sur le
>> routeur à St Go ?
>> J'aurais besoin de quelques infos comme le script PHP n'est pas très
>> documenté.
>>
>> Merci beaucoup
>> Cyril
>>
>>
>> Le 28/04/2014 18:57, Fernando Alves a écrit :
>>> c'est prévu que j'en discute avec Laurent lors de l'AG FFDN dans 10
>>> jours.
>>>
>>> Le 28/04/2014 18:27, Cyril a écrit :
>>>> Salut Fernando,
>>>>
>>>> Génial comme principe car, si j'ai bien compris, on applique la QoS
>>>> seulement aux personnes qui abusent.
>>>>
>>>> Ça marche bien en production ?
>>> Oui, c'est pas parfait mais beaucoup moins de plaintes (parfois quelques
>>> plaintes sur la voix IP)
>>>
>>>
>>>> Tu faisais pareil sur le download ou pas besoin ?
>>> Je fais rien en Download à part le qdisc sur l'ingress
>>>
>>> tc qdisc del dev $PPP_IFACE ingress
>>> tc qdisc add dev $PPP_IFACE handle ffff: ingress
>>> tc filter replace dev $PPP_IFACE parent ffff: protocol ip prio 50 u32
>>> match ip src 0.0.0.0/0 police rate 10000kbit burst 500k drop flowid :1
>>>
>>>
>>>> Merci pour ton retour
>>>> Cyril
>>>>
>>>>
>>>> Le 28/04/2014 16:59, Fernando Alves a écrit :
>>>>> Salut,
>>>>>
>>>>>
>>>>> Le 28/04/2014 15:39, Cyril a écrit :
>>>>>>> Par contre, il serait possible de fixer des règles en fonction de
>>>>>>> l'heure de la journée ou bien de cascader plusieurs règles pour
>>>>>>> faire
>>>>>>> un enforcement de plus en plus strict du débit maximal autorisé par
>>>>>>> utilisateur jusqu'à supprimer la saturation (entendu : on essaye à
>>>>>>> 5Mbps, puis 2Mbps, puis 1Mbps, puis 500kbps), mais au bout d'un
>>>>>>> moment il y a le risque d'over-engineerer, et les problèmes de
>>>>>>> performance que cela peut engendrer en multipliant les règles
>>>>>>> netfilter.
>>>>>> D'accord.
>>>>>>
>>>>>> Donc ce n'est pas vraiment possible de donner tout le débit à un
>>>>>> utilisateur si personne d'autre ne s'en sert ? De le diviser en deux
>>>>>> si deux personnes le demandent ?
>>>>>>
>>>>>> Ou encore mieux, donner tout le débit dispo durant X secondes puis
>>>>>> fixer une limite de débit une fois que ce "crédit est dépensé" ?
>>>>>> Par exemple, utiliser 30 Mb pendant 300 secondes permet de
>>>>>> télécharger
>>>>>> plus d'un Go de données.
>>>>>> On peux considérer qu'au-delà c'est une utilisation abusive et nous
>>>>>> pourrions prioriser les utilisateurs lambda.
>>>>>>
>>>>> A Sames j'utilise un truc dans le genre sur le UP de nos lignes ADSL.
>>>>> J'ai un script (en php) qui relève la conso de chaque IP toutes les N
>>>>> minutes, les utilisateurs changent de "class" selon leur temps
>>>>> d'utilisation intensive du débit montant.
>>>>> C'est un script (ci-joint) que j'avais développé à l'arrache suite
>>>>> à la
>>>>> plainte de nombreux adhérents sur la lenteur de leurs connexions, il
>>>>> mériterait d'être repris/amélioré (changer le langage surtout(php))
>>>>> mais
>>>>> je n'ai jamais trouvé le temps.
>>>>>
>>>>> ************* A mettre dans "/etc/ppp/ip-up.d/"
>>>>> ***********************
>>>>>
>>>>> MAXUP0=900
>>>>> MAXUP1=800
>>>>> MAXUP2=700
>>>>> MAXUP3=600
>>>>> MAXUP4=500
>>>>> MAXUP5=300
>>>>>
>>>>> tc qdisc add dev $PPP_IFACE root handle 1: htb default 100
>>>>> tc class add dev $PPP_IFACE parent 1: classid 1:1 htb rate 100000Kbit
>>>>> ceil 100000Kbit burst 1023975b cburst 126575b prio 0 quantum 60000
>>>>> tc class add dev $PPP_IFACE parent 1:1 classid 1:2 htb rate 1000kbit
>>>>> ceil 1000kbit burst 6Kb cburst 2224b quantum 60000
>>>>>
>>>>> tc class add dev $PPP_IFACE parent 1:2 classid 1:10  htb rate 300kbit
>>>>> ceil ${MAXUP0}kbit burst 48Kb prio 1 quantum 60000
>>>>> tc qdisc add dev $PPP_IFACE parent 1:10 handle 10: sfq perturb 10
>>>>>
>>>>> tc class add dev $PPP_IFACE parent 1:2 classid 1:3  htb rate 200kbit
>>>>> ceil ${MAXUP0}kbit burst 24Kb prio 2 quantum 60000
>>>>>
>>>>> tc class add dev $PPP_IFACE parent 1:3 classid 1:100  htb rate 100kbit
>>>>> ceil ${MAXUP1}kbit burst 24Kb prio 3 quantum 60000
>>>>> tc qdisc add dev $PPP_IFACE parent 1:100 handle 100: sfq perturb 10
>>>>>
>>>>> tc class add dev $PPP_IFACE parent 1:3 classid 1:99  htb rate 64kbit
>>>>> ceil ${MAXUP2}kbit burst 6Kb prio 4 quantum 60000
>>>>> tc qdisc add dev $PPP_IFACE parent 1:99 handle 99: sfq perturb 10
>>>>>
>>>>> tc class add dev $PPP_IFACE parent 1:3 classid 1:98  htb rate 32kbit
>>>>> ceil ${MAXUP3}kbit burst 1Kb prio 5 quantum 60000
>>>>> tc qdisc add dev $PPP_IFACE parent 1:98 handle 98: sfq perturb 10
>>>>>
>>>>> tc class add dev $PPP_IFACE parent 1:3 classid 1:97  htb rate 16kbit
>>>>> ceil ${MAXUP4}kbit burst 1Kb prio 6 quantum 60000
>>>>> tc qdisc add dev $PPP_IFACE parent 1:97 handle 97: sfq perturb 10
>>>>>
>>>>> tc class add dev $PPP_IFACE parent 1:3 classid 1:96  htb rate 16kbit
>>>>> ceil ${MAXUP5}kbit burst 1Kb prio 7 quantum 60000
>>>>> tc qdisc add dev $PPP_IFACE parent 1:96 handle 96: sfq perturb 10
>>>>>
>>>>> ********************************************************************
>>>>>
>>>>>
>>>>> Fernando
>