No reorder buffer?

[Dave Taht]

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[0] 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
> http://lists.infradead.org/mailman/listinfo/ath10k



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article