From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9798E21F3BC for ; Wed, 15 Oct 2014 12:55:51 -0700 (PDT) Received: from hms-beagle-6.home.lan ([93.194.238.62]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MC8iq-1XVjFL2U2y-008tdB; Wed, 15 Oct 2014 21:55:47 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 15 Oct 2014 21:55:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A129F5B-2EA9-4A48-A3D8-9A978564A20C@gmx.de> References: <1895D16A-1B0F-48C7-B4B5-6FC84CA92F43@gmx.de> <543E624C.8070304@etorok.net> <4F0AE2A6-47C1-4733-9FD0-4D654E6E69BF@gmx.de> To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:/TFLkR8xjAfzutSrLEc4sfItUJamUDsUe3e/HFKWGIGnyRuXx07 mWHPAVwiJNFWq7GRbvqM6iHBgB4FmYB+Usl3Y8ukuQZLNIQeZAQxGgcZx4zZRdxHwb0P5p3 CI28GNlpOsTbGaEqnlObnT4ah9kK4BWD6dXoc0wShyUAxlljZI5vxXZIRfTTkwJ4STOMKNA iYozkWTPd2NsIQRQCmY3w== X-UI-Out-Filterresults: notjunk:1; Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] SQM and PPPoE, more questions than answers... X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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: Wed, 15 Oct 2014 19:56:20 -0000 Hi Dave, On Oct 15, 2014, at 19:28 , Dave Taht wrote: > hmm. The pppoe LLC packets are sparse and should already be optimized > by fq_codel, but I guess I'll go look at the construction of those > headers. Perhaps they need to be decoded better in the flow_dissector > code? So when shaping on pppoe-ge00 one does not see the LLC packets = at all (tested with tcpdump -i pppoe-ge00), since they are added after = the shaping. (tcpdump -i ge00 does see th dllc packets) I have no idea = whether pppd issues these with higher priority or not. >=20 > I also made some comments re the recent openwrt pull request. >=20 > = https://github.com/dtaht/ceropackages-3.10/commit/b9e3bafdabb3c5aa47f8f63e= ae2ecfe34c361855 >=20 > SQM need not require the advanced qdiscs package, if it checks for > availability of the other qdiscs, Well, but how to do this, I know of no safe way, except testing = availability of modules for a known set of qdiscs, but what if the = qdiscs are built into a monolithic kernel? Does anyone here have a good = idea of how to detect all qdiscs available to the running kernel? Best Regards Sebastian > and even then nobody's proposed > putting the new nfq_codel stuff into openwrt - as it's still rather > inadaquately tested, and it's my hope that cake simplifies matters > significantly when it's baked. I already have patches for sqm for it, > but it's just not baked enough... >=20 > Also I think exploring policing at higher ingres bandwidths is = warrented=85 >=20 > On Wed, Oct 15, 2014 at 6:39 AM, Sebastian Moeller = wrote: >> Hi Edwin, >>=20 >>=20 >> On Oct 15, 2014, at 14:02 , T=F6r=F6k Edwin = wrote: >>=20 >>> On 10/15/2014 03:03 AM, Sebastian Moeller wrote: >>>> I guess it is back to the drawing board to figure out how to = speed up the classification=85 and then revisit the PPPoE question = again=85 >>>=20 >>> FWIW I had to add this to /etc/config/network (done via luci = actually): >>> option keepalive '500 30' >>>=20 >>> Otherwise it uses these default values from /etc/ppp/options, and = then I hit: https://dev.openwrt.org/ticket/7793: >>> lcp-echo-failure 5 >>> lcp-echo-interval 1 >>>=20 >>> The symptomps are that if I start a large download after half a = minute or so pppd complains that it didn't receive reply to 5 LCP echo = packets and disconnects/reconnects. >>=20 >> I have not yet seen these in the logs, but I will keep my eyes = open. >>=20 >>> Sounds like the LCP echo/reply packets should get prioritized, but I = don't know if it is my router that is dropping them or my ISP. >>=20 >> I think that is something we should be able to teach SQM (as = long as the shaper is running on the lower ethernet interface and not = the pppoe interface). >>=20 >>>=20 >>> When you tested PPPoE did you notice pppd dropping the connection = and restarting, cause that would affect the timings for sure=85 >>=20 >> Nope, what I see is simply more variance in bandwidth and = latency numbers and a less step slope on a right shifted ICMP CDF=85 I = assume that the disconnect reconnects should show up as periods without = any data transfer=85. >>=20 >> Mmmh, I will try to put the PPP service packets into the highest = priority class and see whether that changes things, as well as testing = your PPP options. >>=20 >> Thanks for your help >>=20 >> Sebastian >>=20 >>>=20 >>> Best regards, >>> --Edwin >>>=20 >>>=20 >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>=20 >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks