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.
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.
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).
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).
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.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
