On Thu, Aug 11, 2016 at 12:45 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > Jonathan Morton <chromati...@gmail.com> writes: > >>> On 11 Aug, 2016, at 01:05, Toke Høiland-Jørgensen <t...@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 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
