All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Classless Queues in series...
Date: Wed, 12 Mar 2003 20:36:32 +0000	[thread overview]
Message-ID: <marc-lartc-104750146522185@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104748887802810@msgid-missing>

On Wednesday 12 March 2003 18:07, Ben Clewett wrote:
> I need (or would at lest live very much :) to use two Classless Queues
> in series.
>
> I can't see in the HOWTO how this is done, but guess at something like:
>
> tc qdisc add dev eth0 root handle 1: sfq (etc)
> tc qdisk add dev eth0 parent 1: tbf (etc)
>
> Am I on the right lines here?
Not really.  Like Martin said, some qdiscs can contain classes (htb/cbq).  You 
can add a second qdisc on that classes.  In fact, each leaf class contains a 
qdisc.  By default this is a pfifo qdisc, but you can replace it with a 
classfull qdisc.  And you can add a third qdisc to the classes of that second 
qdisc and so on.
But each qdisc introduces a new queue so extra delays.

> I also have a small problem with TBF...  From the HOWTO sec 9.2.2, it is
> surgested that a value for the 'burst' should be:
>
> "For 10mbit/s on Intel, you need at least 10kbyte buffer if you want to
> reach your configured rate!"
>
> Therefore: burst => rate * (8 / 1000)
>
> However, I find using this I get stall on ftp and other common
> protocols, when they get above the throttle rate, with low bandwidths
> (eg, 64kbit/sec).  --  Or I completelly fail to understand the above
> statement...
The minimal burst is the amount of packets you can check between 2 updates.  
And this depends on the internal clock used by the kernel.  Say this clock 
checks the rate each 1/10 second.  And you have a rate of 1mbit/s.  Then you 
need a minimal burst of 0.1mbit.  If your burst is lower, say 0.05mbit, you 
only can send 0.05mbit each time your timer checks the tbf so you have a rate 
of 0.5mbit/s.

> Does any person have a better method for calculating a good value for
> 'buffer' ?
No.  But the bigger the buffer, the more time a packet can stay in the bufffer 
so the deay can go up.

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/

      parent reply	other threads:[~2003-03-12 20:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-12 17:07 [LARTC] Classless Queues in series Ben Clewett
2003-03-12 17:52 ` Martin A. Brown
2003-03-12 20:36 ` 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-104750146522185@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.