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

Cyril popolinux at gmail.com
Lun 28 Avr 19:46:28 CEST 2014


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
>




Plus d'informations sur la liste de diffusion technique