From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 50DBB3CB4B for ; Thu, 22 Feb 2018 07:32:12 -0500 (EST) 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=1519302731; bh=qf8gRs0AuSVoudTAEStevCUoxFYmS2df7v2AhS1Zf0I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=w73RFb4XYPJ0rf7klYEdcALE9dbXHzOlX/y0ZJP+ImfgVG0hUCZxUQ5i3nooHLfH1 uHIyl5GowCiGsNt/GLNwFuQVoHr+aMR9jlfGiO5O55k7KvmU0OYcQDzgmir0hgUPeF vN3Nr3wdetomNhrtipI2f+IAXYzCdJtxGh+dX25kRo6KjtccyMhBNHJ8FWkb9de4ER RL/Z4ZuZwy0uZG2/xqEa0oOtJjJ6DE+9QSHaozMFTfwydkIB7fW1DxVbi1LyClGF7Y sZLCKPTHv7yBww+HLlewbsw/9coNKkuHj4HB7qZgRnjaUGBQoPga01obGc5MtBmo2/ zXiolyGHcIP+w== To: Pete Heist Cc: make-wifi-fast@lists.bufferbloat.net In-Reply-To: <431766C8-135F-4A69-85DA-784A1D2C4ED0@gmail.com> References: <20180219170224.14816-1-toke@toke.dk> <20180222101848.18772-1-toke@toke.dk> <431766C8-135F-4A69-85DA-784A1D2C4ED0@gmail.com> Date: Thu, 22 Feb 2018 13:32:05 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fu5tqk6y.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH v2] iw: Print TXQ statistics for stations and interfaces 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, 22 Feb 2018 12:32:12 -0000 Pete Heist writes: >> On Feb 22, 2018, at 11:18 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Sample output: >>=20 >> $ iw dev wlp2s0 station dump -v >> Station xx:xx:xx:xx:xx:xx (on wlp2s0) >> [...] >> TXQs: >> TID qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-pack= ets >> 0 0 0 0 0 0 0 0 0 0 >> 1 0 0 0 0 0 0 0 0 0 >> 2 0 0 0 0 0 0 0 0 0 >> 3 0 0 0 0 0 0 0 0 0 >> 4 0 0 0 0 0 0 0 0 0 >> 5 0 0 0 0 0 0 0 0 0 >> 6 0 0 0 0 0 0 0 0 0 >> 7 0 0 0 0 0 0 0 0 0 >> 8 0 0 0 0 0 0 0 0 0 >> 9 0 0 0 0 0 0 0 0 0 >> 10 0 0 0 0 0 0 0 0 0 >> 11 0 0 0 0 0 0 0 0 0 >> 12 0 0 0 0 0 0 0 0 0 >> 13 0 0 0 0 0 0 0 0 0 >> 14 0 0 0 0 0 0 0 0 0 >> 15 0 0 0 0 0 0 0 0 0 >> [...] >>=20 >> $ iw dev wlp2s0 info >> Interface wlp2s0 >> ifindex 9 >> wdev 0x1 >> addr xx:xx:xx:xx:xx:xx >> type AP >> wiphy 0 >> channel 165 (5825 MHz), width: 20 MHz, center1: 5825 MHz >> txpower 24.00 dBm >> multicast TXQ: >> qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets >> 0 0 72 0 0 0 0 7380 72 >>=20 > > Could these stats make possible a userspace tool for determining the > proportion of delay that is introduced by congestion vs by link layer > issues? Such a tool could be really helpful for network engineers > wanting to mitigate delay issues and not sure where to best focus > their efforts... Well you could combine the amount of backlogged data with the rate control information and estimate the current queue drain time for each station I guess. It would technically also be possible to directly expose the queueing time of the last dequeued packet (as measured by CoDel) as part of the statistics. -Toke