[Cerowrt-devel] [Make-wifi-fast] wifi airtime fairness patches could use eyeballs and testing

[Toke Høiland-Jørgensen]

On 11 August 2016 08:43:46 CEST, Dave Taht <dave.taht at gmail.com> wrote:
>On Thu, Aug 11, 2016 at 12:45 AM, Toke Høiland-Jørgensen <toke at toke.dk>
>wrote:
>> Jonathan Morton <chromatix99 at gmail.com> writes:
>>
>>>> On 11 Aug, 2016, at 01:05, Toke Høiland-Jørgensen <toke at toke.dk>
>wrote:
>>>>
>>>> There are cwnd reductions, yes, but are they drops? My thought was
>>>> that they were retransmissions caused by OOO packets?
>>>
>>> You should be able to find the retransmitted packets, in that case.
>>> But FQ shouldn’t be reordering packets within the same flow.
>>
>> No, but the WiFi retransmission logic might. Specifically, the ath9k
>> will put packets in a retry buffer that takes precedence over new
>> packets when building aggregates. But since it has one or two
>aggregates
>> built already by the time it does this, reordering can occur that
>way.
>>
>> Now, digging in to the packet traces (looking at the single flow
>case,
>> since that is easier to follow), there's a ~320k segment of the
>sequence
>> space that is about 1.5MB and 200 ms late (sequence numbers 10044929
>> through 10370177 show up after sequence number 11617665 at around the
>> 12k packet mark in the trace). This is nine full aggregates being
>> reordered.
>>
>> I'm not really sure the reordering mechanism described above can
>account
>> for this, unless there are some pretty serious hardware buffering
>going
>> on that we are not aware of. Does anyone else have any ideas?
>
>>From a bug finding perspective, disable fq as per the original patch,
>and try again, look for reordering.

Yes, though this was on a single flow test. Having thought it over some more, it could also be that the aggregates were simply lost entirely and retransmitted (the capture was taken at the receiver). Would make more sense from a timing perspective; but then we still need to explain why eight consecutive aggregates were lost.

I'll do some more tests and take captures at both ends.

>The question I have is does this also happen on x86? A thought is that
>we're interacting with a mips specific bug in header parsing...

Don't think so, at least not in the same pattern. But the physical environments are also fairly different...

-Toke