Newsgroup: it.comp.os.linux.sys
Titolo: Ancora sulla limitazione di banda

Già tempo fa avevo chiesto conferme, espresso dubbi ecc circa la
limitazione di banda per particolari scopi, tipo traffic shaping
ma non solo...o perlomeno non è ora come ora il mio obiettivo.
In rete ho visto che vi sono parecchi documenti, tutti piuttosto
evoluti e che fanno riferimento quasi sempre alla predisposizione
di una macchina che collega una LAN ad internet fungendo anche da
firewall per esempio. In questo modo si hanno 2 interfaccie eth0
ed eth1 per esempio, l'una rivolta verso internete e l'altra
verso la lan, ecc ecc.
La mia situazione è differente in quanto al momento non sono in
una lan, ma ho il mio portatile connesso ad internet con un
cellulare attraverso l'interfaccia ppp0.
Mi piacerebbe, tanto per farmi un'idea e riuscire a ottenere un
risultato concreto e tangibile, considerare con voi il seguente
caso:
supponiamo di voler scaricare da un sito un grosso file, per
esempio una iso di linux, un video o comunque qualcosa di grosso.
E supponiamo di voler limitare la banda utilizzata per il
download di modo da poter comunque svolgere altre attività
utilizzando interent.
Usiamo qualche dato circa i miei infimi valori di up/down-load.
UP=10KB/s circa
DOWN=20KB/s circa
(per i curiosi si tratta di connessione via tecnologia edge).
Ora come ho già detto l'interfaccia con cui ci si connette ad
internet è ppp0.
Inoltre conosciamo il sito da cui si vuole scaricare, in
particolare il suo ip: chiamiamolo per esempio ip.ip.ip.ip.
Ora vorrei che il download da quel sito fosse perennemente
limitato al valore di 6 KB/s (sono tutti KByte).
Come potrei farlo utilizzando tc?
Sarebbe veramente esaustivo un esempio pratico di creazione di
eventuali discipline di coda...e tutto il resto insomma.
Utilizzo slackware 12.1 con kernel hugesmp rimaneggiato poco e
per aspetti che dubito centrino qualcosa con questo argomento.
Mi farebbe comunque piacere che sottolineaste eventuali aspetti
da controllare nel kernel, necessari per l'efettivo funzionamento
di tc e della gestione delle varie code.
Ancora, mi farebbero comodo 2 parole spese per giustificare
l'utilizzo dell'uno piuttosto che dell'altro tipo di disciplina
di coda (ad esempio vedo che in alcuni esempi si usa HTB, in
altri CBQ).
Spero sia una domanda cui possiate/sappiate rispondere, infatti
se funzionasse bene questo meccanismo sarebbe una buona via per
migliorare la gestione di banda sulla mia povera linea.
Vi ringrazio in anticipo e scusate la lunghezza.
Saluti  :-)

 migliorare la gestione di banda sulla mia povera linea.
Non so darti la risposta che cerchi, ma nel frattempo, a fini pratici,
mi viene da suggerirti trickle, che è un bandwidth manager per
applicazione e gira in userspace.
Ad esempio, per scaricare l'iso, potresti dare qualcosa come:
trickle -d6 wget quelcheè.iso
e vivere felice.
--
Bye, Lem

 trickle -d6 wget quelcheè.iso
L'avevo già provato in passato, lo riproverò, ma se non ricordo
male non mi aveva soddisfatto granchè, sinceramente non ricordo
bene il motivo.
Inoltre mi piacerebbe capire di più su tc con l'esempio pratico
che avevo proposto. Comunque grazie del consiglio, magari riprovo
anche trickle.  :-)
In ogni caso attendo la versione con tc, sperando che qualcuno
sappia rispondere.
Saluti! :-)

 vedo che in alcuni esempi si usa HTB, in altri CBQ).
HTB è più evoluto e più flessibile.
Per il resto, tu *vuoi* studiare gli intermediate queueing devic:
http://lartc.org/howto/lartc.imq.html

 
http://lartc.org/howto/lartc.imq.html
Ma...era una domanda?  ;-)
Avevo letto di questa sorta di interfaccia virtuale, non so se si
dice cosě...sono veramente a zero per quanto riguarda questi
argomenti. E a dirla tutta mi era parsa anche una soluzione
giusta, tuttavia non avevo azzardato prove o configurazioni di
testa mia vista la inesistente esperienza in merito e soprattutto
la persistenza di parecchi dubbi anche a livello di comprensione
del lartc (ho come l'impressione che preveda un background di
informazione che ahimč non possiedo).
Per questo avevo "praticamente" chiesto la pappa pronta nella parte
di post che non hai quotato. Speravo vivamente che le note e il
link, fossero a corredo di un esempio pratico completo di righe
di "codice bash" riferito alla mia situazione.
Ad ogni modo, slaviamo il salvabile:
- la tipologia di qdisc piů consigliabile da utilizzare č htb.
- le interfacce da considerare sono rispettivamente ppp0 per ciň
  che esce e imq per ciň che entra...spero di aver azzeccato.
        |-----> imq0 
