Hi Jonathan,
On July 30, 2015 11:56:23 PM GMT+02:00, Jonathan Morton <[email protected]> wrote: >Hardware people tend to think in terms of simple priority queues, much >like >old fashioned military communications (see the original IP precedence >spec). Higher priority thus gets higher throughput as well as lower >latency. > >I note also that in 802.11e, leftover space in a TXOP can't be (or at >least >generally isn't) used opportunistically for traffic from another class, >because the four queues are so rigidly separated. > >I think the hardware people are shortsighted in this respect. It's so >easy >to game simple priority queues when there's no filter on the field >controlling it. That's why cake's Diffserv layer works the way it does. >And >if I ever get the chance to do a Wi-Fi specific version, I'll avoid >both of >the above problems. > >- Jonathan Morton Thanks for the insight. Now I Start to realize why my jome network behaves AS it does. When I run RRUL locally from my macbook over WiFi with cerowrt as AP (which if I recall correctly only uses AC_BE) the macbook's send starves the AP and hence the macbook's receive tanks. Since macos seems to exercise the AC_v[I|o] queues, it hogs airtime and and all systems using lower AC classes see less airtime, less bandwidth and higher latency. I guess my gut feeling would be to run the AP always at AC_VO so it does not get starved. But really calling such a system where any station can inflict that much pain/badness on others 'quality of service' makes me wonder. Then again it certainly affects quality of service just not deterministic or overall positive ;) Best Regards Sebastian -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
