From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (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 B58FE21F1E7 for ; Tue, 7 Apr 2015 10:16:52 -0700 (PDT) Received: by wgsk9 with SMTP id k9so40587858wgs.3 for ; Tue, 07 Apr 2015 10:16:50 -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 :content-type; bh=7Ss2rZjjmVt/SDAQKVlfyXG5GLJJzgUcZbCNplYcEC0=; b=F2zXJfPixF/Lp0wqLpNbJSmIlY8TLKJlUAgZ1LFR9t2y/AA4uP/rtBX1OF7XsVUHtN PcJ5SXrpdTtgDFsggqB0QANaFSgUdnG6Wl6kyv7hbW77TsrRakb0L+auXT4z8KPwVbjT 9wnQx5R6BwkQfPK/+6lp9V4mqT4GZXeVAM/BPtODHXLhIUjrzVLgVq9BlAut61LjCMgg iFm7cuvn1EWRD/rZyiXoXhLy3xuKnouxH7CNRmwOM/eIWWuSv0LHP9wMjEFtEk/aJDx0 fvuf4+WdeQRvEvcNA6TqxlBT7Mvuc1iFSP1tZMXpMH6oyFcU9Esw9a3wJNE2QOb7MTsI qdmw== MIME-Version: 1.0 X-Received: by 10.181.13.146 with SMTP id ey18mr6365969wid.21.1428427009999; Tue, 07 Apr 2015 10:16:49 -0700 (PDT) Received: by 10.28.180.87 with HTTP; Tue, 7 Apr 2015 10:16:49 -0700 (PDT) In-Reply-To: References: <20150316203532.05BD21E2@taggart.lackof.org> <15A0911A-E3B7-440A-A26B-C5E1489EA98B@viagenie.ca> <1426773234.362612992@apps.rackspace.com> <1426796961.194223197@apps.rackspace.com> <5FD20B4A-A7E8-48C0-89F9-E2EB86DED8A6@gmail.com> <755FC1BE-141C-42FD-B3E3-564488982665@gmail.com> <95B0F8DA-7650-4064-BEE6-F0CDF936D33A@gmail.com> <20150331180735.0abd31fc@redhat.com> Date: Tue, 7 Apr 2015 19:16:49 +0200 Message-ID: From: Pedro Tumusok To: bloat Content-Type: multipart/alternative; boundary=f46d043c81fa84e7cf0513259402 Subject: [Bloat] Fwd: Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?) 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: Tue, 07 Apr 2015 17:17:21 -0000 --f46d043c81fa84e7cf0513259402 Content-Type: text/plain; charset=UTF-8 I managed to remove a "t" on the end there.... Pedro ---------- Forwarded message ---------- From: Pedro Tumusok Date: Tue, Apr 7, 2015 at 7:15 PM Subject: Re: [Bloat] Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?) To: jb Cc: bloat On Sat, Apr 4, 2015 at 2:03 PM, jb wrote: > Hi, > Thanks for the indirect invitation to the list I'm looking forward to > following it and learning stuff. > > If I had one question now, it would be this. Should I put effort into > measuring ongoing RTT during the "full" download and upload phases, or > should I put effort into running packet captures at some of the test > locations, storing them, and processing them later, with the idea that this > will reveal in conjunction with speed test result files, actual TCP RTT > times during times when a residential connection is full. Even packet > capturing at one location would capture a lot of individuals because of the > many to one setup of the server-client. > >From earlier discussions on here, I think the RTT during "full" download and upload phases. is what most people on here want to see. Since it will tell us how any latency sensitive service will be affected by the buffers in the equipment when the connection is under heavy load. In tune with your "We are not interested in making your ISP look good", on here we are interested in making your device vendor look "bad". So that they actually can fix this, because its about them fixing their hardware, the solutions are there, they just need to do it. Having full captures is icing on the cake, but to just show the induced delay by the equipment is 90% of the way. But as all projects, the last 10% is the toughest part. Personally I think that if your speed test shows people the "true" experience, ie bad, they can expect from their setup, it will be immensely valuable for you and the bufferbloat project. And of course you will be copied on it, as before, by other speed test sites/tools. Bad analogies wise, having the best speed is like inserting a Porsche high performance car engine into a VW Beetle. You have the potential for going very fast, but it will be a very scary and uncomfortable ride, especially if you compare it to using that engine in a "real" Porsche. > Anything that is produced from this project might have to be crunched by > an interested person other than me, because of the number of different > devices and browsers and undocumented limits I've still got my hands full > making sure the maximum number of people get a "competitive" speed reading. > Making sure the majority drive their connection to capacity is probably a > necessary condition for accurate conclusions on anything else anyway. > > I assume that a lot of the people on here can use it for their daily work and I think there are some academics/scientists on here, that would love to have a copy of the date for research. Pedro > On Thu, Apr 2, 2015 at 4:21 AM, Pedro Tumusok > wrote: > >> Justin, >> >> If you got any questions, don't feel shy :) >> If there is any testing I can help with etc, let me know. >> >> Pedro >> >> On Tue, Mar 31, 2015 at 7:07 AM, Jesper Dangaard Brouer < >> jbrouer@redhat.com> wrote: >> >>> >>> On Mon, 30 Mar 2015 18:05:19 +0200 Pedro Tumusok < >>> pedro.tumusok@gmail.com> wrote: >>> >>> [...] >>> > That is feature creep, we originally discussed having continuous ping >>> > measurement under load. >>> > New ideas not so welcome ;) >>> >>> I agree, we just want Justin (http://www.dslreports.com/speedtest) to >>> also measure and report on ping/latency under load. >>> >>> After we have this basic step, we can refine it further, e.g. with >>> Jonathan HZ measurement. >>> >>> -- >>> Best regards, >>> Jesper Dangaard Brouer >>> MSc.CS, Sr. Network Kernel Developer at Red Hat >>> Author of http://www.iptv-analyzer.org >>> LinkedIn: http://www.linkedin.com/in/brouer >>> >> >> >> >> -- >> Best regards / Mvh >> Jan Pedro Tumusok >> >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> >> > -- Best regards / Mvh Jan Pedro Tumusok -- Best regards / Mvh Jan Pedro Tumusok --f46d043c81fa84e7cf0513259402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I managed to remove a "t" on the end there....= =C2=A0

