[Ninux-Calabria] traffic shaping

[Giuseppe De Marco]

Il 11 maggio 2014 20:57, Vincenzo Pirrone <linuspax a gmail.com> ha scritto:
>> Wind infostrada ? Dicevi che hai 24 di attenuazione ?
>
> Downstream      Upstream
>
>
>
> SNR Margin
>
> :
>         15.2    24.3    db
>
>
>
> Line Attenuation
>
> :
>         23.5    12.4    db
>
>
>
> Data Rate
>
> :
>         8000    511     kbps
>
> Il copia incolla dalla webui del modem è venuto un po' male, perdonatemi.
>

ti faccio il mio, wind/infostrada:

Internet Connection Up Time:  212 hours, 11 minutes, 31 seconds
Downstream Line Rate (Kbps):13999
Upstream Line Rate (Kbps):997

SNR Margin (dB):8.611.6
Attenuation (dB):24.512.4
Output Power (dBm):19.412.3
Attainable Rate (Kbps):167681045
Rate (Kbps):13999 997
D (interleaver depth):11
Delay (msec):00
HEC Errors:12914229
OCD Errors:22670
LCD Errors:40

Total ES:1438111

Allora come ben sai anche io ero a 7999 di QoS ma li ho telefonati 2
volte a settimana per un mese e mezzo.
Purtroppo di questi 13999 ho 2500 di rumore e benedica gli errori HEC
e soci sono tutti fallimenti del crc.

Ho anche più attenuazione di te.
Sai, dovrei rimuovere il filtro antico della telecom, un fusibile che
è presso l'entrata di casa che non oso immaginare che valore resistivo
abbia.

Provo a rimuoverlo e riavviare il router per capire se l'attenuazione
diminuisce.
Se sì uso una ciabatta con protezione rj11 / linea telefonica.

tu intanto pressali ! :)
Ti devono dare la banda minima garantita ai 11 o 12Mbit !!!


>>> Così facendo in realtà si imposta un limite fullduplex?
>> Purtroppo su linea asincrona abbiamo bisogno della regola anche in upload.
>>


>>> Se il limite di 1024k è fullduplex vuol dire che è ancora possibile che
>>> mi vengano saturati i 400k di upload?
>> Il problema, purtroppo, è che la regola di iptables parla chiaro, il
>> CLASSIFY si applica esclusivamente ai pacchetti che hanno come source
>> 10.87.20.0/24, i pacchetti destinati a questa rete vengono ignorati
>> dal kernel e non passano da HTB :(

di questo non ne sono cmq certissimo ma DI CERTO che nè sà lo
scheduler che la nostra linea è asincrona e con quali parametri ! :)

ad ogni modo su "A Practical Guide to Linux Traffic Control", dice che:

 A variety of methods exist to classify flows. You can use tc to
classify traffic, but it suffers from being entirely stateless

>
> Quindi per come ho fatto fin'ora limito solo il traffico in upload
> giusto? (ho fatto dei test che me lo confermano), volendo sistemare
> meglio i rate dovrei fare:
>
> tc qdisc add dev pppoe-wan root handle 1: htb default 1
> tc class add dev pppoe-wan parent 1: classid 1:1  htb rate 411kbit
> tc class add dev pppoe-wan parent 1:1 classid 1:2 htb rate 51kbit
> iptables -t mangle -A POSTROUTING -o pppoe-wan ! -s 10.87.20.0/24 -j
> CLASSIFY --set-class 1:2
>
> Per limitare il download devo per forza inserire un qdisc sulla vlan di
> olsr, correggimi se sbaglio, si può fare una roba del genere

non ci conviene coinvolgere l'eth di Ninux, il QoS meglio tenerlo
sull'uscita internet (pppoe-wan) così non ti precludi la lan veloce.
forse non ho capito poi ne parliamo ma qui io proverei:

iptables -t mangle -A POSTROUTING -o pppoe-wan -s 10.87.20.0/24 -j
CLASSIFY --set-class 1:2
iptables -t mangle -A POSTROUTING -o pppoe-wan -d 10.87.20.0/24 -j
CLASSIFY --set-class 1:1

così ai pacchetti in download dai 411kbit e a quelli in upload 51kbits.
poi ci dici.

> tc qdisc add dev eth0.3 root handle 1: htb default 2
> tc class add dev eth0.3 parent 1: classid 1:1  htb rate 100Mbit
> tc class add dev eth0.3 parent 1:1 classid 1:2 htb rate 1Mbit
> iptables -t mangle -A POSTROUTING -o eth0.3 -s 10.87.20.0/24 -j CLASSIFY --set-class 1:1
>
> Tengo cioè di default il rate a 1M, per il traffico originato dalla mia
> lan invece è possibile utilizzare tutta la banda (quella della nanostation)

quando vuoi facciamo un test incrociato :)