From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DF7C63B25E; Thu, 11 Aug 2016 05:16:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk EFCF540D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1470907012; bh=TXRDiOjY66Mp+C0EjvAmbnvUp1QfiyM+xsTL+hdRTi0=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=FM1ijH9XBsrSpeb2+ZAzE7IHfUjb5/DxEttjrnb703v5kEdc3TimquhtS/O8pdyNA KHJimuzvNZf3e0veyY4E6uuOcU420neCjba1gU6Ifq4iCZeiaEUalZJg4NJdkPtoFW aiptUExjAeue8r+ejkLlOuPIyL+qRsiCpgWL1AEo= In-Reply-To: References: <76eb6a6a-2f39-3b36-d4c1-04198083c0f6@gmail.com> <87oa50acnr.fsf@toke.dk> <87bn109tv8.fsf@toke.dk> <877fbo9t4v.fsf@toke.dk> <736D102C-3383-457B-96C4-D1B1403F48AE@gmail.com> <8737mc9rav.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= Date: Thu, 11 Aug 2016 11:16:48 +0200 To: Dave Taht CC: Jonathan Morton , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" , Felix Fietkau X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <1EFE69FE-F1FB-4ED3-B36D-7C20C59A7F0C@toke.dk> Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] wifi airtime fairness patches could use eyeballs and testing X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 09:16:54 -0000 On 11 August 2016 08:43:46 CEST, Dave Taht wrote: >On Thu, Aug 11, 2016 at 12:45 AM, Toke H=C3=B8iland-J=C3=B8rgensen >wrote: >> Jonathan Morton writes: >> >>>> On 11 Aug, 2016, at 01:05, Toke H=C3=B8iland-J=C3=B8rgensen >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=E2=80=99t 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 m= ore, it could also be that the aggregates were simply lost entirely and r= etransmitted (the capture was taken at the receiver). Would make more sen= se 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 enviro= nments are also fairly different... -Toke