From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 E848821F263 for ; Mon, 30 Mar 2015 06:56:16 -0700 (PDT) Received: by oicf142 with SMTP id f142so120023999oic.3 for ; Mon, 30 Mar 2015 06:56:15 -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; bh=uKUGckTEqdVj7jltnkiQVsZEnKNsgdJb+Lb1zD6I3JI=; b=M4Czrpd686iAB0nhUAvlNFj/VC5uC1tmvmG2oTp+eradN+eRLmyuv57lyf0LHn2H0g zNMoC2OY26VCn4qNldki41+R7VToPdVyuC0CFpPH5VAA61gyE4DJzWOFsG3b9rRJcpa6 C9ZNTBFPa9oaECz4au+ihic21IzoY9bh/KaD7Ao4ZtiUJkjq/FHtT9s4tsr8DMLkcAE5 yzqfTTYIp7O+UejIeIWdOuJvNgSKk4br4jTy427D/zuebmoxF8W0G+QqRLJtnWYRzISM gu/TG4jtmg9qn1lRlne9TmMkAtV+DxYkiq/GoG03qiYrw6/YCy7L5p0/u/330f4bIly2 28oA== MIME-Version: 1.0 X-Received: by 10.202.213.88 with SMTP id m85mr25460914oig.52.1427723775340; Mon, 30 Mar 2015 06:56:15 -0700 (PDT) Received: by 10.76.154.194 with HTTP; Mon, 30 Mar 2015 06:56:15 -0700 (PDT) In-Reply-To: <755FC1BE-141C-42FD-B3E3-564488982665@gmail.com> References: <20150316203532.05BD21E2@taggart.lackof.org> <123130.1426635142@turing-police.cc.vt.edu> <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> Date: Mon, 30 Mar 2015 15:56:15 +0200 Message-ID: From: Pedro Tumusok To: Jonathan Morton Content-Type: multipart/alternative; boundary=001a113b0294777945051281d854 Cc: "dpreed@reed.com" , bloat Subject: Re: [Bloat] 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: Mon, 30 Mar 2015 13:56:46 -0000 --001a113b0294777945051281d854 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 30, 2015 at 9:06 AM, Jonathan Morton wrote: > > > On 29 Mar, 2015, at 20:36, Pedro Tumusok > wrote: > > > > Dslreports got a new speedtester up, anybody know Justin or some of the > other people over there? > > > > http://www.dslreports.com/speedtest > > > > Maybe somebody on here could even lend a hand in getting them to > implement features like ping under load etc. > > I gave that test a quick try. It measured my download speed well enough, > but the upload=E2=80=A6 > > Let=E2=80=99s just say it effectively measured the speed to my local webc= ache, not > to the server itself. > > Hi Jonathan, I forwarded your observation to the Justin over at dslreports and I got the following answer. I a bit in the middle here, but I'll see if I can get him to join the mailing list, he seemed interested in bufferbloat at least. Also would you mind doing another test and share the link for result, so he can check closer? ""Let=E2=80=99s just say it effectively measured the speed to my local webc= ache, not to the server itself." If he runs an outbound squid, as the upload speed is measured continuously, it will measure the speed to the squid, although why would configure it to cache POSTs when the URL is unique and includes all the no-cache headers? it doesn't make them any faster we still have to wait for the result.. I believe his situation to be rather unique. 190,000 tests nobody else has had that case. Either way if he re-runs and sends me a link, I can look at the log and work out how to"patch" the upload speed at the end to the right number because it waits for the real reply from the server, with the amount uploaded, and no web cache can fake that. on the other things, yes I'd like to hear about buffer bloat ideas. The simultaneous up+down mode would also be interesting. Since I control the servers and don't use a CDN, I'm thinking of running ng-capture constantly, then inspecting the tcptraces in real time. If there is stuff that can drop out of that that is revealing it can be rolled into the results.. Even without any buffer bloat issues, being able to see packet loss directly would be a win for people with bad lines. It would also pickup those TCP disasters between client and server when they can't agree on something or things are fragmented etc etc." What do you guys think about his packet capture ideas? There are a lot of users over on dslreports, so if they put up a speedtest with bufferbloat "detectors" it could be another thing to get the snowball to roll. I also removed cerowrt dev list, do not think we need to cross post to that one. --=20 Best regards / Mvh Jan Pedro Tumusok --001a113b0294777945051281d854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 30, 2015 at 9:06 AM, Jonathan Morton <= chromatix99@gmai= l.com> wrote:

> On 29 Mar, 2015, at 20:36, Pedro Tumusok <pedro.tumusok@gmail.com> wrote:
>
> Dslreports got a new speedtester up, anybody know Justin or some of th= e other people over there?
>
> http= ://www.dslreports.com/speedtest
>
> Maybe somebody on here could even lend a hand in getting them to imple= ment features like ping under load etc.

I gave that test a quick try.=C2=A0 It measured my download speed we= ll enough, but the upload=E2=80=A6

Let=E2=80=99s just say it effectively measured the speed to my local webcac= he, not to the server itself.


Hi Jonathan,

I forwarded your obs= ervation to the Justin over at dslreports and I got the following answer. I= a bit in the middle here, but I'll see if I can get him to join the ma= iling list, he seemed interested in bufferbloat at least.
Also wo= uld you mind doing another test and share the link for result, so he can ch= eck closer?

""Let=E2=80=99s just say it = effectively measured the speed to my local webcache, not to the server itse= lf."

If he runs an outbound squid, as the upl= oad speed is measured continuously, it will measure the speed to the squid,= although why would configure it to cache POSTs when the URL is unique and = includes all the no-cache headers? it doesn't make them any faster we s= till have to wait for the result.. I believe his situation to be rather uni= que. 190,000 tests nobody else has had that case.

= Either way if he re-runs and sends me a link, I can look at the log and wor= k out how to"patch" the upload speed at the end to the right numb= er because it waits for the real reply from the server, with the amount upl= oaded, and no web cache can fake that.

on the othe= r things, yes I'd like to hear about buffer bloat ideas.
The = simultaneous up+down mode would also be interesting.

Since I control the servers and don't use a CDN, I'm thinking of= running ng-capture constantly, then inspecting the tcptraces in real time.= If there is stuff that can drop out of that that is revealing it can be ro= lled into the results.. Even without any buffer bloat issues, being able to= see packet loss directly would be a win for people with bad lines. It woul= d also pickup those TCP disasters between client and server when they can&#= 39;t agree on something or things are fragmented etc etc."
=


<= div class=3D"gmail_extra">
What do you = guys think about his packet capture ideas? There are a lot of users over on= dslreports, so if they put up a speedtest with bufferbloat "detectors= " it could be another thing to get the snowball to roll.

I also removed cerowrt dev list, do not think we need to cro= ss post to that one.
--
Best regard= s / Mvh
Jan Pedro Tumusok

--001a113b0294777945051281d854--