* Re: [LARTC] Download and upload independency
2006-01-18 9:38 [LARTC] Download and upload independency Diego Cabrero
@ 2006-01-19 16:07 ` gypsy
2006-01-20 13:20 ` Diego Cabrero
2006-01-21 5:15 ` gypsy
2 siblings, 0 replies; 4+ messages in thread
From: gypsy @ 2006-01-19 16:07 UTC (permalink / raw)
To: lartc
Diego Cabrero wrote:
>
> Hello everyone:
> As it is known, when you limit uplink bandwidth it usually gets downlink
> bandwidth to a lower value.
> I just want to know what is the optimal configuration for eth1 and imq0
> according to some variables of tc(HTB), txqueuelen, mtu, etc. to make
> these packet flows less independent on an ethernet based network.
>
> Thank you in advance.
>
> -Diego
Diego,
Since nobody else answered this, I'll give it a try.
I accelerate all small packets on the egress side because this sends the
ACK packets ASAP. Doing this improves download speed.
I use 'quantum 1514', 'prio #' and 'burst #k' in my 'tc class add'
lines. E.G.:
tc class add dev eth1 parent 1:1 classid 1:20 htb rate $RATE ceil \
$CEIL burst 16k quantum 1514 prio 2
Make sure the sum of the rates is <= the parent rate. Some say it is
better to patch htb to deque one packet at a time rather than 2. I
don't.
Be sure you change your linux kernel source
vi ~linux/include/net/pkt_sched.h
so it uses PSCHED_CPU because JIFFIES just does not cut the mustard.
I am just now implementing IMQ. What a pain getting it to compile (bad
linux 2.4 patch)! I can't say yet if this is the right approach, but I
intend to accelerate SSH and put everything else into a default bulk
class, adding an esfq qdisc:
~'parent 1:20 handle 20: esfq limit 64 depth 64 divisor 10 \
hash dst perturb 20'
and then filter SSH by source and dest port 22 into accelerated 1:10. I
want to shape the incoming flows by where the packets come from - but I
might change my mind after I try this :o
I looked at documentation on the DSL sites about tweaking, then at Oskar
Andreasson's tutorial to understand the /proc settings, but I can't find
my notes about what I changed. I did increase buffer sizes, but I can't
recall anything further right now... IIRC, most things were correct so
I did not change much.
--
gypsy
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [LARTC] Download and upload independency
2006-01-18 9:38 [LARTC] Download and upload independency Diego Cabrero
2006-01-19 16:07 ` gypsy
2006-01-20 13:20 ` Diego Cabrero
@ 2006-01-21 5:15 ` gypsy
2 siblings, 0 replies; 4+ messages in thread
From: gypsy @ 2006-01-21 5:15 UTC (permalink / raw)
To: lartc
> Diego Cabrero wrote:
>
> All right, so priorizing ACK packets is one of the solutions. Then, do
> you use 1:20 class for ACK packets?
Please don't post in HTML. My Email reader was full of crap like <br>.
I create what I call an interactive class. I have a "T1" radio
connection to the internet, so my upload rate is 1500kbit which I
strangle to 1350 (90%). The interactive class has a rate of 200kbit,
ceil of 1350kbit and prio 1 so it can borrow from all other classes (but
it never needs to; I should find out how low rate can go but I haven't
had time to do that). I set this up as 1:10 but I don't think the
classid really matters (although I'm not sure). The rate, ceil, prio
and burst do matter. Quantum is there because that lets me set any rate
I want without having htb complain about r2q and because it is correct
for ethernet.
> Or just by setting the parameters
> 'quantum 1514', 'prio #' and 'burst #k' is enough to do it inside
> whatever traffic runs through 1:20?.
Not if I understand what you are asking. You need a class that has
nothing going through it except really important traffic (SSH and ACK
for me), so you do not want anything else in it. I do not use esfq on
this either. All my other classes use esfq (which is why I maintain it
for 2.4 kernels).
If I had two classes and I was going to create an interactive one, I'd
steal a bit of bandwith from each of the other two, making sure they are
set up to lend. It does not take much just for ACK.
> In case you assign one whole htb class for ACK packets,if i am not
> using priority bands (just ensuring VoIP´s QoS) is it so simple as
> asignate them a low bandwidth (1Kb) and higher priority?
Almost. Along with low bandwidth you need a big ceiling and the HIGHEST
priority so it can borrow when necessary. But since the packets are
small, you don't need a big burst.
For VoIP, you need to try to keep it's class from lending when there is
traffic and you sure don't want (e)sfq because that reorders the
packets, which likely will disrupt your conversation.
If everything is prio 0 (no prio specified), you can't be sure which
class will lend spare bandwidth first.
> Thanks a lot.
>
> -Diego
You're welcome if this helps, otherwise you don't need to thank me ;)
--
gypsy
> gypsy escribió:
>
> > Diego Cabrero wrote:
> >
> >
> >> Hello everyone:
> >> As it is known, when you limit uplink bandwidth it usually gets
> >> downlink
> >> bandwidth to a lower value.
> >> I just want to know what is the optimal configuration for eth1 and
> >> imq0
> >> according to some variables of tc(HTB), txqueuelen, mtu, etc. to
> >> make
> >> these packet flows less independent on an ethernet based network.
> >>
> >> Thank you in advance.
> >>
> >> -Diego
> >>
> >>
> > Diego,
> >
> > Since nobody else answered this, I'll give it a try.
> >
> > I accelerate all small packets on the egress side because this sends
> > the
> > ACK packets ASAP. Doing this improves download speed.
> >
> > I use 'quantum 1514', 'prio #' and 'burst #k' in my 'tc class add'
> > lines. E.G.:
> > tc class add dev eth1 parent 1:1 classid 1:20 htb rate $RATE ceil \
> > $CEIL burst 16k quantum 1514 prio 2
> >
> > Make sure the sum of the rates is <= the parent rate. Some say it
> > is
> > better to patch htb to deque one packet at a time rather than 2. I
> > don't.
> >
> > Be sure you change your linux kernel source
> > vi ~linux/include/net/pkt_sched.h
> > so it uses PSCHED_CPU because JIFFIES just does not cut the mustard.
> >
> > I am just now implementing IMQ. What a pain getting it to compile
> > (bad
> > linux 2.4 patch)! I can't say yet if this is the right approach,
> > but I
> > intend to accelerate SSH and put everything else into a default bulk
> > class, adding an esfq qdisc:
> > ~'parent 1:20 handle 20: esfq limit 64 depth 64 divisor 10 \
> > hash dst perturb 20'
> > and then filter SSH by source and dest port 22 into accelerated
> > 1:10. I
> > want to shape the incoming flows by where the packets come from -
> > but I
> > might change my mind after I try this :o
> >
> > I looked at documentation on the DSL sites about tweaking, then at
> > Oskar
> > Andreasson's tutorial to understand the /proc settings, but I can't
> > find
> > my notes about what I changed. I did increase buffer sizes, but I
> > can't
> > recall anything further right now... IIRC, most things were correct
> > so
> > I did not change much.
> > --
> > gypsy
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 4+ messages in thread