From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] htb3 & imq
Date: Fri, 09 Aug 2002 21:20:42 +0000 [thread overview]
Message-ID: <marc-lartc-102892810512118@msgid-missing> (raw)
In-Reply-To: <marc-lartc-102892233106032@msgid-missing>
> $htb class add dev imq0 parent 2:20 classid 2:2020 htb quantum 1096 rate
> 36kbit ceil 42kbit
> $htb class add dev imq0 parent 2:20 classid 2:2021 htb quantum 1096 rate
> 36kbit ceil 46kbit
> the mannual says >>> "..Normaly you don't need to specify quantums
> manualy as HTB chooses precomputed values. It computes classe's quantum
> (when you add or change it) as its rate divided by r2q global parameter...
> " why in thiscase the default quabum reported error/taken too small ? can u
> please elaborate on r2q... how is it calculated, as the mannual says
> default value 10 !
> what does these error signifies?..
Each class can send quantum bytes at a time. You specified quantum = 1096
wich is bigger then the MTU (mostly 1500). If you have a big packet of 1500
byte and a quantum of 1096 byte, you are only allowed to send 1096 byte. But
the packet is sended anyway and a warning message is logged.
Quantum is calculated as rate / r2q. r2q iq by default 10 and can be
overruled if you create the heb qdisc. Quantum can be overruled when you add
a class.
You should choose r2q so that the class with the smallest rate has a quantum
equal to MTU. Because quantum is used by each class to send quantum bytes at
a time, you should take quantum proportional to the rate so each class is
getting the bandwidth you want to get it. So leaving quantum untouched, but
changing r2q is a good choice.
Taking too big quantums can cause delays. All classes can send it's quantum
bytes before the first class may send again. So how bigger the quantum, the
longer it takes before a class can send again.
I have some more info about it on www.docum.org on the faq page.
But not so much as I typed now :)
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2002-08-09 21:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-09 19:45 [LARTC] htb3 & imq Arindam Haldar
2002-08-09 21:20 ` Stef Coene [this message]
2002-08-10 4:58 ` Arindam Haldar
2002-08-10 8:20 ` Stef Coene
2002-08-11 7:29 ` Arindam Haldar
2002-08-12 23:07 ` Tobias Geiger
2002-08-13 7:54 ` Stef Coene
2002-08-13 11:44 ` Arindam Haldar
2002-08-13 17:44 ` Stef Coene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-102892810512118@msgid-missing \
--to=stef.coene@docum.org \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.