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 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. > > -DiegoDiego, 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
All right, so priorizing ACK packets is one of the solutions. Then, do
you use 1:20 class for ACK packets? Or just by setting the parameters
''quantum 1514'', ''prio #'' and ''burst
#k'' is enough to do it inside
whatever traffic runs through 1:20?.
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?
Thanks a lot.
-Diego
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
> 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. > > -DiegoYou''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