From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 1E0583BA8E for ; Tue, 28 Feb 2017 21:16:38 -0500 (EST) Received: by mail-lf0-x230.google.com with SMTP id y193so13290497lfd.3 for ; Tue, 28 Feb 2017 18:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vbbGER1b8Bf/w0/27yDhOiT/YZ6f7Vprx4aeW/a1QZI=; b=FC4JwNK5VIjy536G6cEu51ASFPEcMomX6m9DKfj2OSvvQ4rHxe74nIr3dvVvNZ21Ik llpmrkQjEjWaViHnfyxUq8DtXSAjwdX7va4zxQtY7ZgtMzGwi/QiPzpp4cOBcb6c1F6I yRBR794HLCTyfEwgdzaamZnF/OoVPpThtma32B2nFGbS1mRsu3grmAeyaUt2mcALQJsU ufj2LX/TGZ2B6MvdfB5EV0nF2ersNueOgIAjw7XnMwh0cFew59whRDoWcoXOVeqDTFYI A5DK0aA1PhHCRGa+K+WE9zNWZkwhrlbPFQKxK0lWHbHIOGz9tMCfBdRCLy9vapwVmXJS XijA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vbbGER1b8Bf/w0/27yDhOiT/YZ6f7Vprx4aeW/a1QZI=; b=Gf7cGdvK/qM/cSByKDqMTpJmt6zCUnaP7i4zymtYl83mxBmx9PmGjU5gFjzO87IZVW /UD4J0Ht9l3F6xc/OCMP1xpQ0MfpkivaAL+h1iLU/yBFhS/NsNTmDovy/IGgYgdoiREA Kh91uMFNoSMBJ9PPc4jtjm05kflR/kup6U87qqFGcMtfmWfbDuqjkENp5oXbDvdgamHz cnd8NC0tXGPL/RMu11JkPOohJ6Yk2CwHLyrbn12bUhkkY79SMpkY+0swtcb/J7yackHh JpZAB7XhF7IOn6J+hTx6jmuy2bgCokjwmeUkXCMgR4v2y1LMTx4oVpU+CV86Y2+JCRHw U/Sg== X-Gm-Message-State: AMke39kpL6ghJIGWkjYYYr+DfUIBADWsvpi0VQi5VUMVJ+5w3+SDtJ+8/58SkFB0NdON4AqjvSI4KwkrQTXjYw== X-Received: by 10.46.9.134 with SMTP id 128mr1815330ljj.133.1488334596901; Tue, 28 Feb 2017 18:16:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.198.7 with HTTP; Tue, 28 Feb 2017 18:16:36 -0800 (PST) In-Reply-To: <46520682-a67e-e77c-3ccb-4944cc3739ec@gmail.com> References: <75e10bac-f982-655f-0ef6-483a36797479@gmail.com> <6EA3F28B-2A50-4BDB-A0D4-B94207BFF1A4@gmail.com> <3c0c8aab-2a9a-82a4-0828-d58c604d35dc@gmail.com> <028AA856-B11E-4025-B1BD-84BAC6768508@gmx.de> <9353cc42-220b-af1b-3105-19be52ed0627@gmail.com> <3F9B4D98-ED26-4B56-812E-783CBBF64AAF@gmx.de> <46520682-a67e-e77c-3ccb-4944cc3739ec@gmail.com> From: Benjamin Cronce Date: Tue, 28 Feb 2017 20:16:36 -0600 Message-ID: To: Andy Furniss Cc: Sebastian Moeller , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a114b162cf492300549a1e689 Subject: Re: [Cake] 5ms target hurting tcp throughput tweakable? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 02:16:38 -0000 --001a114b162cf492300549a1e689 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2017 at 1:26 PM, Andy Furniss wrote: > Sebastian Moeller wrote: > >> Hi Andy, >> >> >> On Feb 27, 2017, at 19:02, Andy Furniss >>> wrote: >>> >>> Sebastian Moeller wrote: >>> >>>> Looking at tc-adv, I would recommend to use =E2=80=9Crtt 50=E2=80=9D (= maybe it is >>>> =E2=80=9Crtt 50ms=E2=80=9D) which allows to directly explicitly reques= t a new >>>> =E2=80=9Cinterval=E2=80=9D (which IIRC is corresponding to the time yo= u allow for >>>> the TCP control loop to react to cake=E2=80=99s ecn-marking/dropping) >>>> =E2=80=9Ctarget=E2=80=99 will be calculated as 5% of the explicit inte= rval, in >>>> accordance with the rationale in the codel RFC. >>>> >>> >>> 50 is certainly better than 10, but still seems to hurt single a >>> bit even on a close server. >>> >> >> Oopps, what I meant to convey is that there is the numeric option >> =E2=80=9Crtt NNN=E2=80=9D that allows to select the exact RTT/interval y= ou believe >> to be valid. I picked 50 just because I wanted to give a concrete >> example, not because I believe 50 to be correct for your >> experiments... >> > > Ahh, OK. > > >> >>> On more distant servers maybe even more - I am getting results >>> that are too variable to tell properly at the current time (of >>> day). >>> >>> http://www.thinkbroadband.com/speedtest/results.html?id=3D1488 >>> 216166262542155 >>> >>> >>> >>> >>> Almost OK, but with 100ms this test usually shows x1 and x6 the same. > >> >>> http://www.thinkbroadband.com/speedtest/results.html?id=3D1488 >>> 218291872647755 >>> >> >> >>> >>> Interesting. My mental image is that interval defines the time you >> give both involved TCPs to get their act together before escalating >> cake=E2=80=99s/codel=E2=80=99s signaling. The theory as far as I underst= and it says >> that the RTT is the lower bound for the time required, so I am not >> totally amazed that relaxing that interval a bit increases bandwidth >> utilisation at a vert moderate latency cost (if any). The art is to >> figure out how to pick the interval (and I believe the codel paper >> showed, that at least for codel the exact number is not so important >> but the ballpark/ order of magnitude should match). >> > > Seems to be a repeatable result. > > >> >>> Of course as we all know ingress shaping is a different beast >>> anyway and would deserve its own thread. >>> >> >> The cool thing is that ingress shaping with all its >> =E2=80=9Capproximateness=E2=80=9D (is that a word) works as well as it d= oes ;) >> > > Yea, though I am always interested in any ingress specific tweaks. > > On my current line I have a 67 meg sync and the ISP buffer seems to > spike to max 80ms then settle to 40 =3D luxury compared to when I used to > have a 288/576 kbit sync adsl line with a 600ms remote buffer. Ingress > shaping on that was a bit more "interesting", especially as I targeted > latency for gaming. Back then I used to use connbytes and a short head > dropping sfq (needed hack) to get tcp out of (no so) slow start quickly. > > Even on this line I can measure regular (without qos) tcp blips of 70ms > when someone is watching an HD vid on youtube. Streaming is misleading > description for this test at least, blipping would be better :-) > I have not sampled YouTube data in a while, but the last time I looked it had packet-pacing issues. With TCP going from idle to full, several times a second. Not only do you get the issue that TCP will front-load the entire TCP window all at once, but if the data being transfers fits within the TCP window, it never learns to back down. If you have a 30ms ping to YouTube, at 67Mb/s, your window is about 2mbits, which is about 256KiB, which is about the same size as the request sizes to "stream", last I knew. Netflix is working on packet pacing for FreeBSD. After bufferbloat, it's the next big issue. > > Sacrificing 6 meg does make it better (bit variable 20 - 40ms), but the > blips still show. The challenge of keeping the remote buffer empty ish > without sacrificing too much speed is an interesting one. > > Until recently I didn't need to care as my ISP did QOS with AFAIK > Ellacoyas. Unfortunately they had a big change in their network and for > reasons unknown it all went pear shaped so they have turned it off. > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --001a114b162cf492300549a1e689 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 27, 2017 at 1:26 PM, Andy Furniss <adf.lists@gmail.com> wrote:
Seb= astian Moeller wrote:
Hi Andy,


