From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::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 8E14321F1A0 for ; Tue, 21 Apr 2015 15:13:14 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so27754072ied.1 for ; Tue, 21 Apr 2015 15:13:12 -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:cc:content-type; bh=k1XCAv77i7ldsf314IMkWPrU+OUGdHRpQMaSqSpmp2Q=; b=r+Zkssl197jyAC9t9hCJatZ2YUC1c/7XnVoephkRbD9yu1g0mjrx+1/ygHSNMAPT7b e4N+kJvYaG4CeOO6WFA7ERrQFtcevzYiodDISDhFW/WzONV3q0joapaysVYl9BXitLnA gcFE1CFFAf64raYarAKjnI++bTDtfRIjf7An7tAgzw6mdTWnt6PZ7032S0RUJ/LYb5Ti +pY7Oa51v2RVNTA2UWtjK2/OXctK/Sb/+rs0GvK+RAMr5g3QtjqDF57PZuoplOg16SLo BcAqp8Yr2ORQ4k9oQ0tHgQ+CPV5UJjLA3Yvbr6El9bUFNyG5msK7WFuSZxRRbu9HiAAr s1PA== MIME-Version: 1.0 X-Received: by 10.42.213.136 with SMTP id gw8mr6043216icb.95.1429654392689; Tue, 21 Apr 2015 15:13:12 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Tue, 21 Apr 2015 15:13:12 -0700 (PDT) In-Reply-To: References: <75C1DDFF-FBD2-4825-A167-92DFCF6A7713@gmail.com> <8AD4493E-EA21-496D-923D-B4257B078A1C@gmx.de> <8E4F61CA-4274-4414-B4C0-F582167D66D6@gmx.de> <2C987A4B-7459-43C1-A49C-72F600776B00@gmail.com> <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> Date: Wed, 22 Apr 2015 08:13:12 +1000 X-Google-Sender-Auth: VfTSZ7-Bfsod7_F0pD4WJ1NhIsQ Message-ID: From: jb To: David Lang Content-Type: multipart/alternative; boundary=001a11c317003a594f0514435a44 Cc: bloat 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: Tue, 21 Apr 2015 22:13:42 -0000 --001a11c317003a594f0514435a44 Content-Type: text/plain; charset=UTF-8 Today I've switched it back to large receive window max. The customer base is everything from GPRS to gigabit. But I know from experience that if a test doesn't flatten someones gigabit connection they will immediately assume "oh congested servers, insufficient capacity" and the early adopters of fiber to the home and faster cable products are the most visible in tech forums and so on. It would be interesting to set one or a few servers with a small receive window, take them from the pool, and allow an option to select those, otherwise they would not participate in any default run. Then as you point out, the test can suggest trying those as an option for results with chaotic upload speeds and probable bloat. The person would notice the beauty of the more intimate connection between their kernel and a server, and work harder to eliminate the problematic equipment. Or. They'd stop telling me the test was bugged. thanks On Wed, Apr 22, 2015 at 12:28 AM, David Lang wrote: > On Tue, 21 Apr 2015, David Lang wrote: > > On Tue, 21 Apr 2015, David Lang wrote: >> >> I suspect you guys are going to say the server should be left with a >>>> large >>>> max receive window.. and let people complain to find out what their >>>> issue >>>> is. >>>> >>> >>> what is your customer base? how important is it to provide faster >>> service to teh fiber users? Are they transferring ISO images so the >>> difference is significant to them? or are they downloading web pages where >>> it's the difference between a half second and a quarter second? remember >>> that you are seeing this on the upload side. >>> >>> in the long run, fixing the problem at the client side is the best thing >>> to do, but in the meantime, you sometimes have to work around broken >>> customer stuff. >>> >> >> for the speedtest servers, it should be set large, the purpose is to test >> the quality of the customer stuff, so you don't want to do anything on your >> end that papers over the problem, only to have the customer think things >> are good and experience problems when connecting to another server that >> doesn't implement work-arounds. >> > > Just after hitting send it occured to me that it may be the right thing to > have the server that's being hit by the test play with these settings. If > the user works well at lower settings, but has problems at higher settings, > the point where they start having problems may be useful to know. > > David Lang > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --001a11c317003a594f0514435a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Today I've switched it back to large receive window ma= x.

The customer base is everything from GPRS to gigabit.= But I know from experience that if a test doesn't flatten someones gig= abit connection they will immediately assume "oh congested servers, in= sufficient capacity" and the early adopters of fiber to the home and f= aster cable products are the most visible in tech forums and so on.

It would be interesting to set one or a few servers with = a small receive window, take them from the pool, and allow an option to sel= ect those, otherwise they would not participate in any default run. Then as= you point out, the test can suggest trying those as an option for results = with chaotic upload speeds and probable bloat. The person would notice the = beauty of the more intimate connection between their kernel and a server, a= nd work harder to eliminate the problematic equipment. Or. They'd stop = telling me the test was bugged.

thanks
<= br>

On= Wed, Apr 22, 2015 at 12:28 AM, David Lang <david@lang.hm> wrote= :
On Tue, 21 Apr 2015, David Lang wrote:

On Tue, 21 Apr 2015, David Lang wrote:

I suspect you guys are going to say the server should be left with a large<= br> max receive window.. and let people complain to find out what their issue is.

what is your customer base? how important is it to provide faster service t= o teh fiber users? Are they transferring ISO images so the difference is si= gnificant to them? or are they downloading web pages where it's the dif= ference between a half second and a quarter second? remember that you are s= eeing this on the upload side.

in the long run, fixing the problem at the client side is the best thing to= do, but in the meantime, you sometimes have to work around broken customer= stuff.

for the speedtest servers, it should be set large, the purpose is to test t= he quality of the customer stuff, so you don't want to do anything on y= our end that papers over the problem, only to have the customer think thing= s are good and experience problems when connecting to another server that d= oesn't implement work-arounds.

Just after hitting send it occured to me that it may be the right thing to = have the server that's being hit by the test play with these settings. = If the user works well at lower settings, but has problems at higher settin= gs, the point where they start having problems may be useful to know.

David Lang
_______________________________________________=
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat


--001a11c317003a594f0514435a44--