From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Mon, 04 Apr 2005 15:23:30 +0000 Subject: Re: [LARTC] new perflow rate control queue Message-Id: <42515BF2.6080308@dsl.pipex.com> List-Id: References: <20050404152117.6d90635d.lark@linux.net.cn> In-Reply-To: <20050404152117.6d90635d.lark@linux.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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,ceil,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