Patrick McHardy wrote: > All my testing (quite a lot) in this area so far suggested that queueing > at ingress doesn't work and is actually counter-productive. It gets > worse with increasing signal propagation delays (signal in this case > means congestion indications). I actually wish I never introduced > the stupid IMQ device, it raises false hope and a lot of people seem > to fall for it.
Small clarification: with queueing at ingress I mean queueing after the bottleneck. It might work if you introduce a virtual bottleneck, but in that case in my experience the bandwidth limit you have to use is dependant on the number of TCP flows, so usually you can't specify a limit that will always work, and its wasteful if there is a smaller number of TCP flows. The reason why you would do it, limiting or prioritizing incoming traffic on the _real_ bottleneck, is not achievable of course. Also noteworthy is that policers don't behave any better, and any other schemes I've tried (I also experienced a lot of with TCP rate control) have similar or related problems. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