internet|
        |-----< ppp0
Qualcosa del genere?
Cioč in pratica devo limitare il flusso in uscita da imq0 per
limitare il download e in uscita da ppp0 per limitare l'upload?
Oppure sto farneticando a vanvera?  :-( :-?
Visto che ciň che devo farci, e cioč la limitazione del download
da un singolo ip, non č concettualmente cosě complessa, non č che
potresti passarmi un esempietto da provare al volo?
Ad ogni modo grazie della dritta e del link specifico da
consultare. Saluti!  :-)

 Comunque grazie del consiglio, magari riprovo anche trickle.
Allora, per slackware 12.1 non vi č un pacchetto ufficiale per
trickle. Neanche nei repo dove mi servo solitamente. Cosě ho
deciso di compilarlo autonomamente e crearmi un paccheto .tgz.
Le istruzioni d'altro canto sembra molto semplici:
- wget 
http://monkey.org/~marius/trickle/trickle-1.07.tar.gz
- tar xzf .....
- cd .....
- ./configure
- make
- make install (o equivalente per la creazione del pacchetto)
Ma...
All'atto del make ottengo un errore, riporto l'output completo
del make:
======
# make      
gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -g -O2 -c trickle.c
gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -g -O2 -c util.c
gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -g -O2 -c getopt.c
gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -g -O2 -c strlcat.c
gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -g -O2 -c strlcpy.c
/bin/sh ./libtool --mode=link gcc -Wall -Icompat  -g -O2  -o trickle  \
              trickle.o util.o getopt.o strlcat.o strlcpy.o -lnsl  -ldl
mkdir .libs
gcc -Wall -Icompat -g -O2 -o trickle trickle.o util.o getopt.o strlcat.o \
                                                     strlcpy.o  -lnsl -ldl
gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -g -O2 -c trickled.c
In file included from trickled.c:33:
/usr/include/netinet/in.h:137: error: two or more data types in \
                                           declaration specifiers
/usr/include/netinet/in.h:137: error: two or more data types in \
                                           declaration specifiers
make: *** [trickled.o] Error 1
======
Cosa puň essere andato storto?
Il configure, non riporta errori. Cioč non tutte le voci
risultano verificate, ma alla fine non riporta messaggi
particolari di errore.

                                            declaration specifiers
]zac[
C'è un errore formale o di sintassi o simile nel codice del programma (a
volte è abbastanza banale correggerlo) che probabilmente le versioni
precedenti del compilatore tralasciavano di rilevare.
Quindi o correggi il codice, o da qualche parte la correzione del codice, o
trovi una versione recente è quindi, si spera, corretta, o usi una versione
precedente del compilatore (a volte nei nuovi compilatori c'è una opzione
per forzare il degrading del parsing del codice).
Comunque con google avresti già risolto e in maniera autonoma.

 Comunque con google avresti giŕ risolto e in maniera autonoma.
Grazir dell'intervernto, in realtŕ sono riuscito a compilare
uqalcosa di funzionante applicando al codice sorgente, una patch.
Ho approfittato della pubblicazione di tale patch presso il sito
di debian. In pratica ho spacchettato il pacchetto
trickle_1.07.orig.tar.gz, quindi ho spacchettato anche la ultima
patch pubblicata blablabla.diff.gz, l'ho poi copiata dentro la
directory dei sorgenti, applicata col comando patch ecc ecc, e
quindi mi sono apprestato a dare i soliti comandi di
configurazione ed il make.
Il make lamenta comunque alcuni errori, anche se gli eseguibili
trickle e trickled vengono compilati.
Ho provato trickle lanciandolo dalla directory dei sorgenti e
mi pare che vada bene, comunque prima di impacchettarmelo vorrei
vederci un po' piů chiaro....ad ogni modo per le prove che avevo
intezione di fare va giŕ bene cosě.
Grazie ancora comunque.  :-)

 utilizzando interent.
Personalmente ti suggerirei *wondershaper*.
Non è esattamente quello che vuoi tu, ma in pratica raggiungi lo stesso
scopo.
Se ho ben capito il tuo problema è che quando scarichi qualcosa di
pesante la latenza della navigazione web aumenta tantissimo.
Con questo programma vai in pratica a limitare (di poco) la banda
utilizzabile al massimo dal computer: in questo modo non si satura la
connessione e la navigazione rimane di solito agevole.
Tra l'altro noterai che la velocità di download rimane più costante e
"balla" meno.
Esempio pratico:
#wondershaper ppp0 150 70
-- 
Lurkos

 #wondershaper ppp0 150 70
Ok, grazie mille anche dell'esempio pratico. Devo documentarmi un
po' di più in merito a questo programma.
Certo è che dopo tanti vostri interventi, non siano saltati fuori
un paio di comandi per tc...mi viene da pensare che questo
strumento non sia poi così "alla portata", o così
diffuso....Sicuramente in ambito home è probabilmente
sovradimenionato non so, ma dal canto mio forse perchè vedo la
banda col contagocce, mi aspettavo un attimo più di casi simili
al mio esempio.
Va bè ora mi guard un po' wondershaper. grazie ancora della
risposta e a presto.  :-)

