From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 6F1353B29E for ; Wed, 4 Jul 2018 17:47:33 -0400 (EDT) Received: by mail-wm0-x244.google.com with SMTP id i139-v6so8068114wmf.4 for ; Wed, 04 Jul 2018 14:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z3CVhiQYlzGcRd3ZOGXG1DLevTyutyf9B6o1AbmFQaA=; b=erbAcI7UesRQyBWcyZd9/FxeQxGF5mAhWd9sVsUCOCPb7s8GFwj6P3SSnvkqjIrwLv m9mGFJtg+XyP0cUDGCogdrweAq8vndGCO53XAyqYQ39Hv9zvWEPafzGUhsRGU8EiRoWE sAu5vPDgKckvH8VZ3d89LQzCtMxu+yzFzP++fUkJj1gwSB188XYyykxlZVJ3YWPcX+KK GRwRQN7yOA/Z1zV+7jgpJEzE/A4mTocInA815Y7gqmgBa2y6UgOH5LXpgUCa6gg4tFi8 UXPo3xxW85pXSFQrDgBgjbjIV8y0APD6q6mTBx6ntS5h2TsJQCCTgvF1bdZgfOSWMpPO 2wSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z3CVhiQYlzGcRd3ZOGXG1DLevTyutyf9B6o1AbmFQaA=; b=eq6EFF8hRMwgm1xNrnYjNdgN9UlYSpmlL7DmmeItNUBDxWuZnV7Jp47OVTAcJejNyo An0KD6hV7F41XR6en81jzpkWJhfyy5FQYu1sp3FzzR2kq8Pjh1Z2yfw0WnLd6E44wgNo zj0jF6RfP2ynKnwbmzthTTbpwFR+pTGTV1OeD6ddgYf/bn7kFU0HgbZtjmk8SPxY1u/k c6fslYSB/+ZdEryv82yOi67JPeZrhH6zbqAG4ecIY4Ugp6ZOm9UoJrHWHJKay4z9gvE3 WN+b+Oz200tFxagfxhgTz2qUkeFNbNk6NFOXATSClxKVGEoetL1PFu0fhmTt/IcNoK9h HlHg== X-Gm-Message-State: APt69E3NKbcfP4K4Q3girCInwstSYZpxukuTU58IdjaS46oUE33z4dSJ cb9wuryFTJfvKlEi3iIsZeBPLw== X-Google-Smtp-Source: AAOMgpdXMUpUWuFwcbIBKvMdW+AcBxMJ7cAYkePDFWFg7rxa6DUBEcgXMNHrVue1qiD8cChPW1/ZQQ== X-Received: by 2002:adf:bc03:: with SMTP id s3-v6mr2840630wrg.211.1530740852528; Wed, 04 Jul 2018 14:47:32 -0700 (PDT) Received: from tron.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id h102-v6sm7508690wrh.60.2018.07.04.14.47.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 14:47:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Pete Heist In-Reply-To: Date: Wed, 4 Jul 2018 23:47:30 +0200 Cc: Make-Wifi-fast Content-Transfer-Encoding: quoted-printable Message-Id: <2EC1279B-76C6-48C0-AED4-E9C4A7D0F004@heistp.net> References: <9E7E043B-2373-46ED-B122-38A287422999@eventide.io> <87d0wu7rbg.fsf@toke.dk> <8A44F1D4-1EB8-4D46-85F9-00C7307FF2D4@heistp.net> To: bkil X-Mailer: Apple Mail (2.3445.8.2) Subject: Re: [Make-wifi-fast] mesh deployment with ath9k driver changes 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: Wed, 04 Jul 2018 21:47:33 -0000 > On Jun 30, 2018, at 9:14 PM, bkil wrote: >=20 > Dear Pete, >=20 > We understand that you are reluctant to share full radiotap wlan > traces due to privacy reasons and collecting them would strain your > infrastructure still a bit more. Thanks for this idea (creative scripts as well!) but I think even the = appearance of sharing the packet traces of guests might cause a problem, = so I probably won=E2=80=99t be able to. > Although we can probably give more informed advice based on the > traces, as a stop gap measure until you finish cabling, you may > consider traffic shaping of the clients to improve QoS. For example, > you may put a hard bandwidth cap on each client (or only those coming > from an AP in question), prioritize HTTP & VoIP traffic and reduce P2P > traffic, depending on what is the biggest data hog. I've been playing with that recently actually. I wasn=E2=80=99t able to = leave it restricted for long before, but just now I set the per-station = limit to 6mbit down / 2mbit up. Some people may not be pleased :), but = let=E2=80=99s see what it does for a few days. One thing I=E2=80=99m surprised by is the amount of data going through = the VO queue (view in fixed width font for sanity): root@Cabin_28:/sys/kernel/debug/ieee80211/phy0/ath9k# cat xmit BE BK VI VO MPDUs Queued: 218711 5303 435 12846236 MPDUs Completed: 18355992 37807 1672 89811026 MPDUs XRetried: 68553 2409 258 2393713 Aggregates: 28796699 262349 2232 0 AMPDUs Queued HW: 0 0 0 0 AMPDUs Completed: 295460430 2306820 317102 0 AMPDUs Retried: 11666516 120541 3006 0 AMPDUs XRetried: 394366 7493 500 0 TXERR Filtered: 198118 1152 41 1202 FIFO Underrun: 86 0 0 2237 TXOP Exceeded: 0 0 0 0 TXTIMER Expiry: 0 0 0 0 DESC CFG Error: 407 0 0 74 DATA Underrun: 4 0 0 1 DELIM Underrun: 617 0 0 20 TX-Pkts-All: 314279341 2354529 319532 92204739 TX-Bytes-All: 643508167 2628424750 1190327282061782753 HW-put-tx-buf: 94881437 1449351 315153 86013757 HW-tx-start: 0 0 0 0 HW-tx-proc-desc: 96148496 1449537 314472 92007898 TX-Failed: 0 0 0 0 And in the aqm driver support I=E2=80=99m not sure what fq_overmemory = signifies (Toke may know that) or if the other stats are within the = expected ranges for this amount of traffic. root@Cabin_28:/sys/kernel/debug/ieee80211/phy0# cat aqm access name value R fq_flows_cnt 4096 R fq_backlog 0 R fq_overlimit 1716333 R fq_overmemory 58786914 R fq_collisions 4100715 R fq_memory_usage 0 RW fq_memory_limit 4194304 RW fq_limit 8192 > Also, could you by any chance set up monitoring of some addition > metrics, like CPU usage, I/O wait, load average and memory usage on > your nodes? Here=E2=80=99s a snapshot of a gateway AP that=E2=80=99s under typical = contentious load in the evening: Mem: 26908K used, 33628K free, 228K shrd, 356K buff, 4368K cached CPU: 8% usr 19% sys 0% nic 42% idle 0% io 0% irq 29% sirq Load average: 0.32 0.20 0.22 1/62 12265 Servicing software interrupts is always a larger portion of the time, = which might be expected. > N.b.: It's a pity that networking trace anonymization tools aren't up > to the challenge. Simple MAC randomization or hashing with data > omission would be just fine for such a use case. I=E2=80=99m also surprised I don=E2=80=99t see an obvious tool to = randomize MACs. In the case of releasing captures of guest traffic = without asking their permission though, I=E2=80=99m not sure any = technical measures would be enough to erase the perception problem, but = pseudonymization of all possible identifying values would theoretically = satisfy GDPR requirements, for example. After that, it would be = extremely difficult (maybe not impossible) without extensive external = knowledge to identify users from their traffic.=