On Feb 27, 2017, at 19:02, Andy Furniss <adf.lists@gmail.com>
wrote:

Sebastian Moeller wrote:
Looking at tc-adv, I would recommend to use =E2=80=9Crtt 50=E2=80=9D (maybe= it is
=E2=80=9Crtt 50ms=E2=80=9D) which allows to directly explicitly request a n= ew
=E2=80=9Cinterval=E2=80=9D (which IIRC is corresponding to the time you all= ow for
the TCP control loop to react to cake=E2=80=99s ecn-marking/dropping)
=E2=80=9Ctarget=E2=80=99 will be calculated as 5% of the explicit interval,= in
accordance with the rationale in the codel RFC.

50 is certainly better than 10, but still seems to hurt single a
bit even on a close server.

Oopps, what I meant to convey is that there is the numeric option
=E2=80=9Crtt NNN=E2=80=9D that allows to select the exact RTT/interval you = believe
to be valid. I picked 50 just because I wanted to give a concrete
example, not because I believe 50 to be correct for your
experiments...

Ahh, OK.



On more distant servers maybe even more - I am getting results
that are too variable to tell properly at the current time (of
day).

http://www.thinkbroadba= nd.com/speedtest/results.html?id=3D1488216166262542155




Almost OK, but with 100ms this test usually shows x1 and x6 the same.

