From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 6631C21F5A6 for ; Sat, 24 Oct 2015 10:30:53 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so51913823igb.0 for ; Sat, 24 Oct 2015 10:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=cBOeWRBGqXNR0ZZxabWA/O+KoHPb6ySRge9TY6DT4aY=; b=srWHsLapidere4HJijaaPaHwDf+GHqJSXil0wuqJlHdWakVIe/pX5QZMfu5PINm145 f4R6pvoOxAEuu78kMBELX5SlnKDYC7puGsnkPg7QOuKS6BhgZdrSpobR5I9/obxZEQ9r 0rN8FMf/nw+ZgDC3j82b+5orYfGN6xYbdzlCf+COuQzfbiZM66GhZ6UlVzDemdSEnUCT VDq5eS93rN0lltyXYui4nJUZdLDG93bZM2JtsQMGOgRcMKXgc48qeaMUEAIITTPIVEhD hIOD7gNTwVba+s/u53a1zmRPSTSbw5ly/jC7haeaacT5oOwhGiNJ/f4e1vpjdN606npg P5cg== X-Received: by 10.50.82.5 with SMTP id e5mr9879111igy.30.1445707853077; Sat, 24 Oct 2015 10:30:53 -0700 (PDT) MIME-Version: 1.0 References: <562A5BE5.6010101@gmail.com> <12883.1445625688@sandelman.ca> <562A9611.4050403@gmail.com> <931be41d-68b7-4fea-9d4e-14bf1636e9bc@reed.com> <2DE7C829-5C11-4B9A-B8FD-10029918A7FA@gmx.de> In-Reply-To: <2DE7C829-5C11-4B9A-B8FD-10029918A7FA@gmx.de> From: Aaron Wood Date: Sat, 24 Oct 2015 17:30:43 +0000 Message-ID: To: Sebastian Moeller , "David P. Reed" Content-Type: multipart/alternative; boundary=047d7bd911a80825d70522dd17aa Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Problems testing sqm 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: Sat, 24 Oct 2015 17:31:16 -0000 --047d7bd911a80825d70522dd17aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've done the same setup in the past with my 3800, and htb limits just fine to 10Mbps even when used with gigabit lab links. So I think that, for whatever reason, htb just isn't functioning. Dumping the qdiscs setup and stats using tc should make it clearer as to what the state of things actually is. -Aaron On Sat, Oct 24, 2015 at 10:25 Sebastian Moeller wrote: > Hi David, > > > On Oct 24, 2015, at 18:34 , David P. Reed wrote: > > > Not trying to haggle. > > Sorry, I was a bit to grumpy for unrelated reasons. > > > Just pointing out that this test configuration has a very short RTT. > maybe too short for our SQM to adjust to. > > That could be, but I believe people have tested fq_codel and sqm > with similar setups and generally got dozens of milliseconds induced dela= y, > not multiple seconds. So sure sqm might not for the best thing but it > should deliver a reasonable compromise. Now, I believe Toke has a test be= d > where he can vary the transmission delay so he might know already whether > sqm has issues with 1GE lans. > > Best Regards > Sebastian > > > > > On Oct 24, 2015, Sebastian Moeller wrote: > > Hi David, > > > > On Oct 24, 2015, at 00:53 , David P. Reed wrote: > > > > In particular, the DUT should probably have no more than 2 packets of > outbound queueing given the very small RTT. 2xRTT is the most buffering y= ou > want in the loop. > > > > Let=E2=80=99s not haggle about the precise amount of queueing we deem > acceptable, as long as we all agree that >=3D 2 seconds is simply not > acceptable ;) (the default sqm will approximately limit the latency under > load increase (LULI) to roughly twice the target or typically 10 ms; note > that this LULI only applies to unrelated flows). The exact number of queu= ed > packets seems to correlate with the beefiness of the DUT, the beefier the > fewer packets should work, wimpier devices might need to batch some > processing up, resulting in higher LULI=E2=80=A6 > > > > Best Regards > > Sebastian > > > > > > On Oct 23, 2015, Richard Smith wrote: > > On 10/23/2015 02:41 PM, Michael Richardson wrote: > > Richard Smith wrote: > > My test setup: > > > > Laptop<--1000BaseT-->DUT<--1000baseT-->Server > > > > So, given that the DUT is the only real constraint in the network, what > > do you expect to see from this setup? > > > > Given that the probably DUT can't forward at Gb/s, and it certainly can= 't > > shape anything, it's gonna drop packets, and it's probably gonna drop > them in > > Rx, having overrun the Rx-queue (so tail-drop). If there is too much ra= m > > (bufferbloated), then you'll see different results... > > > > Setting ingress/egress to 10Mbit/s I expected to see the speed > > measurements bounce around those limits with the ping times staying in > > the low double digits of ms. What I saw however, was the data rates > > going well past 10Mbit limit and pings up to 2000 ms. > > > > This is what I've seen in prior rrul testing using a the 50/10 cable > > link at our office and my 25(ish)/6 link at my apartment and a well > > connected server on the net. That however was using QoS and not SQM. > > > > Its that a reasonable expectation? > > > > -- Sent with K-@ Mail - the evolution of emailing. > > > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > > > -- Sent with K-@ Mail - the evolution of emailing. > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --047d7bd911a80825d70522dd17aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've done the same setup in the past with my 3800, and htb limits just = fine to 10Mbps even when used with gigabit lab links.

