Leaving stuff in a buffer in hopes that more will arrive is a terrible idea, proven over and over. However, if you already have a packet waiting to go out, combining packets after that with each other does create some benefit at no cost (reducing negotiation time). Coupled with something like FQ_Codel so that the combined packets are managed properly, and the queue doesn't bloat, there's a likely benefit for small packets in reducing overhead. Of course you want the "turn taking" for packets coming in to the access point from different stations to be "unlumpy" so the maximum *airtime* of a packet (transmission unit size / transmission rate) to be limited, so slow transmitters can't fill up the airtime with low rate, long packets. So you don't want big MTU's on the air link, and you want the air link to discourage occupancy by low-data-rate transmitters. On Thursday, February 12, 2015 5:23pm, "Dave Taht" said: > The max mtu for wifi is somewhere around 2300 bytes. So there is not a > lot of benefit, and all kinds of headaches for other devices. I don't > remember the max mtu for the ag71xx but I think it was 1514+vlan > header only... > > No point. The only case where I can think it is useful is when you are > tunnelling some protocol over another protocol on a wifi p2p link and > don't want to mess with the underlying mtu. That was the use case for > it when I tried to deploy ipv4 over ipv6 with the nat work being done > on the edgepoints a few years back. > > On Thu, Feb 12, 2015 at 1:46 PM, David Lang wrote: > > It occured to me as I was driving home last night that if the APs are > > working to combine packets into a single transmission due to the high > > overhead of independent transmissions, would it possibly improve wifi > > performance to just configure a larger MTU? > > > > Has anyone done any experimentation in this area? > > > > David Lang > > _______________________________________________ > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave Täht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >