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.