From: Martin Devera <devik@cdi.cz>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SFQ improvement ideas
Date: Wed, 16 Jan 2002 10:07:37 +0000 [thread overview]
Message-ID: <marc-lartc-101117575820408@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101094979511667@msgid-missing>
> > either sorted queues (log N) or cycle on head of queue until all
> > expired ones are deleted. But it doesn't preserve fairnes IMHO.
> > In any way I'll think about it :)
> You're thinking of removing a packet when it has been in the queue too
> long. I'm thinking of something much easier. When you dequeue just
> check to see it's not too old. If it is then discard it and go on to
> the next one. I admit that this could result in a large amount of
> work for one packet dequeued, but that work translates into much more
> time saved by not sending old packets.
It is exactly what I meant by "cycle on head of queue". But
compare it with queue depth limiting. When you know rate and depth
you can compute the oldest packet on the queue. So that it will
assure the same for you but with less of work and less of storage
(packets are dropped at enqueue).
> > it is better determined by bytes send. Hi-load traffic is for
> > example long ftp download.. I'm not sure how to detect them yet.
> > See www.cisco.com, IOS documentation, QoS section.
> I have looked there. Perhaps we simply interpret the contents
> differently.
Maybe :) How do you interpret it ?
> > > > Nice effect is that short conversations are handled faster
> > > > and long downloads are isolated with lower priority.
> > > Isn't this just what you get from a queue for each flow?
> > > I thought that's what WFQ did.
> >
> > No. For flows A,B,C,X where X is interactive one the nornal SFQ
> > schedule is: ABCDXABCDX.... and WFQ is AXBXCXAXBXCX.... Thus lower
> > delay.
> (Except for the D's I guess.)
> Again, where do you see this? I've not seen anything in Cisco doc
> that says this.
I quote:
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/fun_c/fcprt4/fcperfrm.htm#xtocid128886)
------
Weighted fair queueing can manage duplex data streams, such as those
between pairs of applications, and simplex data streams such as voice
or video. From the perspective of weighted fair queueing, there are two
categories of data streams: high-bandwidth sessions and low-bandwidth
sessions. Low-bandwidth traffic has effective priority over high-bandwidth
traffic, and high-bandwidth traffic shares the transmission service
proportionally according to assigned weights.
------
devik
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
prev parent reply other threads:[~2002-01-16 10:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-13 19:21 [LARTC] SFQ improvement ideas devik
2002-01-13 21:06 ` John Huttley
2002-01-13 21:10 ` Daniel Wittenberg
2002-01-14 2:02 ` John Huttley
2002-01-14 4:23 ` Daniel Wittenberg
2002-01-14 5:13 ` Don Cohen
2002-01-14 9:35 ` Martin Devera
2002-01-14 9:36 ` Martin Devera
2002-01-14 9:38 ` Martin Devera
2002-01-14 9:54 ` Martin Devera
2002-01-14 14:56 ` Michael T. Babcock
2002-01-14 22:33 ` Don Cohen
2002-01-16 9:46 ` Martin Devera
2002-01-16 10:07 ` Martin Devera [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-101117575820408@msgid-missing \
--to=devik@cdi.cz \
--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.