> well, we're getting there. the results of both patch attempts were > really nice, and brought encrypted performance with fq back into line > with unencrypted. Still running crypted tests as I write... > > So fixing TKIP would be next, forcing the AP to use that? What other > scenarios do we have to worry about? WDS? > I don't think there's anything else, I just don't really feel it's getting anywhere. This is a mere symptom of the design. Felix had worked around the SN assignment in a similar way, but I feel that perhaps the whole thing isn't quite the right architecture. Why are we applying FQ after the wifi conversion, when clearly that doesn't work well? Seems to me that it would make more sense to let the frames sit on the queues as they come in, and do most of the wifi handling only when needed (obviously, things like control port would still have to be done). We even count those packets that are dropped for TX statistics, which would seem to be a big behavioural difference vs. applying a qdisc. Now, it's unlikely to be that simple - fragmentation, for example, might mess this up. Overall though, I'm definitely wondering if it should be this way, since all the special cases just add complexity. johannes
