From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 0D3633B260; Tue, 26 Apr 2016 19:18:54 -0400 (EDT) Received: by mail-ob0-x231.google.com with SMTP id tz8so14666778obc.0; Tue, 26 Apr 2016 16:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc :content-transfer-encoding; bh=jUFZUS8cAiVXeW7EzbY/m+Ejpi64ZI1hCsqBohV9tw4=; b=RqVEdEjZoVFaobM2I4uO6wFR80IQpYPD9xPmueIR4gjmppkIxRVHR4nKMqSxiJHrRO 6gdV6lhUtYY7fK5KmH4uBawfTPZem2UGznFjbEgSmwSg5q4qg3nnsFjnW1aLIIEY4+iL Wj5A2SBHKx4sEAHlRRgkNcVuVJE8ReyHblv66RUwJ3vqboqp8quZdRnnptIrnUypOOik CC2XXKkyBOOr3id00zSfMJXWPO0X0p603dKodI3v0aeRLZrEdxVPj7tM5kiW6Jj6Yg+/ y/SzYcoHCIEFbrciVaGsHtlHYL5eWSp3Ggq48aMIlozSFENOt2FGXISjHPNs30QxONv4 f2FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-transfer-encoding; bh=jUFZUS8cAiVXeW7EzbY/m+Ejpi64ZI1hCsqBohV9tw4=; b=GPww/emN1zTCElbb8rq7333FrXTSQsdU8FuhQaINH2jCYCwLgBilxL1le9yjmghCg5 237nXnNlOuFGt+p+Kx8AV0XjseCKGpfnugD8wZ6/pwWRNKhUz2VpotymdHGGUabBlMgX +xV7K+v2rLrSKG05nuhwFRHmPd9kvu6PlO8mt6BmRSqmH3LyTCO1xni0qVATG6YGo35z Xpgrmzk4nk+2HQXbe9BMYf3Qg0Yq82ISfvwXNuXkdeKxN1G1asp7sCOb0evot8E8YrcD oDktdVxxO4C0obycKXTseCwgHSgcNTfQjuPjpnOD/giRLs20LTR71mujQH8zJtU8vsfU //NA== X-Gm-Message-State: AOPr4FVkayXlftZa/ZZPU3yO+wskxEHAkNnYgIRn4/IMNxU/Fsx5urTZneUwuafT2M6ZR7chh0Fqr95tMnObKQ== MIME-Version: 1.0 X-Received: by 10.60.52.177 with SMTP id u17mr2301823oeo.61.1461712734228; Tue, 26 Apr 2016 16:18:54 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Tue, 26 Apr 2016 16:18:54 -0700 (PDT) Date: Tue, 26 Apr 2016 16:18:54 -0700 Message-ID: From: Dave Taht To: "babel-users@lists.alioth.debian.org" Cc: Michal Kazior , "cerowrt-devel@lists.bufferbloat.net" , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Make-wifi-fast] perverse powersave bug with sta/ap mode 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, 26 Apr 2016 23:18:55 -0000 Pain shared, reduced, joy shared increased... for weeks now I've been puzzling over why a variety of links flapped the way they did, routes coming and going, failing over to weird paths, and I think I have finally isolated one part of the problem. In an age where adhoc does not work particularly well, and AP/sta mode does (as in 6mbit vs 500 in one case), I've had a tendency to nail up links in ap/sta mode. Well, at least one ( probably several) of the devices I have in the new lab has *very aggressive* power save, to where babel ipv6 multicast traffic either doesn't sync up to the AP's request for multicast (or the sta's), or it is merely completely suppressed by the stack. (or lost due to a bug!)... Anyway... So long as there is unicast traffic on the local part of the link, you don't see a problem. And there's almost always a bit of traffic on the link. So, perversely... like when I'm looking at it... ssh'd through to the other side, running something like "watch tc", or like, pinging from one side of the link to the other... it works. When I go away for a bit... it fails. Eventually. If I run a test, after getting everything all setup and verified the network looks correct... it works. If I walk away and run a test that has a few minutes :grump: between runs to let things "settle down", things actually deteriorate. Babel misses multicast traffic and gradually increases the metric on that interface due to the loss - causing a given route, in my case, to eventually fall over to an adhoc wifi radio elsewhere on the network, which reduces the probability of unicast traffic through that link still more, until ultimately the local link, otherwise nailed up, drops off the network completely. to "fix" this: iw dev wlp4s0 set power_save off worked beautifully on the ath10k driver I'm using. The babel metric stayed stable, the route stayed stable, life was good, throughput increased, latency dropped... That said, I know how hard wifi device driver writers are hammering at trying to reduce multicast effects, and save power... and I haven't exactly found the root cause of this problem, in this driver... (or in the ath9k on the AP side) but I think I've seen it elsewhere also, while chasing this -l failover issue. multicast beacons are supposed to say "hey, chips, wake up, you need to hear this". --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org