From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Mon, 04 Apr 2005 15:10:48 +0000 Subject: Re: [LARTC] new perflow rate control queue Message-Id: <425158F8.4090105@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="windows-1252" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Wang Jian wrote: > Hi Andy Furniss, >=20 > I just tried HTB+SFQ. I replace 'perflow ...' in t.sh with 'sfq'. >=20 > The test result is very bad. The speed is not stable, and speed > variation is too large when considering fairness. >=20 > The HTB is rate=80kbps,ceil=80kbps. I use 7 streams to test. Streams's > speed vary from 3.4kbps to 28.7kbps. The test last about 10 minutes, and > the speeds don't like to converge. >=20 > Maybe the fairness is achived in long run, but it hurts applications > that need bandwidth guarantee. Yes - I can make sfq look bad in tests, if the only difference is dst=20 port then it just doesn't work and if the ip addresses are sequential=20 it's not too good. In practice I use esfq as you can use more hash=20 buckets - but perturb is horrable for the packet reordering. I think perflow is going to be far better for me - just that having low=20 bandwidth means I would never send interactive to sfq anyway and only=20 use it for bulk whose rate is controlled by htb per user and is quite=20 variable - so for me just letting htb do rate would be fine. Andy. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc