No reorder buffer?
dave.taht at gmail.com
Thu Jun 26 00:24:08 PDT 2014
On Wed, Jun 25, 2014 at 10:10 PM, Denton Gentry <denton.gentry at gmail.com> wrote:
> Following up: to confirm or disprove whether the lack of a reorder
> buffer is a factor in abnormally low throughput from Windows STAs, I
> hacked sta_info_alloc() to allocate sta->ampdu_mlme.tid_rx directly
> instead of allocating it when processing an AddBA from the STA.
the proof of concept patch would be nice.
> Throughput from a Windows system running iperf went up from ~45 Mbps
> to 230 Mbps. A pcap collected by the Ethernet system at the other end
> of the test no longer shows frames delivered out of order.
What windows version?
What is the effect on ios and a modern linux? (before/after fix)
What does it do to latency and how does it effect multiple stations
latency and throughput?
> I suspect a proper fix would involve having the firmware pass the
> AddBA up to the host.
> On Tue, Jun 24, 2014 at 7:47 AM, Denton Gentry <denton.gentry at gmail.com> wrote:
>> I'm bridging ath10k to Ethernet, gathering pcaps on another ath10k
>> system in monitor mode and on the Ethernet system which is receiving
>> the packets. I see packets being delivered out of order to the
>> Ethernet system. So far as I can tell, any packet which has to be
>> re-sent on the Wifi link will be delivered out of order to Ethernet.
>> I believe this happens because there is no reorder buffer.
>> ieee80211_rx_reorder_ampdu returns because tid_agg_rx[tid] is NULL.
>> I believe there is no reorder buffer because
>> ieee80211_process_addba_request is not being called.
>> ieee80211_process_addba_request would allocate tid_agg_rx[tid].
>> I believe ieee80211_process_addba_request is not being called because
>> the firmware processes the AddBA and does not pass it up. This is the
>> part I am least sure about.
>> Can anyone confirm or deny that this is correct: does the firmware
>> process the AddBA, but not have a reorder buffer in the firmware?
>> This is noticeable mostly because of Windows. The Windows TCP stack
>> seems to react more strongly to packet reordering (inferred via SACKs,
>> I guess), and slows down.
> ath10k mailing list
> ath10k at lists.infradead.org
More information about the ath10k