From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Wed, 17 Nov 2004 01:15:15 +0000 Subject: Re: [LARTC] SEPARATING VOIP AND SURFING Message-Id: <419AA623.60305@dsl.pipex.com> List-Id: References: <20041109175203.11372.qmail@web41524.mail.yahoo.com> In-Reply-To: <20041109175203.11372.qmail@web41524.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Jason Boxman wrote: > On Tuesday 16 November 2004 09:53, Andy Furniss wrote: > > >>I would do a bit more work to priorotise dns/empty acks/small tcp etc. >>as well as VOIP, then give them a class with plenty of rate spare and >>make bulk borrow. This would mean that each user would notice a bit less >>the fact they have hardly any bandwidth (if that's the case). > > > Is it really helpful to initially prioritize all TCP handshake packets into > the highest priority? Well it's easy WRT marking :-) the gain can be quite alot for browsing and the ones that aren't as important cost practically no bandwidth anyway (and I see getting all my TCPs up quickly as better - whatever rate/priority the traffic ends up getting allocated). After you walk through your list of traffic and > reclassify flows based on your QoS policy, handshake packets for flows that > matter ought to be properly accounted for. Likewise for flows that aren't > that interesting. For all other flows only having the handshake prioritized > and all else going to a default class can't be that beneficial? I call bulk traffic any that will try to grab bandwidth if left unchecked. I don't just send it to a default class, it's shared per IP and new connections (marked by connbytes) get their own class which gives prio and has a short queue so that packets get dropped quickly and slowstart is ended. > >>Choosing a queue length should really be related to link speed - but you >>can't do this if you have lots of queues whose rate are variable. What >>to choose depends on typical and I suppose worst case traffic situation >>for your LAN. > > > I have not noticed in any of the available documentation I have found any > discussion on how to choose an appropriate queue length. The shorter the > queue, the sooner applications become aware of a bandwidth bottleneck? I > guess the queue just helps deal with short term busts? What rate was sfq's > 128p queue originally targeted at? 100Mbps Ethernet? I can't refer you to any docs, but I try to avoid extremes - and having 20x128 for 512 is an extreme. 3.5 meg x 2 wasted unswappable memory - they could absorb about a minutes worth of data at 512kbit. I would aim for < 1 sec each way, my ISP uses 600ms for 512 - the same for 1meg. As I said though, if you have many classes you have to compromise or each user's queue will be too short. 128 1500 byte packets will queue 1 sec at about 1.5 mbit - I don't know what it was designed for - but if you use alot of them it soon adds up. > > > >>I think these differences are too small to be representative. One packet >>could add 12kbit to a counter instantaneously and how you measure can >>decieve. For one really low rate class the way HTB uses DRR to even out >>fairness for different sized packets could, I think cause short term >>variations. P2P traffic is mixed packet size and quite variable >>depending on peers - so recreating behavior for tests may be hard. I >>don't think queue length is involved here. > > > The difference for that leaf with sfq versus pfifo was pretty consistent. I > should test with different queue lengths for pfifo. Maybe there is a difference - If you want to test with different packet sizes just set mtu on a linux box start a connection set mtu to something different and start another and so on. You will know you are comparing like with like then. I would use sfq for P2P - On the upload side so that 56k users don't get squeezed out by broadband, on download so I don't go and drop the one and only packet that a 56k peer managed to get to me in recent seconds. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/