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 B1E4F21F3B3 for ; Fri, 24 Apr 2015 06:32:23 -0700 (PDT) Received: by igblo3 with SMTP id lo3so14524495igb.1 for ; Fri, 24 Apr 2015 06:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=5xtPx3wRoKNahsyInr8dQH6BRkWBThzVSc9knQfAt4c=; b=qfTAshS1S9RYJBjHAaBSt0rUXnsemqmqvNZ7CcS+bfAY449p46wnwnbleeTXaVDvaU yXazV9SZcu7gZnFfaU8GJD9tSVcAQ/QBuDtPTgGQSS1I+kmDrEbNaeAED/beVgwGWCnf hdcOfGLGPKg9+hfI2cWqZ8CZRfP534l5yZtqZ9PnBOG7774W9ScPH391toI/8v37CWb6 9LePof9/7GuNklGcLwh3BqbN7CPHnY6ho1OdpNyzRNXP6kYmw8KxK7Y9hU44XHkGch01 lUj38ehQsLZGkD1/qlI+JTSrWiopGc92eymp4Cb55rjmZxXTF9HoI12l9c0IzWZRQFHE Utag== MIME-Version: 1.0 X-Received: by 10.42.129.73 with SMTP id p9mr9589085ics.48.1429882342553; Fri, 24 Apr 2015 06:32:22 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Fri, 24 Apr 2015 06:32:22 -0700 (PDT) In-Reply-To: <87sibp526w.fsf@toke.dk> References: <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <20150422040453.GB36239@sesse.net> <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> <1429710657.18561.68.camel@edumazet-glaptop2.roam.corp.google.com> <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@email.android.com> <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> <5537CDB7.60301@orange.com> <1429722979.18561.112.camel@edumazet-glaptop2.roam.corp.google.com> <5537DA20.1090008@orange.com> <5537DE4D.8090100@orange.com> <1429771718.22254.32.camel@edumazet-glaptop2.roam.corp.google.com> <6C0D04CF-53AA-4D18-A4E4-B746AF6487C7@gmx.de> <87wq123p5r.fsf@toke.dk> <2288B614-B415-4017-A842-76E8F5DFDE4C@gmx.de> <87sibp526w.fsf@toke.dk> Date: Fri, 24 Apr 2015 23:32:22 +1000 X-Google-Sender-Auth: ddHnQZeLhbEUsL1U9wlrxsZs-YI Message-ID: From: jb To: bloat Content-Type: multipart/alternative; boundary=20cf301af6d9193fb90514786d17 Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 13:33:14 -0000 --20cf301af6d9193fb90514786d17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Don't you want to accuse the size of the buffer, rather than the latency? For example, say someone has some hardware and their line is fairly slow. it might be RED on the graph because the buffer is quite big relative to th= e bandwidth delay product of the line. A test is telling them they have bloated buffers. Then they upgrade their product speed to a much faster product, and suddenl= y that buffer is fairly small, the incremental latency is low, and no longer shows RED on a test. What changed? the hardware didn't change. Just the speed changed. So the test is saying that for your particular speed, the buffers are too big. But for a higher speed, they may be quite ok. If you add 100ms to a 1gigabit product the buffer has to be what, ~10mb? but adding 100ms to my feeble line is quite easy, the billion router can have a buffer of just 100kb and it is too high. But that same billion in front of a gigabit modem is only going to add at most 1ms to latency and nobody would complain. Ok I think I talked myself around in a complete circle: a buffer is only bad IF it increases latency under load. Not because of its size. It might explain why these fiber connection tests don't show much latency change, because their buffers are really inconsequential at those higher speeds? On Fri, Apr 24, 2015 at 7:02 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Sebastian Moeller writes: > > > Oh, I can get behind that easily, I just thought basing the > > limits on externally relevant total latency thresholds would directly > > tell the user which applications might run well on his link. Sure this > > means that people on a satellite link most likely will miss out the > > acceptable voip threshold by their base-latency alone, but guess what > > telephony via satellite leaves something to be desired. That said if > > the alternative is no telephony I would take 1 second one-way delay > > any day ;). > > Well I agree that this is relevant information in relation to the total > link latency. But keeping the issues separate has value, I think, > because you can potentially fix your bufferbloat, but increasing the > speed of light to get better base latency on your satellite link is > probably out of scope for now (or at least for a couple of hundred more > years: http://theinfosphere.org/Speed_of_light). > > > What I liked about fixed thresholds is that the test would give > > a good indication what kind of uses are going to work well on the link > > under load, given that during load both base and induced latency come > > into play. I agree that 300ms as first threshold is rather unambiguous > > though (and I am certain that remote X11 will require a massively > > lower RTT unless one likes to think of remote desktop as an oil tanker > > simulator ;) ) > > Oh, I'm all for fixed thresholds! As I said, the goal should be (close > to) zero added latency... > > > Okay so this would turn into: > > > > base latency to base latency + 30 ms: green > > base latency + 31 ms to base latency + 100 ms: yellow > > base latency + 101 ms to base latency + 200 ms: orange? > > base latency + 201 ms to base latency + 500 ms: red > > base latency + 501 ms to base latency + 1000 ms: fire > > base latency + 1001 ms to infinity: > fire & brimstone > > > > correct? > > Yup, something like that :) > > -Toke > --20cf301af6d9193fb90514786d17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Don't you want to accuse the size of the buffer, rathe= r than the latency?

