Re: [Make-wifi-fast] wifi airtime fairness patches could use eyeballs and testing

[Dave Taht <dave.taht@gmail.com>]

On Thu, Aug 11, 2016 at 12:45 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Jonathan Morton <chromatix99@gmail.com> writes:
>
>>> On 11 Aug, 2016, at 01:05, Toke Høiland-Jørgensen <toke@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.

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...

>
> -Toke



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org