http://www.thinkbroadba= nd.com/speedtest/results.html?id=3D1488218291872647755



Interesting. My mental image is that interval defines the time you
give both involved TCPs to get their act together before escalating
cake=E2=80=99s/codel=E2=80=99s signaling. The theory as far as I understand= it says
that the RTT is the lower bound for the time required, so I am not
totally amazed that relaxing that interval a bit increases bandwidth
utilisation at a vert moderate latency cost (if any). The art is to
figure out how to pick the interval (and I believe the codel paper
showed, that at least for codel the exact number is not so important
but the ballpark/ order of magnitude should match).

 Seems to be a repeatable result.



Of course as we all know ingress shaping is a different beast
anyway and would deserve its own thread.

The cool thing is that ingress shaping with all its
=E2=80=9Capproximateness=E2=80=9D (is that a word) works as well as it does= ;)

 Yea, though I am always interested in any ingress specific tweaks.

On my current line I have a 67 meg sync and the ISP buffer seems to
spike to max 80ms then settle to 40 =3D luxury compared to when I used to have a 288/576 kbit sync adsl line with a 600ms remote buffer. Ingress
shaping on that was a bit more "interesting", especially as I tar= geted
latency for gaming. Back then I used to use connbytes and a short head
dropping sfq (needed hack) to get tcp out of (no so) slow start quickly.
Even on this line I can measure regular (without qos) tcp blips of 70ms
when someone is watching an HD vid on youtube. Streaming is misleading
description for this test at least, blipping would be better :-)

I have not sampled YouTube data in a while, but t= he last time I looked it had packet-pacing issues. With TCP going from idle= to full, several times a second. Not only do you get the issue that TCP wi= ll front-load the entire TCP window all at once, but if the data being tran= sfers fits within the TCP window, it never learns to back down. If you have= a 30ms ping to YouTube, at 67Mb/s, your window is about 2mbits, which is a= bout 256KiB, which is about the same size as the request sizes to "str= eam", last I knew.

Netflix is working on pack= et pacing for FreeBSD. After bufferbloat, it's the next big issue.
=C2=A0

Sacrificing 6 meg does make it better (bit variable 20 - 40ms), but the
blips still show. The challenge of keeping the remote buffer empty ish
without sacrificing too much speed is an interesting one.

Until recently I didn't need to care as my ISP did QOS with AFAIK
Ellacoyas. Unfortunately they had a big change in their network and for
reasons unknown it all went pear shaped so they have turned it off.

_______________________________________________
Cake mailing list
Cake@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

--001a114b162cf492300549a1e689--