On Wed, Apr 6, 2016 at 12:21 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > [removing other lists since they spam me with moderation bounces] I have added your email address be accepted to the codel, make-wifi-fast lists. My apologies for the bounces. The people on those lists generally do not have the time to tackle the volume of traffic on linux-wireless. >> The hope had been the original codel.h would have been reusable, >> which is not the case at present. > > So what's the strategy for making it happen? Strategy? to meander towards a result that gives low latency to all stations, no matter their bandwidth, on several chipsets. The holy grail from my viewpoint is to get airtime fairness, better mac utilization, slow stations not starving fast ones, more stations servicable, and so on, and my focus has generally been on having an architecture that applied equally to APs and clients. Getting clients alone to have a queuing latency reduction of these orders of magnitude on uploads at low rates would be a huge win, but not the holy grail. It was really nice to have michal's proof of concept(s) show up and show fq_codel-like benefits at both low and high speeds on wifi, but it is clear more architectural rework is required to fit the theory into the reality. > Unless there is one, I > don't see the point in making the code more complicated than it already > has to be anyway. +1. Next steps were - get toke's and my testbeds up - avery/tim/myself to keep hammering at the ath9k - michal exploring dql - jonathon poking at it with cake-like ideas - and anyone else that cares to join in on finally fixing bufferbloat on wifi. and maybe put together a videoconference in 2-3 weeks or so with where we are stuck at (felix will be off vacation, too, I think). There are still multiple points where we all talk past each other. Me, for example, am overly fixated on having a per station queue to start with (which in the case of a client is two stations - one multicast/mgtmt frames and regular traffic) and not dealing with tids until much later in the process. Unfortunately it seems the hook is very late in the process. > > johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
