From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] above rate and below rate HTB packet dequeuing
Date: Sun, 17 Aug 2003 18:08:54 +0000 [thread overview]
Message-ID: <marc-lartc-106114379904754@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106047502114999@msgid-missing>
On Sunday 10 August 2003 02:16, Martin A. Brown wrote:
> Hello all,
>
> I have a question about the details of HTB packet dequeuing and the effect
> on scheduling of packets queued in different classes. I have been unable
> to answer this question with certainty either by reading the HTB user
> guide [1] or the LARTC FAQ on docum.org [2].
>
> The closest I can come to guessing the answer is the section on burst in
> the HTB user guide [3].
>
> Here's my question:
>
> When a sending class is below rate, how many bytes is the class allowed
> to transmit before another class is serviced?
>
> It seems clear to me from this answer [4] in the LARTC FAQ, that the
> quantum is used to allow each class to borrow from a parent in a turn. Is
> the class also allowed to dequeue only quantum bytes per turn (when above
> rate but below ceil)?
> But, more importantly, when a class is below rate, is it allowed to
> dequeue a maximum of burst packets per turn?
>
> Is this statement, then, accurate?
>
> - below rate, a class can dequeue up to burst bytes per turn
I don't think this is true. I see it like this. The htb scheduler polls each
class to see if the class has some packets. It also checks the tokens and
ctokens to find out how many packets the class can sent.So the number of
packets a class can sent depends on the rate and the polling frequency.
The polling frequency depends on the number of classes to be polled and the
kernel clock timer. That's why changing the kernel clock can change the
accuracy [1].
And I'm not sure, but I thought the htb scheduler has a list of possible
active classes to poll. See "self feed list" on [2]. So it has not to poll
all class but know which classes are ready to sent.
> - above rate, a class can dequeue up to quantum bytes per turn
Agree.
> P.S. Groeten, Stef!
Thx :)
[1] http://www.docum.org/stef.coene/qos/faq/cache/40.html
[2] http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm
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-08-17 18:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-10 0:16 [LARTC] above rate and below rate HTB packet dequeuing Martin A. Brown
2003-08-17 18:08 ` 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-106114379904754@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.