From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7C48F3B25E; Thu, 11 Aug 2016 02:43:49 -0400 (EDT) Received: by mail-it0-x22f.google.com with SMTP id x130so6093847ite.1; Wed, 10 Aug 2016 23:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=c1ArstAHNF0HGbWsDor0VTmCXh6GqVVaBYdD2mJyPMc=; b=f3HBk1q08ctgnTySmBONJsj0SO6y/Ud3paNzrVDmRPEsFNIK1EU3kBa3OW3ozzBAjC du2iwZMUvKUr27HoODMuts6lsz0XdQm1KNt4jNxZDrqQJh7foPXeGJmDN2V7ljwlQG2Y xUXNZhEjAEdZxO8Ug1KcXparl8jFU+HfVf1Zb9sDbPKYDj70iUUPT9Qbo/qP3xdOrRKh cV+Uj1P0XcaPWY2PKGdLPiQJ9ErogL/7if2MtNEinkH2bTQRvSgAI1bAyycNN3nLnlpM 6NsHQDqtiLOvuLId0DjHCwv+Ta6Vq7c7UfmeRTk7mP3cylfeaDjSS5lzYTPi2HNdAsiy YbPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=c1ArstAHNF0HGbWsDor0VTmCXh6GqVVaBYdD2mJyPMc=; b=lNLZd/JxfsK7t3ILVJziOlP+gudZ0XAmv0yNqtTQsKRbECXKV3HG4UlFQLB0i77DUe kLBPiAUTKqNgnO7N66DrmLdWh2uAopL3zFX41/+Eq8mpWeRBHltz/kaWvb6dkB7nmfdD YF6q50dttX7tY00PQVREJB33dQE/cs88qltwrX54vJiyE2aQxgqyBtBNzeX4GEyN6jiW tY9NcgOdPk5lRB8aYP+b9EBM0VG/yHNBz21ilDqjISx4HQYrcpHDPmhKYO1iAu7XCRl9 jhZpw501aVg9eE7Mxut4K5weBWHyPumCo33Jg/qM+4eFjMEApyP56mLDxNCgdVSUYRBZ JVbg== X-Gm-Message-State: AEkoouvn5AUfRQaasEZsd1+QUp8SyWb1jI1MHILymwx0BUmZijT8P9S49ymN1c9Q4xSAgEoo6rEm4+pPr9RmAQ== X-Received: by 10.36.92.206 with SMTP id q197mr8106413itb.46.1470897828913; Wed, 10 Aug 2016 23:43:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.101.207 with HTTP; Wed, 10 Aug 2016 23:43:46 -0700 (PDT) In-Reply-To: <8737mc9rav.fsf@toke.dk> 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> From: Dave Taht Date: Thu, 11 Aug 2016 08:43:46 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Jonathan Morton , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" , Felix Fietkau Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] [Make-wifi-fast] wifi airtime fairness patches could use eyeballs and testing X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 06:43:49 -0000 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. 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 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org