All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian Worm Mortensen" <worm@dkik.dk>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] CBQ and WRR
Date: Wed, 28 Mar 2001 14:22:26 +0000	[thread overview]
Message-ID: <marc-lartc-98578938627845@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98567886104582@msgid-missing>

Hi,

> > Maybe I will read it some day ;-)
> 
> I think you _Must_ (especially if you are implementing WRR). There are
> some good ideas there

Yes... I will.. 

> > Well, the WRR qdisc essentially works this way:
> >
> > * For each band (=class) there is a byte counter
> > * When a band transfers a packet the byte counter is
> >    increased by the packet size divided with the weight (which is a
> >    number between 0 and 1)
> > * The next band that can transfer a packet is always the one with the
> >   lowest byte counter.
> >
> > It also does some additional things to make sure that when a new band
> > has something to send it can send it immedialty. I don't see any way
> > this scheme can be improved.
> >
> 
> So is this decision on packet by packet?

Yes. The above is done for each packet.

> Are there opportunities that a 'band' could be starved?

No.

> Dont make me go read the Varghese paper again. You should ;->

Without having read the article what is stressed is that it is an O(1) implementaion while WRR as described above is O(lg n) in a simple implementation where n is the number of bands having something to send. It can be improved to O(lg lg w) where w is the word size or maybe to even to O(lg lg n). But I don't think it is worth it and it is not even sure that it would be faster in practice - depending on the size of n, of course.

> > > The original CBQ implementation is the classical WRR;
> >
> > But it did not take the packet size into account?
> 
> It didnt.

Ok... That might explain why I did not see what I expected.


Christian


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

      parent reply	other threads:[~2001-03-28 14:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-27  7:49 [LARTC] CBQ and WRR Rick Goh
2001-03-27  8:26 ` Christian Worm Mortensen
2001-03-27 12:05 ` jamal
2001-03-27 15:23 ` Christian Worm Mortensen
2001-03-28 12:43 ` jamal
2001-03-28 13:03 ` Christian Worm Mortensen
2001-03-28 13:24 ` jamal
2001-03-28 13:36 ` Christian Worm Mortensen
2001-03-28 13:59 ` jamal
2001-03-28 14:22 ` Christian Worm Mortensen [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-98578938627845@msgid-missing \
    --to=worm@dkik.dk \
    --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.