From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] [LONG] Weights not working
Date: Tue, 29 Jul 2003 07:42:11 +0000 [thread overview]
Message-ID: <marc-lartc-105946464422424@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105919332505371@msgid-missing>
On Tuesday 29 July 2003 07:22, Rio Martin. wrote:
> On Saturday 26 July 2003 13:09, Raj Mathur wrote:
> > Hi Rio,
> > Hmm, so if I understand you correctly you're saying that the QUANTUM
> > in each SFQ should be proportional to the bandwidth allocated to that
> > pool. As per the documents I've read, this must also be >= the
> > maximum packet size.
>
> Not quantum value in SFQ, but R2Q ..
> Perhaps Stef have something more about this, i am just user, i am just
> using this HTB without understanding about how this work more deeper ..
Quantum is a number of bytes. It is calculated as rate / r2q. And r2q can be
set when you add a htb qdisc (default = 10). Quamtum is the number of bytes
that each class can send when they are fighting for remaining bandwidth.
The minimum quantum is 1500 (max packet size). So you can send at least 1
packet. The maximum is 60000 and this is hard coded in htb to prevent class
starvation. If a class has a quantum of 1000000000 it will send 1000000000
bytes before other classes are served. So to prevent this, 60000 is the
maximum.
The rate of a class is the minimum bandwidth a class will get. If all classes
are sending theire rate AND the parent has more bandwidth, each class may
send quantum bytes. So quantum is only imporant if the parent has more
bandwidth then the sum of the rate of the active child classes.
I never changed quantum in a test situation to see what's happing, but there
are reports that you can improve your setup by choosing the right quantums.
Just take quantum not too small (5000 so you can send some packets in 1
turn). But for higher rates, take a higher quantum. But don't give 2
classes 2 total different quantums like 2000 and 600000.
I hope this helps. I know what quantum does, but if you get some real
improvements if you change quantum, let me know so I can update the faq page
on docum.org.
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/
prev parent reply other threads:[~2003-07-29 7:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-26 4:32 [LARTC] [LONG] Weights not working Raj Mathur
2003-07-26 4:59 ` Rio Martin.
2003-07-26 6:21 ` Raj Mathur
2003-07-29 5:22 ` Rio Martin.
2003-07-29 7:42 ` Stef Coene [this message]
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-105946464422424@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.