From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 6123121F19A for ; Thu, 19 Mar 2015 01:37:45 -0700 (PDT) Received: from u-089-d066.biologie.uni-tuebingen.de ([134.2.89.66]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3j17-1ZPW9U207V-00rJQF; Thu, 19 Mar 2015 09:37:41 +0100 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: Thu, 19 Mar 2015 09:37:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BA5CC6C-C27F-4EE0-8EBA-6AD081EF8901@gmx.de> References: <1895D16A-1B0F-48C7-B4B5-6FC84CA92F43@gmx.de> <5509F8B1.6090608@gmail.com> To: David Lang X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:C6SwBxi0JBzjkyTeSJZ7r76WELH3FnCH6JRt2VXWJ6pK40kTsuD +dZNdd0mWqOX89CLuvTpfBnwqyiJZflll2Y6fW7KuxJrYW6+gzUBf3uMWipqIJwcznQx3U8 RL3+Bkz52Uw/Qm1ChlaCcpg+7YGJrIih4XYEmzJnqJnZqRpKFNzMWLsI/mNG2sgL+wNC2es 6UzZbPoNqH+FomdmspklQ== X-UI-Out-Filterresults: notjunk:1; Cc: Alan Jenkins , cerowrt-devel 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: Thu, 19 Mar 2015 08:38:15 -0000 Hi David, On Mar 19, 2015, at 03:43 , David Lang wrote: > On Wed, 18 Mar 2015, Alan Jenkins wrote: >=20 >>> Once SQM on ge00 actually dives into the PPPoE packets and >>> applies/tests u32 filters the LUL increases to be almost identical = to >>> pppoe-ge00=92s if both ingress and egress classification are active = and >>> do work. So it looks like the u32 filters I naively set up are quite >>> costly. Maybe there is a better way to set these up... >>=20 >> Later you mentioned testing for coupling with egress rate. But you = didn't test coupling with classification! >>=20 >> I switched from simple.qos to simplest.qos, and that achieved the = lower latency on pppoe-wan. So I think your naive u32 filter setup = wasn't the real problem. >>=20 >> I did think ECN wouldn't be applied on eth1, and that would be the = cause of the latency. But disabling ECN didn't affect it. See files 3 = to 6: >>=20 >> = https://www.dropbox.com/sh/shwz0l7j4syp2ea/AAAxrhDkJ3TTy_Mq5KiFF3u2a?dl=3D= 0 >>=20 >> I also admit surprise at fq_codel working within 20%/10ms on eth1. I = thought it'd really hurt, by breaking the FQ part. Now I guess it = doesn't. I still wonder about ECN marking, though I didn't check my = endpoint is using ECN. >=20 > ECN should never increase latency, if it has any effect it should = improve latency because you slow down sending packets when some hop = along the path is overloaded rather than sending the packets anyway and = having them sit in a buffer for a while. This doesn't decrease actual = throughput either (although if you are doing a test that doesn't = actually wait for all the packets to arrive at the far end, it will look = like it decreases throughput) >=20 >>>> 3) SQM on pppoe-ge00 has a rough 20% higher egress rate than SQM on >>>> ge00 (with ingress more or less identical between the two). Also 2) >>>> and 3) do not seem to be coupled, artificially reducing the egress >>>> rate on pppoe-ge00 to yield the same egress rate as seen on ge00 >>>> does not reduce the LULI to the ge00 typical 10ms, but it stays at >>>> 20ms. >>>> For this I also have no good hypothesis, any ideas? >>> With classification fixed the difference in egress rate shrinks to >>> ~10% instead of 20, so this partly seems related to the >>> classification issue as well. >>=20 >> My tests look like simplest.qos gives a lower egress rate, but not as = low as eth1. (Like 20% vs 40%). So that's also similar. >>=20 >>>> So the current choice is either to accept a noticeable increase in >>>> LULI (but note some years ago even an average of 20ms most likely >>>> was rare in the real life) or a equally noticeable decrease in >>>> egress bandwidth=85 >>> 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 >> so maybe the question is actually classification v.s. not? >>=20 >> + IMO slow asymmetric links don't want to lose more upload bandwidth = than necessary. And I'm losing a *lot* in this test. >> + As you say, having only 20ms excess would still be a big = improvement. We could ignore the bait of 10ms right now. >>=20 >> vs >>=20 >> - lowest latency I've seen testing my link. almost suspicious. looks = close to 10ms average, when the dsl rate puts a lower bound of 7ms on = the average. >> - fq_codel honestly works miracles already. classification is the = knob people had to use previously, who had enough time to twiddle it. >=20 > That's what most people find when they try it. Classification doesn't = result in throughput vs latency tradeoffs as much as it gives absolute = priority to some types of traffic. But unless you are really up against = your bandwidth limit, this seldom matters in the real world. As long as = latency is kept low, everything works so you don't need to give VoIP = priority over other traffic or things like that. But note, not all traffic is equal ;) Take the example from the = mail Alan was quoting from, shaping on an ethernet interface that = handles pppoe traffic: the shaper sees all packets including the packets = PPP uses to establish and maintain the link, I would argue that these = actually need a guaranteed delivery as dropping them can take out the = pop link and hence the internet connection. I admit it is rare for home = users to actually encounter such drop-averse packets, but they at least = justify the use of classification/priorities. Whether VoIP makes the cut = really depends on its drop probability on each end link (I just want to = note that commercial VoIP system at least use precedence and EF markings = on their packets, so classification of these is a) easy and b) is = actually performed by many ISP=92s home router offerings for that ISP=92s = brand of VoIP) Best Regards Sebastian >=20 > David Lang