Re: [LARTC] new perflow rate control queue

From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] new perflow rate control queue
Date: Mon, 04 Apr 2005 15:23:30 +0000	[thread overview]
Message-ID: <42515BF2.6080308@dsl.pipex.com> (raw)
In-Reply-To: <20050404152117.6d90635d.lark@linux.net.cn>

Wang Jian wrote:

> This per flow control is good when used for VoIP (Voice and Video).

Ahh yes  - your needs are totally different to mine - with low bandwidth 
I just have to seperate interactive from bulk and use sfq for bulk only 
as if queuing interactive would mean I have run out of bandwidth anyway.

> 
> Let me explain the idea more clear.
> 
> For example, you may have 50 streams. These stream can work perfectly at
> 10kbps - 15kbps.
> 
> With HTB + SFQ, you should give 50*15 guaranteed. but then, if only one
> stream is using this, it can use up to 50*15 guaranteed. You have risk
> of waste 49*15 on it.
> 
> In another hand, if your have more than 50 streams, say, 80 streams.
> With perfect fairness, every stream can get less than 10kbps. The
> quality is not met however, no one is satisfied with fairness.
> 
> So, you have risk of waste and still you don't have guarantee.
> 
> With per flow rate control, you can give a guaranteed 12*65, and set per
> flow control to rate\x12,ceil\x15,limit`. When you have only a few
> streams, you don't worry that you waste bandwidth. If more than 60
> streams occurs, the first 60 streams still works fine.
> 
> Fairness is good, but sometimes, fairness means everyone hurts. If you
> have more than enough bandwidth, you can use fairness to get good QoS.
> But it is not the case when bandwidth is not so enough.

I can see now why you do it this way.

> 
> BTW: Are there any good document for HFSC? I don't even know how it
> works :( Maybe it's can be used to achieve per flow control.

No not really many docs and you can't really do per flow as such - more 
per user/class.

I haven't played with it enough yet, but the strength is being able to 
seperate interactive from bulk and still limit per user/class , without 
making each users interactive wait for other users bulk - at slow rates 
the bitrate latency of single packets can add up enough to messup 
interactive.

> 
> Because this per-flow queue is new, you can add things useful to it.

It does look good :-) I'll test when I get time.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc