Newsgroup: it.comp.os.linux.sys
Titolo: ADSL e traffic shaping

Ho un router ADSL con hub integrato, che serve la mia rete casalinga. Ho
notato che  un avviare  un upload riduce  drasticamente la  velocita` in
download (in  genere si passa  da 40Kbps  a 20Kbps). Ho il  sospetto che
questo sia  dovuto al  fatto che  gli ACK  relativi al  download vengono
ritardati dai pacchetti relativi all'upload.
Passare da una qdisc fifo a sfq  porta dei benefici minimi, visto che la
velocita` del link verso il router  (10Mbps) e` molto maggiore di quella
in uscita dal router verso Internet (128Kbps).
Ho quindi pensato di usare una CBQ per dimensionare la massima capacita`
di  upload. Il  problema e`  che  non  posso  usare un'unica  classe  da
128Kbps, perche`  questo limiterebbe le  prestazioni di *tutta*  la rete
locale, mentre io  voglio limitare solo i pacchetti  diretti fuori dalla
mia rete.
Sto quindi cercando di dividere il traffico locale da quello non locale.
Questo filtro:
tc filter add dev eth0 protocol ip parent 1:0 match u32 0a000000
ff000000 at 16 flowid 1:10
permette di riconoscere  tutti i pacchetti diretti verso  la rete locale
(
10.0.0.0/8
) ed assegnarli alla classe giusta (1:10).
Il mio problema e` che non  riesco ad invertire questo test per matchare
i pacchetti non diretti sulla rete locale.
tc non  permette di negare la  condizione, quindi ho il  dubbio di stare
sbagliando approccio.
Qualche idea?
TIA,
Kronos
-- 
Home: 
http://kronoz.cjb.net
You and me baby ain't nothin' but mammals
So let's do it like they do on the Discovery Channel

Stesso problema.......
Il primo che risolve avvisa l'altro.
Stefano


 (
10.0.0.0/8
) ed assegnarli alla classe giusta (1:10).
E' una descrizione un po' sommaria del tuo filtro e non riesco a capire.
Le classi non funzionano modello scatole cinesi: il traffico non "matchato"
non rimane nella classe genitore di 1:10?
 
bye.


Scusate, ma le bande per upload e per download lavorano separatamente...
non dovreste avere problemi se entrambe vengono utilizzate a pieno....
 Io ho sempre lavorato con entrambe le bande a pieno utilizzo senza mai
perdere in prestazioni.

 Qualche idea?
un paio:
-gli ack non centrano
-
http://lartc.org/wondershaper/
 (qui e' spiegato il problema e una 
possibile risoluzione)
-controllare gli archivi prima di postare
Ciao
Francesco

 perdere in prestazioni.
Una banda satura in upload limita anche quella in download, questo perchè per
ogni pacchetto (di solito) ricevuto devi cmq inviare l'ack o cmq la notifica che
il pacchetto sia arrivato a destinazione :)
-- 
| /
| \Byte - Andrea Briganti - kbytesys(at)
tiscali.it
http://www.kbytesystem.fasturl.it
 - ICQ: 40872731
*** Chi non ha rispetto non merita considerazione

 non rimane nella classe genitore di 1:10?
E` appunto questo il problema. La classe genitore ha una banda di 10Mbps
(eth0). Io voglio  limitare solo  il traffico  diretto fuori  dalla rete
locale.
Cmq, penso  di aver risolto  la cosa. So  che il traffico  diretto verso
internet deve passare  attraverso il router, che e` anche  il gateway di
default.
Ora, impostando il gw cosi`:
ip route add table default via 10.0.0.138 dev eth0 realms 10 metric 1
ho la possibilita` di usare un  filtro per matchare il traffico (tramite
realm) in uscita:
tc filter add dev eth1 parent 1:0 protocol ip prio 100 route to 10
classid 1:10
dove 1:0 e` la classe root da 10Mbps e 1:10 e` la classe da 128Kbps.
Devo fare qualche test, ma penso che la soluzione sia buona.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Ligabue canta: "Tutti vogliono viaggiare in primaaaa..."
Io ci ho provato e dopo un chilometro ho fuso il motore e bruciato
la frizione...

 -controllare gli archivi prima di postare
Non hai colto qual'e` il mio problema...
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"Fare l'amore con dieci donne e` fantastico, soprattutto perche` ti
 presentano un sacco di amiche." -- Fabio Di Iorio

 Non hai colto qual'e` il mio problema...
Perdono :)
Francesco

 dimensioni delle code ..
Piu` o meno. Il problema delle code  si farebbe sentire solo nell'uso di
protocolli  interattivi sensibili  agli aumenti  di latenza  (http, irc,
ecc) e di questo mi importerebbe relativamente poco. Il problema sta nel
fatto che  nella coda ci finiscono  anche gli ACK relativi  al download,
che arrivano  quindi in ritardo. Se  il ritardo e` abbastanza  grande il
trasmettente assume che i pacchetti  siano andati persi e ritrasmette (e
rallenta, visto  che questo  e` proprio  il metodo  di flow  control del
TCP/IP).
Quello  che non  mi  riusciva di  fare,  non era  impostare  la CBQ,  ma
separare il traffico remoto da  quello diretto alla rete locale (128Kbps
sulla LAN sono un po' pochini...).
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Porc i' mond che cio' sott i piedi!
V. Catozzo

 sulla LAN sono un po' pochini...).
Avevo letto e risposto di fretta lo so ;-), il perdono della mail 
precedente era dovuto al fatto che avevo "riletto" con più calma la tua 
mail e mi ero accorto dell'errore fatto ;-) (e quindi del tuo effettivo 
problema)
Ciao
Francesco