From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 BAB8321F18F for ; Wed, 22 Apr 2015 05:02:45 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so35210367iec.0 for ; Wed, 22 Apr 2015 05:02:44 -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:cc:content-type; bh=/mSeXnZdD0JDg1VZhK6AXo6af5RtyRmUDt6eJOnGsLw=; b=DF0JD93+4T/5N7Oii2ezFfDWoTNmNi+jlaejCVllrBBENf5iSEZ9OaSndzK0vaJTkB HLxWaUbUcGWpdpOxWpYsD/wyUpOOlpLSQUT8rUqRwQGtKJ0Jzah0pNrwJ4eLcX+08fSG boKA+EBje+UKfae5G+BYtn9f6PVFWQ1NNJJ1UtChij6S82Pym/0EEM/Te0y7VT0O2zuf obg+k036Wg6ovzPGxK/zGdOANinY/z2Qo/WExw8FIfSEZOgK9k/eWT/9x8dOpNMpbei/ Rw8pz99QR4nrzzgpWmhOanPUwtXy316f59RRDZRwOPjtnIfltDVw667Zg/r7MRKil3wd HAmg== MIME-Version: 1.0 X-Received: by 10.50.77.48 with SMTP id p16mr3912671igw.31.1429704164293; Wed, 22 Apr 2015 05:02:44 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Wed, 22 Apr 2015 05:02:44 -0700 (PDT) In-Reply-To: <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> 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> <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> Date: Wed, 22 Apr 2015 22:02:44 +1000 X-Google-Sender-Auth: Qq8DAchOd3T17LR_wJesDSvitqg Message-ID: From: jb Cc: bloat Content-Type: multipart/alternative; boundary=047d7bdcaaa4d8c43905144ef00c Subject: Re: [Bloat] RE : 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: Wed, 22 Apr 2015 12:03:14 -0000 --047d7bdcaaa4d8c43905144ef00c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So I find a page that explains SO_RCVBUF is allegedly the most poorly implemented on Linux, vs Windows or OSX, mainly because the one you start with is the cap, you can go lower, but not higher, and data is needed to shrink the window to a new setting, instead of slamming it shut by setsockopt Nevertheless! it is good enough that if I set it on tcp connect I can at least offer the option to run pretty much the same test to the same set of servers, but with a selectable cap on sender rate. By the way, is there a selectable congestion control algorithm available that is sensitive to an RTT that increases dramatically? in other words, one that does the best at avoiding buffer size issues on the remote side of the slowest link? I know heuristics always sound better in theory than practice but surely if an algorithm picks up the idle RTT of a link, it can then pump up the window until an RTT increase indicates it should back off, Instead of (encouraged by no loss) thinking the end-user must be accelerating towards the moon.. thanks. On Wed, Apr 22, 2015 at 6:51 PM, wrote: > cons: large BDP in general would be negatively affected. > A Gbps access vs a DSL access to the same server would require very > different tuning. > > sch_fq would probably make the whole thing less of a problem. > But running it in a VM does not sound a good idea and would not reflect > usual servers setting BTW > > > > > > > > > > -------- Message d'origine -------- > De : Eric Dumazet > Date :2015/04/22 12:29 (GMT+08:00) > =C3=80 : "Steinar H. Gunderson" > Cc : bloat > Objet : Re: [Bloat] DSLReports Speed Test has latency measurement built-i= n > > On Wed, 2015-04-22 at 06:04 +0200, Steinar H. Gunderson wrote: > > On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote: > > > As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket > buffers > > > for the application layer, they do not change the TCP window size > either > > > send or receive. > > > > I haven't gone into the code and checked, but from practical experience= I > > think you're wrong. I've certainly seen positive effects (and verified > with > > tcpdump) from reducing SO_SNDBUF on a server that should have no > problems at > > all sending data really fast to the kernel. > > Well, using SO_SNDBUF disables TCP autotuning. > > Doing so : > > Pros: > > autotuning is known to enable TCP cubic to grow cwnd to bloat levels. > With small enough SO_SNDBUF, you limit this cwnd increase. > > Cons: > > Long rtt sessions might not have enough packets to utilize bandwidth. > > > > > > Then again, this kind of manual tuning trickery got obsolete for me the > > moment sch_fq became available. > > Note that I suppose the SO_MAX_PACING rate is really helping you. > > Without it, TCP cubic is still allowed to 'fill the pipes' until packet > losses. > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --047d7bdcaaa4d8c43905144ef00c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So I find a page that explains SO_RCVBUF is allegedly the = most poorly implemented on Linux, vs Windows or OSX, mainly because the one= you start with is the cap, you can go lower, but not higher, and data is n= eeded to shrink the window to a new setting, instead of slamming it shut by= setsockopt

Nevertheless! it is good enough that if I se= t it on tcp connect I can at least offer the option to run pretty much the = same test to the same set of servers, but with a selectable cap on sender r= ate.

By the way, is there a selectable congestion = control algorithm available that is sensitive to an RTT that increases dram= atically? in other words, one that does the best at avoiding buffer size is= sues on the remote side of the slowest link? I know heuristics always sound= better in theory than practice but surely if an algorithm picks up the idl= e RTT of a link, it can then pump up the window until an RTT increase indic= ates it should back off, Instead of (encouraged by no loss) thinking the en= d-user must be accelerating towards the moon..

tha= nks.

O= n Wed, Apr 22, 2015 at 6:51 PM, <luca.muscariello@orange.com> wrote:
cons: large BDP in general would be negatively affected.=C2=A0
A Gbps access vs a DSL access to the same server would require very di= fferent tuning.=C2=A0

sch_fq would probably make the whole thing less of a problem.=C2=A0
But running it in a VM does not sound a good idea and would not reflec= t usual servers setting BTW=C2=A0









-------- Message d'origine --------
De : Eric Dumazet
Date :2015/04/22 12:29 (GMT+08:00)
=C3=80 : "Steinar H. Gunderson"
Cc : bloat
Objet : Re: [Bloat] DSLReports Speed Test has latency measurement buil= t-in

On Wed, 2015-04-22 at 06:04 +0200, Steinar H. G= underson wrote:
> On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
> > As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket= buffers
> > for the application layer, they do not change the TCP window size= either
> > send or receive.
>
> I haven't gone into the code and checked, but from practical exper= ience I
> think you're wrong. I've certainly seen positive effects (and = verified with
> tcpdump) from reducing SO_SNDBUF on a server that should have no probl= ems at
> all sending data really fast to the kernel.

Well, using SO_SNDBUF disables TCP autotuning.

Doing so :

Pros:

autotuning is known to enable TCP cubic to grow cwnd to bloat levels.
With small enough SO_SNDBUF, you limit this cwnd increase.

Cons:

Long rtt sessions might not have enough packets to utilize bandwidth.


>
> Then again, this kind of manual tuning trickery got obsolete for me th= e
> moment sch_fq became available.

Note that I suppose the SO_MAX_PACING rate is really helping you.

Without it, TCP cubic is still allowed to 'fill the pipes' until pa= cket
losses.



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

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

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


--047d7bdcaaa4d8c43905144ef00c--