> Jason Boxman wrote: > > On Monday 15 November 2004 20:06, Ricardo Soria > wrote: > > <snip> > > > >>Dear Andy: > >> > >>Very thanks for your answer. However, I need a > little > >>bit more extended explanation. > >> > >>First, you say that I should "back off more from > link > >>speed - total ceils to about 80% and share that > >>between interactive and bulk". So, do you mean > that > >>if I have a total 512Kbit link, and 2 child > classes, I > >>should not divide the whole 512kbit between the 2 > >>classes, but, I should only divide 410kbit between > >>them, and share the remaining 102kbit between > them?? > >>Or do you mean I should only consider 410kbit as > the > >>whole link capacity?? > > > > > > I think he meant to treat your link as if it were > only 410kbit. With some > > testing you can verify just how close to 100% of > your advertised capacity you > > can get, but 80% is often a good place to start. > > Yes that's what I meant. For uplink it's to allow > for link overheads and > with dsl you should be careful about tweaking as it > may be OK at 90% in > a test with bulk traffic - all MTU size packets, but > if there are lots > of small packets the overhead miscalculations may > mean well over limits > at 90%. You can fix this, but not perfectly, with a > patch Ed Wildgoose > sent to this list. > > Incoming traffic is different - your queue is at the > wrong end of the > link. You have to set a lower limit just to have a > queue at all. > 1. So, starting at 80% of total 512kbit bandwidth (410kbit), there would be a waste of 102kbit. Is this completely necessary?? I think this is to ensure I have the queue on my side, and the queue is not on the side of the ISP. But, I fell tempted to think that 102kbit is too much for this purpose, considering that I really have 512kbit all time. What would you finally recommend ?? > > > > > > >>Second, you say that I should not use SFQ as a > >>sub-qdisc, because of the lenght of the queue, > being > >>it ESFQ (new for me) a better choice. But later, > you > >>say I should use SFQ for bulk traffic (I think you > >>refer surfing as "bulk", and voip as > "interactive"). > >>So, should I use SFQ for bulk classes and ESFQ for > >>interactive classes ?? Or, should I use ESFQ for > all > >>leaf classes?? Or, should I use ESFQ for bulk > classes > >>and default (pfifo, I think) for interactive > classes?? > > What I meant was you could either change the sfq > queue length or use > esfq, which lets you choose length (and more). > > In practise you setup HTB so that your interactive > traffic - doesn't > queue - yes you can attach what ever you like to > it's class - and (e)sfq > would be OK, but if packets actually get queued in > it you marking has > failed and bulk got in or you really have run out of > bandwidth. > 2. Could you please tell me a secure and trustworthy way to know if I am having queued packets under this class?? > The point I made was that you shouldn't really send > a mix of traffic to > SFQ which will still cause long delays at low > bitrates and your users > have potentially low rates (depends on what they > do). > 3. I am creating 2 different htb classes, one for interactive, and another for bulk, and also, 2 different sfq inferior classes, one for each service. What else can I do to avoid sending a "mix of traffic" ?? > 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). > 4. If you still have a copy of my script, you can see I am giving "prio 0" to interactive classes, and "prio 1" to bulk classes. I also tested giving prio 0 and prio 1 at filters setup (and also, prio 1 to everybody, I am not so sure what worked better). What else can I do to emphasize interactive traffic priority?? > 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. > > Alternatly if you were prepared to patch and use > esfq you could use it > to roughly share traffic by IP address - which is > nice to save you > marking and because you are able to set the queue > length for the link. > You do though, loose fairness per connection which > may not affect you - > again it depends on usage P2P. bittorrent etc. > > > > > > > > I am curious about this myself. I placed a > default sfq qdisc with the 128 > > queue default on a p2p class that had a rate of > 144kbit and it routinely > > spiked to about 150kbit several times a second. > If I use pfifo with a queue > > length of 10 I find my utilization for that class > at around 146kbit instead. > > Is it the queue length causing this behavior? > > > > 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. > > Andy. > > > --__--__-- Sorry for the annoyances, very thanks in advance. Ricardo. _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
