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

[Fernando Alves]

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
>>
>


-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 551 octets
Desc: OpenPGP digital signature
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20140428/cb949722/attachment.sig>