Pedro
---------- Fo= rwarded message ----------
From: Pedro Tum= usok <p= edro.tumusok@gmail.com>
Date: Tue, Apr 7, 2015 at 7:15 PM<= br>Subject: Re: [Bloat] Latency Measurements in Speed Test suites (was: DOC= SIS 3+ recommendation?)
To: jb <justinbeech@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.ne>


On Sat, Apr 4, 2015 at 2:03 PM, jb <justinbeech@gmail.com>= ; wrote:
Hi,
= Thanks for the indirect invitation to the list I'm looking forward to f= ollowing it and learning stuff.

If I had one q= uestion now, it would be this. Should I put effort into measuring ongoing R= TT during the "full" download and upload phases, or should I put = effort into running packet captures at some of the test locations, storing = them, and processing them later, with the idea that this will reveal in con= junction with speed test result files, actual TCP RTT times during times wh= en a residential connection is full. Even packet capturing at one location = would capture a lot of individuals because of the many to one setup of the = server-client.

From earl= ier discussions on here, I think the RTT during "full" download a= nd upload phases. is what most people on here want to see. Since it will te= ll us how any latency sensitive service will be affected by the buffers in = the equipment when the connection is under heavy load. In tune with your &q= uot;We are not interested in making your ISP look good", on here we ar= e interested in making your device vendor look "bad". So that the= y actually can fix this, because its about them fixing their hardware, the = solutions are there, they just need to do it.
Having full capture= s is icing on the cake, but to just show the induced delay by the equipment= is 90% of the way. But as all projects, the last 10% is the toughest part.=

Personally I think that if your speed test shows = people the "true" experience, ie bad, they can expect from their = setup, it will be immensely valuable for you and the bufferbloat project. A= nd of course you will be copied on it, as before, by other speed test sites= /tools.

Bad analogies wise, having the best speed = is like inserting a Porsche high performance car engine into a VW Beetle. Y= ou have the potential for going very fast, but it will be a very scary and = uncomfortable ride, especially if you compare it to using that engine in a = "real" Porsche.


=C2=A0


Anything that is produced from this project mi= ght have to be crunched by an interested person other than me, because of t= he number of different devices and browsers and undocumented limits I'v= e still got my hands full making sure the maximum number of people get a &q= uot;competitive" speed reading. Making sure the majority drive their c= onnection to capacity is probably a necessary condition for accurate conclu= sions on anything else anyway.

=
I assume that a lot of the people on here can use it = for their daily work and I think there are some academics/scientists on her= e, that would love to have a copy of the date for research.
=C2=A0
Pedro


On T= hu, Apr 2, 2015 at 4:21 AM, Pedro Tumusok <pedro.tumusok@gmail.com> wrote:
Justin,

If you got any questions, don= 't feel shy :)=C2=A0
If there is any testing I can help w= ith etc, let me know.

Pedro

On Tue, Mar 31, 2015 at 7:0= 7 AM, Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:

On Mon, 30 Mar 2015 18:05:19 +0200 Pedro Tumusok <pedro.tumusok@gmail.com> wrot= e:

[...]
> That is feature creep, we originally discussed having continuous= ping
> measurement under load.
> New ideas not so welcome ;)

I agree, we just want Justin (http://www.dslreports.com/speedtest) to
also measure and report on ping/latency under load.

After we have this basic step, we can refine it further, e.g. with
Jonathan HZ measurement.

--
Best regards,
=C2=A0 Jesper Dangaard Brouer
=C2=A0 MSc.CS, Sr. Network Kernel Developer at Red Hat
=C2=A0 Author of http://www.iptv-analyzer.org
=C2=A0 LinkedIn: http://www.linkedin.com/in/brouer



--
Best regards / Mvh
Ja= n Pedro Tumusok


_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat





--
Best regards / Mvh
Jan Pedro Tumusok

=



--
Best regards / Mvh
Jan Pedro Tumusok

--f46d043c81fa84e7cf0513259402--