From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B80F53BA8E for ; Tue, 12 Jun 2018 06:24:15 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528799053; bh=MzHcsGmjSChOSKwZz3QGqQ6+rtOnS8qFeg1bIG6rrUo=; h=From:To:Subject:In-Reply-To:References:Date:From; b=EhDXT+GNTrTDDQco0mmFTzi1d4Lu8uK8k0C67Fc2AlVqklkNaCSxdQ7516cwLraUZ YIYLjuTG9G+gbKJkvKq9iznPLNwgZLE5B9C9ZRItQzr0lP08JAUOjaCK5ERFM9bgKD HR0VkDL/Lx8eZr604Zy5wmCHK3QxnIwl2M+Y10/3Vg7fVd5dkgxsQ+KJ2hmJ+nYzLs pfgLbFPSniutforv7mSu499nyLUWLCSNLgyY/inKv4SGmeauIScVEmU+1moqBJcKbl 4mSSY9I4QzR2bU5euDgw6qvSniqn/qnxs+s1gBv3WBbjSaPrh9cEhLptYKXjpAbMci DrwInuN+10LpQ== To: Pete Heist , make-wifi-fast@lists.bufferbloat.net In-Reply-To: <111C85D5-859A-4F2E-8D6E-DA32A4BD5AA8@heistp.net> References: <111C85D5-859A-4F2E-8D6E-DA32A4BD5AA8@heistp.net> Date: Tue, 12 Jun 2018 12:24:13 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in6ojoaa.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] NanoStation M5 anyone? 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: Tue, 12 Jun 2018 10:24:15 -0000 Pete Heist writes: > This is an appeal to anyone who has access to a NanoStation M5 and a litt= le time to try to reproduce this problem and add to this post: > > https://community.ubnt.com/t5/airMAX-Installation/NanoStation-M5-ping-spi= kes-about-once-per-second-even-just-to/td-p/2358704 > > I=E2=80=99ve been trying unsuccessfully to demonstrate to Ubiquiti that t= hey > have a bug somewhere that causes isochronous latency spikes. It seems > what=E2=80=99s happening is that for a fixed period of time (20ms when one > Ethernet port is in use and 40ms when two are in use), once per > second, the device queues packets until the pause is over. The > function ar7240sw_phy_poll_reset in ag71xx_ar7240.c exactly describes > the behavior of 20ms delays when one port is connected and 40ms delays > when two ports are connected, so basically it appears that the > Ethernet / internal switch device is being reset once per second for > some reason. > > So far nobody has seemed to care (after all, who=E2=80=99s counting 40ms = here > or there when it comes to WiFi?), but it does pollute my test results > and may be causing latency spikes wherever these devices are deployed > (like, worldwide). So if anyone else tests this and can add some > weight to the discussion, I=E2=80=99d be glad. :) Does this only happen with stock firmware? I think I have reflashed all of mine... -Toke