> #wondershaper ppp0 150 70
questo esempio non l'ho capito troppo alla luce di quanto ho
letto nel readme e di quanto vedo dallo script stesso:
io ho messo la versione 1.1a, non so se ti riferivi a qualcosa di
diverso o qualcosa di preimpacchettato cui vi sia stato aggiunto
qualche cosa. Per quanto mi riguarda ho reperito tutto
direttamente dal sito del progetto...e gli eseguibili si chiamano
wshaper che usa cbq e wshaper.htb che appunto sfrutta htb.
Ad ogni modo penso che il discorso non cambi:
ho tenuto il download avviato così come pure il ping e allo
stesso tempo ho lanciato
# wshaper.htb
La velocità di download del file è scesa circa al valore stabilito,
mentre la latenza che aveva valori vergognosi, si è drasticamente
ridotta tornando su tempi di 400 ms e anche meno così come fa
solitamente quando non uso banda.
Insomma, pare proprio che questo script sia tutto sommato un
metodo facile ed efficace per raggiungere uno o più scopi:
- download non presidiato in notturna per esempio.
Con wshaper, posso impostare valori di banda bassi a piacere, in
modo da rendere la connessione più robusta. Infatti (forse che
usa connessioni gprs ne è a conoscenza) connessioni del genere
mal sopportano la saturazione di banda, con la conseguenza che
spesso cadono o si "inchiodino" (mi capitava col vecchio
cellulare che non si riuscisse più a scambiare dati perchè
adirittura lo stesso device andasse in uno stato di "limbo" e
talvolta per sbloccarlo fosse necessario spegnerlo e
riaccenderlo). wshaper potrebbe venire incontro anche a questo
tipo di prolemi.
- utilizzo di applicazioni tipo p2p che vanno meglio se la
  latenza è bassa e i valori di banda non sono saturi.
Per tutto ciò ringrazio molto circa il consiglio di questo
software.
Invece mi pare evidente un limite di wshaper (e non solo a dire
il vero). Mettiamo che stia scaricando con downthemall che
disgraziatamente non prevede la limitazione di banda come
funzionalità inclusa nel programma.
E mettiamo che contemporaneamente stia navigando con firefox.
L'ottimo sarebbe attuare una politica di filtraggio dei
pacchetti, creando due discipline di coda, l'una per i pacchetti
che usa downthemall e l'altra prioritaria per tutto il resto
navigazione compresa. La somma delle due code in termini di banda
dovrà poi essere pari ad un valore opportunamente inferiore alla
potenzialità reale della linea (sempre per tenere bassa la
latenza).
Questo tra gli altri sarebbe un obiettivo a me molto caro.
Il problema, a parte le diavolerie che riguardano l'impostazione
di tc, sta a monte cioè, come fare a riconoscere il traffico
generato da downthemall...non è così facile in quanto il
parametro "user-agent" rilevato al layer7 risulta mozilla o
qualcosa del genere, indistinguibile quindi da quello generato
dallo stesso browser con la conseguenza che se anche riuscissi a
limitare downthemall, limiterei allo stesso valore di banda anche
il browser.
Non vi pare?
Resterebbe anche un altro caso, ma ho già superato le 100
righe...chiedo scusa per la lunghezza sperando comunque che
l'argomento interessi.
Non esitate quindi se potete a commentare la questione. Da parte
mia sono tutto orecchi, penso che una chiaccherata possa essere
d'aiuto a dipanare più dubbi rispetto alla lettura di
diversi documenti che magari prevedono conoscenze più tecniche
già in partenza, rendendo l'argomento un po' fumoso alla
compresione...il tutto IMVVHO ovviamente e senza voler togliere
nulla agli how-to esistenti, indispensabili comunque per
approfondire.
Slauti! :-)

> provare.
IMHO ti stai complicando la vita. Con tutti i download manager e i 
client p2p e possibile limitare la banda in entrata/uscita. hai un 
controllo più fine in quanto lo fai "per applicazione"; mi pare anche 
che con alcuni client sia possibile farlo "per file".
I siti che visiti con una certa regolarità, li puoi anche schiaffare in 
/etc/hosts così eviti la query al server DNS. Se sono tanti, ti puoi 
installare un server DNS "cache only" tipo pdnsd:
http://www.phys.uu.nl/~rombouts/pdnsd.html
Se poi c' dietro uno scopo "didattico" ok, continua per la tua strada :)
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 
http://www.phys.uu.nl/~rombouts/pdnsd.html
A dire la verità uso gia bind, come dns cache...non so se è la
stessa cosa.

 stessa cosa.
Hai presente la storia del bazooka e la zanzara ?


 
http://www.gedanken.demon.co.uk/wwwoffle/
Ci darò un'occhiata. Grazie del consiglio.