For example, say someone has some ha= rdware and their line is fairly slow.
it might be RED on the grap= h because the buffer is quite big relative to the
bandwidth delay= product of the line. A test is telling them they have
bloated bu= ffers.

Then they upgrade their product speed to a = much faster product, and suddenly
that buffer is fairly small, th= e incremental latency is low, and no longer shows
RED on a test.<= /div>

What changed? the hardware didn't change. Just= the speed changed. So the
test is saying that for your particula= r speed, the buffers are too big. But for a
higher speed, they ma= y be quite ok.

If you add 100ms to a 1gigabit prod= uct the buffer has to be what, ~10mb?
but adding 100ms to my feeb= le line is quite easy, the billion router can have=C2=A0
a buffer= of just 100kb and it is too high. But that same billion in front of a
gigabit modem is only going to add at most 1ms to latency and nobody<= /div>
would complain.

Ok I think I talked myse= lf around in a complete circle: a buffer is only bad IF
it increa= ses latency under load. Not because of its size. It might explain why
=
these fiber connection tests don't show much latency change, becau= se=C2=A0
their buffers are really inconsequential at those higher= speeds?


On Fri, Apr 24, 2015 at 7:02 PM, Toke H=C3=B8iland-J=C3= =B8rgensen <toke@toke.dk> wrote:
Sebastian Moeller <moeller0@gmx.de> writes:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Oh, I can get behind that easily, I just tho= ught basing the
> limits on externally relevant total latency thresholds would directly<= br> > tell the user which applications might run well on his link. Sure this=
> means that people on a satellite link most likely will miss out the > acceptable voip threshold by their base-latency alone, but guess what<= br> > telephony via satellite leaves something to be desired. That said if > the alternative is no telephony I would take 1 second one-way delay > any day ;).

Well I agree that this is relevant information in relation to the to= tal
link latency. But keeping the issues separate has value, I think,
because you can potentially fix your bufferbloat, but increasing the
speed of light to get better base latency on your satellite link is
probably out of scope for now (or at least for a couple of hundred more
years: http://theinfosphere.org/Speed_of_light).

>=C2=A0 =C2=A0 =C2=A0 =C2=A0What I liked about fixed thresholds is that = the test would give
> a good indication what kind of uses are going to work well on the link=
> under load, given that during load both base and induced latency come<= br> > into play. I agree that 300ms as first threshold is rather unambiguous=
> though (and I am certain that remote X11 will require a massively
> lower RTT unless one likes to think of remote desktop as an oil tanker=
> simulator ;) )

Oh, I'm all for fixed thresholds! As I said, the goal should be = (close
to) zero added latency...

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Okay so this would turn into:
>
> base latency to base latency + 30 ms:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0green
> base latency + 31 ms to base latency + 100 ms:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yellow
> base latency + 101 ms to base latency + 200 ms:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0orange?
> base latency + 201 ms to base latency + 500 ms:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0red
> base latency + 501 ms to base latency + 1000 ms:=C2=A0 =C2=A0 =C2=A0 f= ire
> base latency + 1001 ms to infinity:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0fire & brimstone
>
> correct?

Yup, something like that :)

-Toke

--20cf301af6d9193fb90514786d17--