So I think tha= t, for whatever reason, htb just isn't functioning.

Dumping the = qdiscs setup and stats using tc should make it clearer as to what the state= of things actually is.

-Aaron
On Sat, Oct 24, 2015 at 10:25 Sebastian Moeller <moeller0@gmx.de> wrote:
Hi David,


On Oct 24, 2015, at 18:34 , David P. Reed <dpreed@reed.com> wrote:

> Not trying to haggle.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sorry, I was a bit to grumpy for unrelated reas= ons.

> Just pointing out that this test configuration has a very short RTT. m= aybe too short for our SQM to adjust to.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 That could be, but I believe people have tested= fq_codel and sqm with similar setups and generally got dozens of milliseco= nds induced delay, not multiple seconds. So sure sqm might not for the best= thing but it should deliver a reasonable compromise. Now, I believe Toke h= as a test bed where he can vary the transmission delay so he might know alr= eady whether sqm has issues with 1GE lans.

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian

>
> On Oct 24, 2015, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi David,
>
> On Oct 24, 2015, at 00:53 , David P. Reed <dpreed@reed.com> wrote:
>
> In particular, the DUT should probably have no more than 2 packets of = outbound queueing given the very small RTT. 2xRTT is the most buffering you= want in the loop.
>
> Let=E2=80=99s not haggle about the precise amount of queueing we deem = acceptable, as long as we all agree that >=3D 2 seconds is simply not ac= ceptable ;) (the default sqm will approximately limit the latency under loa= d increase (LULI) to roughly twice the target or typically 10 ms; note that= this LULI only applies to unrelated flows). The exact number of queued pac= kets seems to correlate with the beefiness of the DUT, the beefier the fewe= r packets should work, wimpier devices might need to batch some processing = up, resulting in higher LULI=E2=80=A6
>
> Best Regards
> Sebastian
>
>
> On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
> On 10/23/2015 02:41 PM, Michael Richardson wrote:
> Richard Smith <smithbone@gmail.com> wrote:
> My test setup:
>
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>
> So, given that the DUT is the only real constraint in the network, wha= t
> do you expect to see from this setup?
>
> Given that the probably DUT can't forward at Gb/s, and it certainl= y can't
> shape anything, it's gonna drop packets, and it's probably gon= na drop them in
> Rx, having overrun the Rx-queue (so tail-drop). If there is too much r= am
> (bufferbloated), then you'll see different results...
>
> Setting ingress/egress to 10Mbit/s I expected to see the speed
> measurements bounce around those limits with the ping times staying in=
> the low double digits of ms. What I saw however, was the data rates > going well past 10Mbit limit and pings up to 2000 ms.
>
> This is what I've seen in prior rrul testing using a the 50/10 cab= le
> link at our office and my 25(ish)/6 link at my apartment and a well > connected server on the net. That however was using QoS and not SQM. >
> Its that a reasonable expectation?
>
> -- Sent with K-@ Mail - the evolution of emailing.
>
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ce= rowrt-devel
>
>
> -- Sent with K-@ Mail - the evolution of emailing.

_______________________________________________
Cerowrt-devel mailing list
Ce= rowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-d= evel
--047d7bd911a80825d70522dd17aa--