On Thu, 2007-06-28 at 12:28 +0200, Marek Michalkiewicz wrote: > Do you have an updated version of your patches for the latest > kernel (soon to be 2.6.22), iptables and iproute? Or can the > current patches be safely applied (with some merging by hand, > but no significant changes) to the latest sources? No, not yet. But I am in the process or moving my production systems from Debian Sarge to Etch. In the course of doing that I will produce modified patches. > One more thing: I'd like to do some shaping inside as well, to > help performance of the wireless LAN. So no ATM cell overhead, > but I'm just wondering: what would be the reasonable packet > overhead value to specify in HTB for 802.11b WLAN at 11 Mb/s? I don't know. But I am not sure it matters. The issue you face is HTB, and indeed most qdisc's except perhaps SFQ need to have an accurate idea of the links capacity. In fact, ensuring the kernels idea of the link capacity is accurate for ADSL lines was the entire point of the ATM patches. Any improvement it produces is purely because of the benefit that comes from the improvement in kernels link capacity measurements. So the question you are really asking is "what overhead value will make the kernels idea of a wireless connection accurate". The answer is: none. The capacity of a wireless connection fluctuates greatly. For example, it will go down someone turns a microwave oven on, or if someone walks by with cell phone with bluetooth turned on. Compared to these real-life functions the frame overhead is just noise. What you need is a qdisc that doesn't require the link capacity specified when it is created, but instead infers it from the current transmission rates. HTB does make scheduling decisions like this when the link is over committed, but it is strictly on a priority basis, ie like the existing pfifo_fast qdisc. I imagine this isn't flexible enough for you. I don't know of any that is. But I haven't looked at HFSC closely. I an cc'ing this to the list. There are people there who know more the various qdisc's than me. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
