User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

en:developers:brainstorming:ap-bufferbloat-problem [2015/01/26 09:49] (current)
Line 1: Line 1:
 +I was thinking about bufferbloat & how to counter it in mac80211, in particular on the AP side, and had some thoughts about how it compares to wired, so I'm dumping some things here. 
 +Consider a typical **wired** scenario: ​
 +<​code>​machine A === 1000mbps link ==== [switch] === 1000mbps === machine B
 +                                     |
 +                                     +--- 100mbps link --- machine C</​code>​
 +Now say A is pumping data to both B and C at very high speeds. Obviously the switch in the middle will start buffering a bit, and then drop frames to C, so the stream there will back off quite quickly. If you attempt to pump data to both at 300 mbps, the link to B will not be affected at all. 
 +In wireless though, there'​s no switch in the middle. Say A is the AP, 3x3 HT, B is a client with 3x3 and C is a legacy 11g client. The maximum throughput to B might be 300mbps (is that even realistic? no matter) but to C it'll be 24mbps at most. However, here airtime is the limit, and A can't send 300+24mbps like it could on wired. ​
 +Obviously the fairness here will be different, and what should it be? Should both get the same throughput, even though that probably means C uses 80+% of airtime? Should both get the same airtime, so they can get 150 and 12 mbps respectively? ​
 +Regarding bufferbloat though the issue is worse because deeper queues are needed to feed the link to B than to C, but all the frames are sitting on the same queue today. And we really don't want to reserve 2007*4 queues (max stations * ACs) all the time ... 
en/developers/brainstorming/ap-bufferbloat-problem.txt ยท Last modified: 2015/01/26 09:49 (external edit)