From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BA8CC21F2F2 for ; Wed, 18 Mar 2015 20:11:33 -0700 (PDT) Received: by oier21 with SMTP id r21so54814867oie.1 for ; Wed, 18 Mar 2015 20:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lFvVo24kH+kGRRCKevgbgKZnh2gOh77UEijznhIgP7s=; b=dGPNOv0nysHDqW+PwIg5eb1F7Km/zFu4ffloiNc/4xCELB+Kg9jnVahv1q4/0LtMCO eSEJ6CTlHFKLp+2Pwnfd+X8wibjeHVF9HsW1iEewyxphDtlzAW+cxHiV08B7348yUGfc 5ayxXMhSkKXU5nQvoZuM7ZRj2kr/x/PLhhWLuc9bxwq7C4fd95VV3JwhRJsY8nYFLGW6 Ux/gKxq2yBh0zHB9CCzC3mCcYCsjnMyvJYpuduAw9gS0M6+9B148FgH5NMvX35i2T+F3 9762ey4PhChgPQ6CwbPf/6cE+O0SUfcQiUVQHOiFhb22LzGh02KfrUPbTFTbThixDSaf 8sVQ== MIME-Version: 1.0 X-Received: by 10.202.62.70 with SMTP id l67mr56992983oia.59.1426734692093; Wed, 18 Mar 2015 20:11:32 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Wed, 18 Mar 2015 20:11:32 -0700 (PDT) In-Reply-To: References: <1895D16A-1B0F-48C7-B4B5-6FC84CA92F43@gmx.de> <5509F8B1.6090608@gmail.com> Date: Wed, 18 Mar 2015 20:11:32 -0700 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 03:12:01 -0000 On Wed, Mar 18, 2015 at 7:43 PM, David Lang wrote: > On Wed, 18 Mar 2015, Alan Jenkins wrote: > >>> 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=E2=80=99s if both ingress and egress classification are acti= ve 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... >> >> >> Later you mentioned testing for coupling with egress rate. But you didn= 't >> test coupling with classification! >> >> 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. >> >> 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: >> >> https://www.dropbox.com/sh/shwz0l7j4syp2ea/AAAxrhDkJ3TTy_Mq5KiFF3u2a?dl= =3D0 >> >> 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 u= sing >> ECN. > > > 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 pat= h > 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 throughp= ut) ECN does, provably, increase latency (and loss) for other non-ecn marked fl= ows. Not by a lot, but it does. In the case of a malignantly mis-marked flow, the present codel aqm algorithm does pretty bad things to itself and to other non-ecn marked packets. (have fixes for codel, but fq_codel doesn't have this problem, pie somewhat has it) >>>> >>>> 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. One of the things we really have to get around to doing is more high rate testing, and actually measuring how much latency the tcp flows are experiencing. >> >> My tests look like simplest.qos gives a lower egress rate, but not as lo= w >> as eth1. (Like 20% vs 40%). So that's also similar. >> >>>> 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=E2=80=A6 >>> >>> >>> I guess it is back to the drawing board to figure out how to speed up >>> the classification=E2=80=A6 and then revisit the PPPoE question again= =E2=80=A6 >> >> >> so maybe the question is actually classification v.s. not? >> >> + IMO slow asymmetric links don't want to lose more upload bandwidth tha= n >> 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. >> >> vs >> >> - lowest latency I've seen testing my link. almost suspicious. looks clo= se >> to 10ms average, when the dsl rate puts a lower bound of 7ms on the aver= age. >> - fq_codel honestly works miracles already. classification is the knob >> people had to use previously, who had enough time to twiddle it. > > > That's what most people find when they try it. Classification doesn't res= ult > 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 bandwidt= h > 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. +10. > > David Lang > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb